QuantLib › quantlib-users

pure virtual function call

Classic

List

Threaded

34 messages Options

George Wang

Re: Fwd: pure virtual function call

I spoke too soon as well. Although the examples all behave similarly before and after the patch, the test suite takes forever and still have not finished running after a couple of hours. There are no errors at all, but it seems to get stuck at "Testing Markov functional vanilla engines..." I believe the patch is suppose to make the test suite run faster not slower. So there might be something wrong with my setup. Any suggestions on where to look? Thanks!

1> Testing analytic European exchange option greeks...

1> Testing Markov functional state process...

1> Testing Kahale smile section...

1> Testing Markov functional calibration to one instrument set...

1> Testing Markov functional vanilla engines...

On Wed, Jun 4, 2014 at 7:51 PM, George <[hidden email]> wrote:

Thanks to Klaus and Luigi 's help, I have got the patch compiled successfully. However, I did not experience the "pure virtual function call" error before trying this patch, and I don't notice any difference after the patch by running existing examples.

Klaus's blog has some example code in Scala, but I have never used it. http://hpcquantlib.wordpress.com/2012/02/27/quantlib-swig-and-a-thread-safe-observer-pattern-in-c/

Simon, do you have any C# example code that I can try to reproduce your "pure virtual function call" error? If it's working Java/scala project that doesn't require much setup, I can give it a try as well.

Thanks,
George

On Wed, Jun 4, 2014 at 2:00 PM, smazzucca <[hidden email]> wrote:

Is it possible that I am getting the "pure virtual function call" error for a
different reason ?

Given that I don't have any multi-thread logic, is the patch going to do
anything good for me ? Or does it only help with MT code ?

Is there at least a way to trap that exception so it doesn't crash the whole
process ?

--
View this message in context: http://quantlib.10058.n7.nabble.com/pure-virtual-function-call-tp15342p15377.html

Sent from the quantlib-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Klaus Spanderen-2

Re: Fwd: pure virtual function call

In reply to this post by smazzucca

Simon, On Wednesday, June 04, 2014 11:00:55 AM smazzucca wrote:

> Is it possible that I am getting the "pure virtual function call" error for

> a different reason ?

We can find this out. Please comment out line 90 to 93 in observable.cpp

// if(active_) {

// observer_->update();

// }

Your code might not work correctly any more but the pure virtual function call exception should disapear. Otherwise we are chasing a ghost here.

regards

Klaus

Klaus Spanderen-2

Re: Fwd: pure virtual function call

In reply to this post by George Wang

Hi George,

I've comment this test out in the quantlibtestsuite.cpp shipped with the patch. Reason for the observed behaviour is that this test creates a large amount of observer/observable pairs and the boost::signal2 library doesn't scale as well as QL's own implementation of the Observer pattern, maybe due to the overhead to support multithreading.

regards

Klaus

On Wednesday, June 04, 2014 11:04:21 PM George wrote:

> I spoke too soon as well. Although the examples all behave similarly before

> and after the patch, the test suite takes forever and still have not

> finished running after a couple of hours. There are no errors at all, but

> it seems to get stuck at "Testing Markov functional vanilla engines..." I

> believe the patch is suppose to make the test suite run faster not slower.

> So there might be something wrong with my setup. Any suggestions on where

> to look? Thanks!

> 1> Testing analytic European exchange option greeks...

> 1> Testing Markov functional state process...

> 1> Testing Kahale smile section...

> 1> Testing Markov functional calibration to one instrument set...

> 1> Testing Markov functional vanilla engines...

> On Wed, Jun 4, 2014 at 7:51 PM, George <[hidden email]> wrote:

> > Thanks to Klaus and Luigi 's help, I have got the patch compiled

> > successfully. However, I did not experience the "pure virtual function

> > call" error before trying this patch, and I don't notice any difference

> > after the patch by running existing examples.

> >

> > Klaus's blog has some example code in Scala, but I have never used it.

> > http://hpcquantlib.wordpress.com/2012/02/27/quantlib-swig-and-a-thread-saf

> > e-observer-pattern-in-c/

> >

> > Simon, do you have any C# example code that I can try to reproduce your

> > "pure virtual function call" error? If it's working Java/scala project

> > that

> > doesn't require much setup, I can give it a try as well.

> >

> > Thanks,

> > George

> >

> > On Wed, Jun 4, 2014 at 2:00 PM, smazzucca <[hidden email]>

> >

> > wrote:

> >> Is it possible that I am getting the "pure virtual function call" error

> >> for a

> >> different reason ?

> >>

> >> Given that I don't have any multi-thread logic, is the patch going to do

> >> anything good for me ? Or does it only help with MT code ?

> >>

> >> Is there at least a way to trap that exception so it doesn't crash the

> >> whole

> >> process ?

> >>

> >> --

> >> View this message in context:

> >> http://quantlib.10058.n7.nabble.com/pure-virtual-function-call-tp15342p15

> >> 377.html Sent from the quantlib-users mailing list archive at Nabble.com.

> >>

> >> -------------------------------------------------------------------------

> >> ----- Learn Graph Databases - Download FREE O'Reilly Book

> >> "Graph Databases" is the definitive new guide to graph databases and

> >> their

> >> applications. Written by three acclaimed leaders in the field,

> >> this first edition is now available. Download your free book today!

> >> http://p.sf.net/sfu/NeoTech

> >> _______________________________________________

> >> QuantLib-users mailing list

> >> [hidden email]

> >> https://lists.sourceforge.net/lists/listinfo/quantlib-users

smazzucca

Re: Fwd: pure virtual function call

OK, I think I have something we can work with.

I have 3 sets of files:
1) SWIG wrapper for QL 1.3
2) SWIG wrapper for QL 1.4 (patched)
3) SWIG wrapper for QL 1.4 (patched, but with update() method commented out)

This is what I get with each:

1) This is my control scenario where I get the "Pure Virtual Function Call" error

2) Contrary to what I said yesterday, I don't actually get the PVFC error, but it's something similar. While the PVFC issue takes down the whole process, this freezes the process. The good news is that in VS I can actually see a bit of what's going on.

The "GC Finalizer Thread" is trying to dispose a CPIBond object:

~CPIBond()
{
Dispose();
}

Which in turn calls:

public override void Dispose()
{
lock (this)
{
if (swigCPtr.Handle != IntPtr.Zero)
{
if (swigCMemOwn)
{
swigCMemOwn = false;
NQuantLibcPINVOKE.delete_CPIBond(swigCPtr);
}
swigCPtr = new HandleRef(null, IntPtr.Zero);
}
GC.SuppressFinalize(this);
base.Dispose();
}
}

The above (from the C# wrapper) gets stuck on the bold line while calling the method below (in the C++ wrapper):

SWIGEXPORT void SWIGSTDCALL CSharp_delete_CPIBond(void * jarg1) {
CPIBondPtr *arg1 = (CPIBondPtr *) 0 ;

arg1 = (CPIBondPtr *)jarg1;
{
try {
delete arg1;
} catch (std::out_of_range& e) {
{
SWIG_CSharpException(SWIG_IndexError, const_cast<char*>(e.what())); return ;
};
} catch (std::exception& e) {
{
SWIG_CSharpException(SWIG_RuntimeError, const_cast<char*>(e.what())); return ;
};
} catch (...) {
{
SWIG_CSharpException(SWIG_UnknownError, "unknown error"); return ;
};
}
}
}

3) Lastly, when I run the version with commented out update(), it all appears to work. I have not checked the numbers themselves, but at least I don't get any errors. I think the only problem is that it appears a bit slow, but I have not actually timed it.

As far as converting your test app to C#, I am not sure we should do that yet. The issue might have something to do with how we use QL. I will see if I can isolate my issue in a small app I can send you.

Hopefully the above will help you understand what's going on.

Thank you,
Simon

Klaus Spanderen-2

Re: Fwd: pure virtual function call

Hi Simon,

thanks for the error report. Case 3 shows that it is actually the observer pattern, which is creating the problems for you. (I bet, if you comment out the update() methd in case 1 it will also work).

Unclear now is why the patch does not fix it. Based on your description I guess in case 2 your application is facing a dead lock. If I had an exmple program then I'd remove boost::mutex::scoped_lock in observable.cpp or I'd replace them by boost::recursive_mutex::scoped_lock (and also replace boost::mutex by boost::recursive_mutex)

thanks and regards

Klaus

On Thursday, June 05, 2014 08:02:33 AM smazzucca wrote:

> OK, I think I have something we can work with.

> I have 3 sets of files:

> 1) SWIG wrapper for QL 1.3

> 2) SWIG wrapper for QL 1.4 (patched)

> 3) SWIG wrapper for QL 1.4 (patched, but with update() method commented out)

> This is what I get with each:

> 1) This is my control scenario where I get the "Pure Virtual Function Call"

> error

> 2) Contrary to what I said yesterday, I don't actually get the PVFC error,

> but it's something similar. While the PVFC issue takes down the whole

> process, this /freezes/ the process. The good news is that in VS I can

> actually see a bit of what's going on.

> The "GC Finalizer Thread" is trying to dispose a CPIBond object:

> ~CPIBond()

> {

> Dispose();

> }

> Which in turn calls:

> public override void Dispose()

> {

> lock (this)

> {

> if (swigCPtr.Handle != IntPtr.Zero)

> {

> if (swigCMemOwn)

> {

> swigCMemOwn = false;

> *NQuantLibcPINVOKE.delete_CPIBond(swigCPtr);*

> }

> swigCPtr = new HandleRef(null, IntPtr.Zero);

> }

> GC.SuppressFinalize(this);

> base.Dispose();

> }

> The above (from the C# wrapper) gets stuck on the bold line while calling

> the method below (in the C++ wrapper):

> SWIGEXPORT void SWIGSTDCALL CSharp_delete_CPIBond(void * jarg1) {

> CPIBondPtr *arg1 = (CPIBondPtr *) 0 ;

> arg1 = (CPIBondPtr *)jarg1;

> {

> try {

> delete arg1;

> } catch (std::out_of_range& e) {

> {

> SWIG_CSharpException(SWIG_IndexError, const_cast<char*>(e.what()));

> return ;

> };

> } catch (std::exception& e) {

> {

> SWIG_CSharpException(SWIG_RuntimeError,

> const_cast<char*>(e.what())); return ;

> };

> } catch (...) {

> {

> SWIG_CSharpException(SWIG_UnknownError, "unknown error"); return ;

> };

> }

> 3) Lastly, when I run the version with commented out update(), it all

> appears to work. I have not checked the numbers themselves, but at least I

> don't get any errors. I think the only problem is that it appears a bit

> slow, but I have not actually timed it.

> As far as converting your test app to C#, I am not sure we should do that

> yet. The issue might have something to do with how we use QL. I will see if

> I can isolate my issue in a small app I can send you.

> Hopefully the above will help you understand what's going on.

> Thank you,

> Simon

> --

> View this message in context:

> http://quantlib.10058.n7.nabble.com/pure-virtual-function-call-tp15342p1539

> 4.html Sent from the quantlib-users mailing list archive at Nabble.com.

> ----------------------------------------------------------------------------

> -- Learn Graph Databases - Download FREE O'Reilly Book

> "Graph Databases" is the definitive new guide to graph databases and their

> applications. Written by three acclaimed leaders in the field,

> this first edition is now available. Download your free book today!

> http://p.sf.net/sfu/NeoTech

> _______________________________________________

> QuantLib-users mailing list

> [hidden email]

> https://lists.sourceforge.net/lists/listinfo/quantlib-users

smazzucca

Re: Fwd: pure virtual function call

Klaus,

I ran a much longer stress test overnight and even in case #3 I get the result I get in case #2.

So even with update commented out (although it's much, much more rare), at one point I get that exact symptom: code halts on NQuantLibcPINVOKE.delete_CPIBond(swigCPtr).

Does that mean there is something else going on ?

smazzucca

Re: Fwd: pure virtual function call

Klaus

We are using Zero Inflation Curves from Bloomberg. The tickers we are using for USD Inflation Linked Bonds for the curve points are USSWIT1 Curncy, USSWIT2 Curncy, USSWIT3 Curncy, etc…

I am trying to put togther a small sample for you.
S

In response to:

Klaus Spanderen wrote

Hi Simon,

thanks for the error report. Case 3 shows that it is actually the observer pattern, which is creating the problems for you. (I bet, if you comment out the update() methd in case 1 it will also work).

Unclear now is why the patch does not fix it. Based on your description I guess in case 2 your application is facing a dead lock. If I had an exmple program then I'd remove boost::mutex::scoped_lock in observable.cpp or I'd replace them by boost::recursive_mutex::scoped_lock (and also replace boost::mutex by boost::recursive_mutex)

thanks and regards
Klaus

smazzucca

RE: Fwd: pure virtual function call

In reply to this post by Klaus Spanderen-2

Klaus,

It will be very complicated to write up a sample to reproduce the error… I will if it comes to it, but can you see if this looks right in the meantime ?

Or maybe it can be simplified in such a way that the critical code is used less ?

This is how we create CpiBond objects. This is done thousands of times:

private CPIBond CreateIndexLinkedBond()

{

ZeroIndexTermCurve.LoadCurveValues(InstrumentCalendar, DayCounter, ScenarioDate, false);

ZeroIndexTermCurve.AdjustCurve(_CurrentMaturityDate);

Period zeroCouponSwapObservationPeriod = new Period(ZERO_COUPON_SWAP_OBSERVATION_LAG-1, TimeUnit.Months);

Date observationLagDate = ScenarioDate.Subtract(zeroCouponSwapObservationPeriod);

DateGeneration.Rule backwardDateGeneration = DateGeneration.Rule.Backward;

bool interpolated = false;

ZeroInflationTermStructureHandle cpiTS = new ZeroInflationTermStructureHandle();

ZeroInflationIndex inflationIndex = new USCPI(interpolated, cpiTS);

inflationIndex.addFixing(observationLagDate, CurrentReferenceIndexlevel);

//Zero coupon inflation index swap

Datum[] zeroCouponInflationIndexSwapData = ZeroIndexTermCurve.ToDatumArray();

ZeroHelperVector zeroCouponSwapHelpers = ZeroIndexTermCurve.ToZeroHelperVector(

inflationIndex,

zeroCouponSwapObservationPeriod,

InstrumentCalendar,

DayCounter);

double baseZeroRate = zeroCouponInflationIndexSwapData[0].rate / 100;

BackwardFlat backwardFlat = new BackwardFlat();

double accuracy = 1.0e-12;

ZeroInflationTermStructure piecewiseZeroInflation = new PiecewiseZeroInflation(

ScenarioDate,

InstrumentCalendar,

DayCounter,

zeroCouponSwapObservationPeriod,

QuantLib.Frequency.Monthly,

interpolated,

baseZeroRate,

_DiscountCurve,

zeroCouponSwapHelpers,

accuracy,

backwardFlat);

cpiTS = new ZeroInflationTermStructureHandle(piecewiseZeroInflation);

inflationIndex = new USCPI(interpolated, cpiTS);

List<double> fixedRatesList = new List<double>() { 1, CouponRate / 100 };

DoubleVector fixedRates = new DoubleVector(fixedRatesList);

//Always use actual365fixed ISDA convention for this

DayCounter fixedDayCount = new Actual365Fixed();

CPI.InterpolationType observationInterpolation = CPI.InterpolationType.Linear;

Period couponFrequenceyPeriod = new Period(Frequency);

Schedule fixedSchedule = new Schedule(

IssueDate,

MaturityDate,

couponFrequenceyPeriod,

InstrumentCalendar,

_BusinessDayConvention,

backwardDateGeneration,

_EndOfMonth);

CPIBond bond = new CPIBond(

(uint)SettlementDays,

NotionalValue,

GrowthOnly,

BaseIndex,

ObservationPeriod,

inflationIndex,

observationInterpolation,

fixedSchedule,

fixedRates,

fixedDayCount,

_BusinessDayConvention,

IssueDate

);

return bond;

}

First we create the CpiBond with CreateIndexLinkedBond() then load the pricing engine:

private void LoadPriceEngine()

{

PricingEngine engine = new DiscountingBondEngine(_DiscountCurve);

_Bond.setPricingEngine(engine);

if (_CleanPrice == 0)

_CleanPrice = _Bond.cleanPrice();

}

Methods called from CreateIndexLinkedBond():

public void LoadCurveValues(Calendar calendar, DayCounter dayCounter, Date scenarioDate, bool inludeFirstCurvePoint)

{

List<CurveValue> curveValues = GetAsCurveValues();

_DayCounter = dayCounter;

_Calendar = calendar;

//Curves must be initialized with reference date

double firstValue = (curveValues.Count > 0) ? curveValues[0].Value : 0.0;

CurveDates = new List<Date>() { scenarioDate };

CurveValues = new List<double>() { firstValue };

int startIndex = inludeFirstCurvePoint ? 0 : 1;

for (int i = startIndex; i < curveValues.Count(); i++)

{

Period months = new Period(curveValues[i].Months, TimeUnit.Months);

Date itemDate = _Calendar.adjust(scenarioDate.Add(months));

CurveDates.Add(itemDate);

CurveValues.Add(curveValues[i].Value);

}

/// <summary>

/// With good data, this won't be an issue, but defensively we must

/// ensure that the Maturity Date is included in the curve

/// </summary>

public void AdjustCurve(Date maturityDate)

{

if (CurveDates.Count > 0)

{

Date lastDate = CurveDates[CurveDates.Count - 1];

double lastValue = CurveValues[CurveValues.Count - 1];

if (maturityDate.ToDateTime() > lastDate.ToDateTime())

{

CurveDates.Add(maturityDate);

CurveValues.Add(lastValue);

}

Thank you,

Simon

From: Klaus Spanderen-2 [via QuantLib] [mailto:ml-node+[hidden email]]
Sent: Thursday, June 05, 2014 5:03 PM
To: Simon Mazzucca
Subject: Re: Fwd: pure virtual function call

Hi Simon,

thanks for the error report. Case 3 shows that it is actually the observer pattern, which is creating the problems for you. (I bet, if you comment out the update() methd in case 1 it will also work).

thanks and regards

Klaus

On Thursday, June 05, 2014 08:02:33 AM smazzucca wrote:

> OK, I think I have something we can work with.

> I have 3 sets of files:

> 1) SWIG wrapper for QL 1.3

> 2) SWIG wrapper for QL 1.4 (patched)

> 3) SWIG wrapper for QL 1.4 (patched, but with update() method commented out)

> This is what I get with each:

> 1) This is my control scenario where I get the "Pure Virtual Function Call"

> error

> 2) Contrary to what I said yesterday, I don't actually get the PVFC error,

> but it's something similar. While the PVFC issue takes down the whole

> process, this /freezes/ the process. The good news is that in VS I can

> actually see a bit of what's going on.

> The "GC Finalizer Thread" is trying to dispose a CPIBond object:

> ~CPIBond()

> {

> Dispose();

> }

> Which in turn calls:

> public override void Dispose()

> {

> lock (this)

> {

> if (swigCPtr.Handle != IntPtr.Zero)

> {

> if (swigCMemOwn)

> {

> swigCMemOwn = false;

> *NQuantLibcPINVOKE.delete_CPIBond(swigCPtr);*

> }

> swigCPtr = new HandleRef(null, IntPtr.Zero);

> }

> GC.SuppressFinalize(this);

> base.Dispose();

> }

> The above (from the C# wrapper) gets stuck on the bold line while calling

> the method below (in the C++ wrapper):

> SWIGEXPORT void SWIGSTDCALL CSharp_delete_CPIBond(void * jarg1) {

> CPIBondPtr *arg1 = (CPIBondPtr *) 0 ;

> arg1 = (CPIBondPtr *)jarg1;

> {

> try {

> delete arg1;

> } catch (std::out_of_range& e) {

> {

> SWIG_CSharpException(SWIG_IndexError, const_cast<char*>(e.what()));

> return ;

> };

> } catch (std::exception& e) {

> {

> SWIG_CSharpException(SWIG_RuntimeError,

> const_cast<char*>(e.what())); return ;

> };

> } catch (...) {

> {

> SWIG_CSharpException(SWIG_UnknownError, "unknown error"); return ;

> };

> }

> 3) Lastly, when I run the version with commented out update(), it all

> appears to work. I have not checked the numbers themselves, but at least I

> don't get any errors. I think the only problem is that it appears a bit

> slow, but I have not actually timed it.

> As far as converting your test app to C#, I am not sure we should do that

> yet. The issue might have something to do with how we use QL. I will see if

> I can isolate my issue in a small app I can send you.

> Hopefully the above will help you understand what's going on.

> Thank you,

> Simon

> --

> View this message in context:

> http://quantlib.10058.n7.nabble.com/pure-virtual-function-call-tp15342p1539

> 4.html Sent from the quantlib-users mailing list archive at Nabble.com.

> ----------------------------------------------------------------------------

> -- Learn Graph Databases - Download FREE O'Reilly Book

> "Graph Databases" is the definitive new guide to graph databases and their

> applications. Written by three acclaimed leaders in the field,

> this first edition is now available. Download your free book today!

> http://p.sf.net/sfu/NeoTech

> _______________________________________________

> QuantLib-users mailing list

> [hidden email]

> https://lists.sourceforge.net/lists/listinfo/quantlib-users

If you reply to this email, your message will be added to the discussion below:

http://quantlib.10058.n7.nabble.com/pure-virtual-function-call-tp15342p15399.html

To unsubscribe from pure virtual function call, click here.
NAML

This e-mail, including its contents and attachments, if any, is confidential and is intended only for the addressee. If you are not the intended recipient, you are hereby notified that any use, dissemination or distribution of this communication is strictly forbidden. If you received this e-mail in error please immediately notify the sender and delete or destroy this and all copies of this message and all attachments. Any unauthorized disclosure, use, distribution, or reproduction of this message or any attachments is prohibited and may be unlawful.

Peter Caspers-4

Re: Fwd: pure virtual function call

In reply to this post by Klaus Spanderen-2

Hi Klaus,

> I've comment this test out in the quantlibtestsuite.cpp shipped with the
> patch. Reason for the observed behaviour is that this test creates a large
> amount of observer/observable pairs and the boost::signal2 library doesn't
> scale as well as QL's own implementation of the Observer pattern, maybe due
> to the overhead to support multithreading.

I had a closer look at this. One reason for the poor performance is
that the Markov
model uses a lot of temporary swap indices which create much
observable - traffic.
I now avoid this with the help of a slight extension of the swap index class.

The other reason is the OptionletStripper1. Its member capFloors_
(which contains
a lot of CapFloor instruments) takes forever when destructed. I don't have a fix
for this at the moment. I think I constructed a fairly realistic cap
surface for the
Markov test case, so this issue should be reviewed I guess. I'll do it
later. At the
moment the only possible solution seems to be to rewrite the boostrap without
relying on the standard instrument and pricing engine. Anyway for the time being
I replaced the market cap surface by a flat one when the test is run with your
thread safe observable.

I added the changes to PR #101 in Luigis repository. With them the
Markov test cases
run reasonably fast again (yet not as fast as with the original
observable implementation,
but this is not expected anyway, is it ?).

https://github.com/lballabio/quantlib/pull/101

Thanks
Peter

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Klaus Spanderen-2

Re: Fwd: pure virtual function call

Hi Peter,

cool, thanks for your help.

regards

Klaus

On Sunday, June 08, 2014 08:38:52 PM Peter Caspers wrote:

> Hi Klaus,

> > I've comment this test out in the quantlibtestsuite.cpp shipped with the

> > patch. Reason for the observed behaviour is that this test creates a large

> > amount of observer/observable pairs and the boost::signal2 library doesn't

> > scale as well as QL's own implementation of the Observer pattern, maybe

> > due

> > to the overhead to support multithreading.

> I had a closer look at this. One reason for the poor performance is

> that the Markov

> model uses a lot of temporary swap indices which create much

> observable - traffic.

> I now avoid this with the help of a slight extension of the swap index

> class.

> The other reason is the OptionletStripper1. Its member capFloors_

> (which contains

> a lot of CapFloor instruments) takes forever when destructed. I don't have a

> fix for this at the moment. I think I constructed a fairly realistic cap

> surface for the

> Markov test case, so this issue should be reviewed I guess. I'll do it

> later. At the

> moment the only possible solution seems to be to rewrite the boostrap

> without relying on the standard instrument and pricing engine. Anyway for

> the time being I replaced the market cap surface by a flat one when the

> test is run with your thread safe observable.

> I added the changes to PR #101 in Luigis repository. With them the

> Markov test cases

> run reasonably fast again (yet not as fast as with the original

> observable implementation,

> but this is not expected anyway, is it ?).

> https://github.com/lballabio/quantlib/pull/101

> Thanks

> Peter

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Luigi Ballabio

Re: Fwd: pure virtual function call

In reply to this post by smazzucca

Klaus,
didn't we have some kind of reference cycle with CPI bonds? Could
this be related somehow?

Luigi

On Fri, Jun 6, 2014 at 5:28 PM, smazzucca <[hidden email]> wrote:

> Klaus
>
> We are using Zero Inflation Curves from Bloomberg. The tickers we are using
> for USD Inflation Linked Bonds for the curve points are USSWIT1 Curncy,
> USSWIT2 Curncy, USSWIT3 Curncy, etc…
>
> I am trying to put togther a small sample for you.
> S
>
>
> In response to:
>
>
> Klaus Spanderen wrote
>> Hi Simon,
>>
>> thanks for the error report. Case 3 shows that it is actually the observer
>> pattern, which is creating the problems for you. (I bet, if you comment
>> out the update() methd in case 1 it will also work).
>>
>> Unclear now is why the patch does not fix it. Based on your description I
>> guess in case 2 your application is facing a dead lock. If I had an exmple
>> program then I'd remove boost::mutex::scoped_lock in observable.cpp or I'd
>> replace them by boost::recursive_mutex::scoped_lock (and also replace
>> boost::mutex by boost::recursive_mutex)
>>
>> thanks and regards
>> Klaus
>
>
>
>
>
> --
> View this message in context: http://quantlib.10058.n7.nabble.com/pure-virtual-function-call-tp15342p15411.html
> Sent from the quantlib-users mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Klaus Spanderen-2

Re: Fwd: pure virtual function call

Hi Luigi,

yes, CPI bonds have cycle references and that why (maybe) switching to recursive mutex looks might help.

regards

Klaus

On Monday, June 09, 2014 04:33:36 PM Luigi Ballabio wrote:

> Klaus,

> didn't we have some kind of reference cycle with CPI bonds? Could

> this be related somehow?

> Luigi

> On Fri, Jun 6, 2014 at 5:28 PM, smazzucca <[hidden email]> wrote:

> > Klaus

> >

> > We are using Zero Inflation Curves from Bloomberg. The tickers we are

> > using

> > for USD Inflation Linked Bonds for the curve points are USSWIT1 Curncy,

> > USSWIT2 Curncy, USSWIT3 Curncy, etc…

> >

> > I am trying to put togther a small sample for you.

> > S

> >

> > In response to:

> >

> > Klaus Spanderen wrote

> >

> >> Hi Simon,

> >>

> >> thanks for the error report. Case 3 shows that it is actually the

> >> observer

> >> pattern, which is creating the problems for you. (I bet, if you comment

> >> out the update() methd in case 1 it will also work).

> >>

> >> Unclear now is why the patch does not fix it. Based on your description I

> >> guess in case 2 your application is facing a dead lock. If I had an

> >> exmple

> >> program then I'd remove boost::mutex::scoped_lock in observable.cpp or

> >> I'd

> >> replace them by boost::recursive_mutex::scoped_lock (and also replace

> >> boost::mutex by boost::recursive_mutex)

> >>

> >> thanks and regards

> >> Klaus

> >

> > --

> > View this message in context:

> > http://quantlib.10058.n7.nabble.com/pure-virtual-function-call-tp15342p15

> > 411.html Sent from the quantlib-users mailing list archive at Nabble.com.

> >

> > --------------------------------------------------------------------------

> > ---- Learn Graph Databases - Download FREE O'Reilly Book

> > "Graph Databases" is the definitive new guide to graph databases and their

> > applications. Written by three acclaimed leaders in the field,

> > this first edition is now available. Download your free book today!

> > http://p.sf.net/sfu/NeoTech

> > _______________________________________________

> > QuantLib-users mailing list

> > [hidden email]

> > https://lists.sourceforge.net/lists/listinfo/quantlib-users

Klaus Spanderen-2

Re: Fwd: pure virtual function call

In reply to this post by smazzucca

Hi Simon,

I think I've made some progress on this topic. In order to be able to debug it I've implemented the InflationCPIBondTest::testCleanPrice unit test in Scala... and this program shows the same behavior as you've outlined:

1. pure virtual function call with an unpatched QuantLib

2. spurious dead locks when using the patch

Indeed due to the cyclic reference structure (Inflation Index referring the CPI term-structure and via versa) this problem exposes a possible dead lock situation within the patched observer pattern. After this has been fixed the CPI bond test case is now running smoothly for hours w/o any "pure virtual function calls" or dead locks.

The latest version of the patch is available here

http://hpc-quantlib.de/src/observer.zip

I'd would be nice if you can test it. BTW, due to the cyclic references in the QL inflation code it is quite easy to create a memory leak even with Scala. I had to manually break the cyclic reference, s. line 141 in the CPIBond example

https://github.com/lballabio/quantlib/pull/106

best regards

Klaus

On Friday, June 06, 2014 08:47:47 AM smazzucca wrote:

> Klaus,

> It will be very complicated to write up a sample to reproduce the error... I

> will if it comes to it, but can you see if this looks right in the meantime

> ? Or maybe it can be simplified in such a way that the critical code is

> used less ?

> This is how we create CpiBond objects. This is done thousands of times:

> private CPIBond CreateIndexLinkedBond()

> {

> ZeroIndexTermCurve.LoadCurveValues(InstrumentCalendar,

> DayCounter, ScenarioDate, false);

> ZeroIndexTermCurve.AdjustCurve(_CurrentMaturityDate);

> Period zeroCouponSwapObservationPeriod = new

> Period(ZERO_COUPON_SWAP_OBSERVATION_LAG-1, TimeUnit.Months); Date

> observationLagDate =

> ScenarioDate.Subtract(zeroCouponSwapObservationPeriod);

> DateGeneration.Rule backwardDateGeneration =

> DateGeneration.Rule.Backward;

> bool interpolated = false;

> ZeroInflationTermStructureHandle cpiTS = new

> ZeroInflationTermStructureHandle(); ZeroInflationIndex inflationIndex = new

> USCPI(interpolated, cpiTS);

> inflationIndex.addFixing(observationLagDate,

> CurrentReferenceIndexlevel);

> //Zero coupon inflation index swap

> Datum[] zeroCouponInflationIndexSwapData =

> ZeroIndexTermCurve.ToDatumArray(); ZeroHelperVector zeroCouponSwapHelpers =

> ZeroIndexTermCurve.ToZeroHelperVector( inflationIndex,

> zeroCouponSwapObservationPeriod,

> InstrumentCalendar,

> DayCounter);

> double baseZeroRate = zeroCouponInflationIndexSwapData[0].rate /

> 100; BackwardFlat backwardFlat = new BackwardFlat();

> double accuracy = 1.0e-12;

> ZeroInflationTermStructure piecewiseZeroInflation = new

> PiecewiseZeroInflation( ScenarioDate,

> InstrumentCalendar,

> DayCounter,

> zeroCouponSwapObservationPeriod,

> QuantLib.Frequency.Monthly,

> interpolated,

> baseZeroRate,

> _DiscountCurve,

> zeroCouponSwapHelpers,

> accuracy,

> backwardFlat);

> cpiTS = new

> ZeroInflationTermStructureHandle(piecewiseZeroInflation); inflationIndex =

> new USCPI(interpolated, cpiTS);

> List<double> fixedRatesList = new List<double>() { 1, CouponRate

> / 100 }; DoubleVector fixedRates = new DoubleVector(fixedRatesList);

> //Always use actual365fixed ISDA convention for this

> DayCounter fixedDayCount = new Actual365Fixed();

> CPI.InterpolationType observationInterpolation =

> CPI.InterpolationType.Linear; Period couponFrequenceyPeriod = new

> Period(Frequency);

> Schedule fixedSchedule = new Schedule(

> IssueDate,

> MaturityDate,

> couponFrequenceyPeriod,

> InstrumentCalendar,

> _BusinessDayConvention,

> backwardDateGeneration,

> _EndOfMonth);

> CPIBond bond = new CPIBond(

> (uint)SettlementDays,

> NotionalValue,

> GrowthOnly,

> BaseIndex,

> ObservationPeriod,

> inflationIndex,

> observationInterpolation,

> fixedSchedule,

> fixedRates,

> fixedDayCount,

> _BusinessDayConvention,

> IssueDate

> );

> return bond;

> }

> First we create the CpiBond with CreateIndexLinkedBond() then load the

> pricing engine:

> private void LoadPriceEngine()

> {

> PricingEngine engine = new

> DiscountingBondEngine(_DiscountCurve);

> _Bond.setPricingEngine(engine);

> if (_CleanPrice == 0)

> _CleanPrice = _Bond.cleanPrice();

> }

> Methods called from CreateIndexLinkedBond():

> public void LoadCurveValues(Calendar calendar, DayCounter

> dayCounter, Date scenarioDate, bool inludeFirstCurvePoint) {

> List<CurveValue> curveValues = GetAsCurveValues();

> _DayCounter = dayCounter;

> _Calendar = calendar;

> //Curves must be initialized with reference date

> double firstValue = (curveValues.Count > 0) ?

> curveValues[0].Value : 0.0; CurveDates = new List<Date>() { scenarioDate };

> CurveValues = new List<double>() { firstValue };

> int startIndex = inludeFirstCurvePoint ? 0 : 1;

> for (int i = startIndex; i < curveValues.Count(); i++)

> {

> Period months = new Period(curveValues[i].Months,

> TimeUnit.Months); Date itemDate =

> _Calendar.adjust(scenarioDate.Add(months)); CurveDates.Add(itemDate);

> CurveValues.Add(curveValues[i].Value);

> }

> /// <summary>

> /// With good data, this won't be an issue, but defensively we must

> /// ensure that the Maturity Date is included in the curve

> /// </summary>

> public void AdjustCurve(Date maturityDate)

> {

> if (CurveDates.Count > 0)

> {

> Date lastDate = CurveDates[CurveDates.Count - 1];

> double lastValue = CurveValues[CurveValues.Count - 1];

> if (maturityDate.ToDateTime() > lastDate.ToDateTime())

> {

> CurveDates.Add(maturityDate);

> CurveValues.Add(lastValue);

> }

> Thank you,

> Simon

> From: Klaus Spanderen-2 [via QuantLib]

> [mailto:[hidden email]] Sent: Thursday, June 05,

> 2014 5:03 PM

> To: Simon Mazzucca

> Subject: Re: Fwd: pure virtual function call

> Hi Simon,

> thanks for the error report. Case 3 shows that it is actually the observer

> pattern, which is creating the problems for you. (I bet, if you comment out

> the update() methd in case 1 it will also work).

> Unclear now is why the patch does not fix it. Based on your description I

> guess in case 2 your application is facing a dead lock. If I had an exmple

> program then I'd remove boost::mutex::scoped_lock in observable.cpp or I'd

> replace them by boost::recursive_mutex::scoped_lock (and also replace

> boost::mutex by boost::recursive_mutex)

> thanks and regards

> Klaus

> On Thursday, June 05, 2014 08:02:33 AM smazzucca wrote:

> > OK, I think I have something we can work with.

> >

> > I have 3 sets of files:

> >

> > 1) SWIG wrapper for QL 1.3

> >

> > 2) SWIG wrapper for QL 1.4 (patched)

> >

> > 3) SWIG wrapper for QL 1.4 (patched, but with update() method commented

> > out)

> >

> > This is what I get with each:

> >

> > 1) This is my control scenario where I get the "Pure Virtual Function

> > Call"

> >

> > error

> >

> > 2) Contrary to what I said yesterday, I don't actually get the PVFC error,

> >

> > but it's something similar. While the PVFC issue takes down the whole

> >

> > process, this /freezes/ the process. The good news is that in VS I can

> >

> > actually see a bit of what's going on.

> >

> > The "GC Finalizer Thread" is trying to dispose a CPIBond object:

> >

> > ~CPIBond()

> >

> > {

> >

> > Dispose();

> >

> > }

> >

> > Which in turn calls:

> >

> > public override void Dispose()

> >

> > {

> >

> > lock (this)

> >

> > {

> >

> > if (swigCPtr.Handle != IntPtr.Zero)

> >

> > {

> >

> > if (swigCMemOwn)

> >

> > {

> >

> > swigCMemOwn = false;

> >

> > *NQuantLibcPINVOKE.delete_CPIBond(swigCPtr);*

> >

> > }

> >

> > swigCPtr = new HandleRef(null, IntPtr.Zero);

> >

> > }

> >

> > GC.SuppressFinalize(this);

> >

> > base.Dispose();

> >

> > }

> >

> > }

> >

> > The above (from the C# wrapper) gets stuck on the bold line while calling

> >

> > the method below (in the C++ wrapper):

> >

> > SWIGEXPORT void SWIGSTDCALL CSharp_delete_CPIBond(void * jarg1) {

> >

> > CPIBondPtr *arg1 = (CPIBondPtr *) 0 ;

> >

> > arg1 = (CPIBondPtr *)jarg1;

> >

> > {

> >

> > try {

> >

> > delete arg1;

> >

> > } catch (std::out_of_range& e) {

> >

> > {

> >

> > SWIG_CSharpException(SWIG_IndexError, const_cast<char*>(e.what()));

> >

> > return ;

> >

> > };

> >

> > } catch (std::exception& e) {

> >

> > {

> >

> > SWIG_CSharpException(SWIG_RuntimeError,

> >

> > const_cast<char*>(e.what())); return ;

> >

> > };

> >

> > } catch (...) {

> >

> > {

> >

> > SWIG_CSharpException(SWIG_UnknownError, "unknown error"); return ;

> >

> > };

> >

> > }

> >

> > }

> >

> > }

> >

> > 3) Lastly, when I run the version with commented out update(), it all

> >

> > appears to work. I have not checked the numbers themselves, but at least I

> >

> > don't get any errors. I think the only problem is that it appears a bit

> >

> > slow, but I have not actually timed it.

> >

> > As far as converting your test app to C#, I am not sure we should do that

> >

> > yet. The issue might have something to do with how we use QL. I will see

> > if

> >

> > I can isolate my issue in a small app I can send you.

> >

> > Hopefully the above will help you understand what's going on.

> >

> > Thank you,

> >

> > Simon

> >

> > --

> >

> > View this message in context:

> >

> > http://quantlib.10058.n7.nabble.com/pure-virtual-function-call-tp15342p153

> > 9

> >

> > 4.html Sent from the quantlib-users mailing list archive at Nabble.com.

> >

> > --------------------------------------------------------------------------

> > --

> >

> > -- Learn Graph Databases - Download FREE O'Reilly Book

> >

> > "Graph Databases" is the definitive new guide to graph databases and their

> >

> > applications. Written by three acclaimed leaders in the field,

> >

> > this first edition is now available. Download your free book today!

> >

> > http://p.sf.net/sfu/NeoTech

> >

> > _______________________________________________

> >

> > QuantLib-users mailing list

> >

> > [hidden email]</user/SendEmail.jtp?type=node&node=15399&i=0>

> >

> > https://lists.sourceforge.net/lists/listinfo/quantlib-users

> ----------------------------------------------------------------------------

> -- Learn Graph Databases - Download FREE O'Reilly Book

> "Graph Databases" is the definitive new guide to graph databases and their

> applications. Written by three acclaimed leaders in the field,

> this first edition is now available. Download your free book today!

> http://p.sf.net/sfu/NeoTech

> _______________________________________________

> QuantLib-users mailing list

> [hidden email]</user/SendEmail.jtp?type=node&node=15399&i=1>

> https://lists.sourceforge.net/lists/listinfo/quantlib-users

> ________________________________

> If you reply to this email, your message will be added to the discussion

> below:

> http://quantlib.10058.n7.nabble.com/pure-virtual-function-call-tp15342p1539

> 9.html To unsubscribe from pure virtual function call, click

> here<http://quantlib.10058.n7.nabble.com/template/NamlServlet.jtp?macro=uns

> ubscribe_by_code&node=15342&code=c21henp1Y2NhQGNvbmNlcHRvbmVsbGMuY29tfDE1MzQ

> yfC0xNjkyNzM2OTc1>.

> NAML<http://quantlib.10058.n7.nabble.com/template/NamlServlet.jtp?macro=mac

> ro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.

> BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.temp

> late.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-inst

> ant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>

> This e-mail, including its contents and attachments, if any, is confidential

> and is intended only for the addressee. If you are not the intended

> recipient, you are hereby notified that any use, dissemination or

> distribution of this communication is strictly forbidden. If you received

> this e-mail in error please immediately notify the sender and delete or

> destroy this and all copies of this message and all attachments. Any

> unauthorized disclosure, use, distribution, or reproduction of this message

> or any attachments is prohibited and may be unlawful.

> --

> View this message in context:

> http://quantlib.10058.n7.nabble.com/pure-virtual-function-call-tp15342p1541

> 3.html Sent from the quantlib-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

smazzucca

RE: Fwd: pure virtual function call

Klaus,

I did the test and it appears I got the same result (PVFC), but when you have a minute I need you to answer my previous questions to make sure I did right.

1. I’m not sure I follow what you say about the memory leak. Are you saying that even with this new patch, I may get a leak ?

2. Which files in the ZIP file should I update ?

Thanks!

Simon

From: Simon Mazzucca
Sent: Sunday, June 15, 2014 1:47 PM
To: 'Klaus Spanderen-2 [via QuantLib]'
Subject: RE: Fwd: pure virtual function call

Klaus,

If this works it will be game changing for us! I will test tomorrow and let you know.

I’m not sure I follow what you say about the memory leak. Are you saying that even with this new patch, I may get a leak ?

Which files in the ZIP file should I update ?

Thanks,

Simon

From: Klaus Spanderen-2 [via QuantLib] [[hidden email]]
Sent: Sunday, June 15, 2014 10:17 AM
To: Simon Mazzucca
Subject: Re: Fwd: pure virtual function call