debug vs. relaease bahavior of QuantLib code?

[JURAJ HUSKA]

Hello all,

I ran into a debug vs. release problem using QuantLib code, it will most likely be my (programming related) error but I wonder if anyone has had similar experience and a way to fix it.

I added some classes to QuantLib and used them along with the existing QuantLib code to program some functions which reside in a solution that compiles to a .dll. When I compile this dll in debug mode and run it everything seems to be fine (I stepped through the code line by line several times... took hours) and the application (.exe file) using it produces constistent results. When, however, I compile the dll in release mode and run it from  the executable I get results which look more like a random sequence of numbers. Let's say I price the same exact bond using one of the functions from the dll 100 times in a for loop. It may happen that I get 80 times the correct result and 20 times various other results (no exceptions thrown though); the "wrong" numbers seem unrelated (but not out of range for a "double" type) and they are interspersed throughout the sequence without any pattern. when I repeat the same experiment the good and wrong numbers are appearing completely randomly (it seems).

Could it be some project setting that needs to be set in release mode? (run-time checks etc.) Is there anything of static type (evaluation date) that one has to worry about when using QuantLib (note, I am not touching eval date in my calcs at all).  If someone is interested I can provide the code too (but it's not very short).

Juraj

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[JURAJ HUSKA]

Hello all,

I ran into a debug vs. release problem using QuantLib code, it will most likely be my (programming related) error but I wonder if anyone has had similar experience and a way to fix it.

I added some classes to QuantLib and used them along with the existing QuantLib code to program some functions which reside in a solution that compiles to a .dll. When I compile this dll in debug mode and run it everything seems to be fine (I stepped through the code line by line several times... took hours) and the application (.exe file) using it produces constistent results. When, however, I compile the dll in release mode and run it from  the executable I get results which look more like a random sequence of numbers. Let's say I price the same exact bond using one of the functions from the dll 100 times in a for loop. It may happen that I get 80 times the correct result and 20 times various other results (no exceptions thrown though); the "wrong" numbers seem unrelated (but not out of range for a "double" type) and they are interspersed throughout the sequence without any pattern. when I repeat the same experiment the good and wrong numbers are appearing completely randomly (it seems).

Could it be some project setting that needs to be set in release mode? (run-time checks etc.) Is there anything of static type (evaluation date) that one has to worry about when using QuantLib (note, I am not touching eval date in my calcs at all).  If someone is interested I can provide the code too (but it's not very short).

Juraj

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Eric Ehlers-2]

Hi Juraj,

> I ran into a debug vs. release problem using QuantLib code, it will most
> likely be my (programming related) error but I wonder if anyone has had
> similar experience and a way to fix it.

In Debug build, all variables are initialized to zero.  In the Release
build they aren't and any variable that is not explicitly initialized by
your code will have an undefined value.  When an application malfunctions
in Release and not in Debug, a common cause is that the code neglects to
initialize a variable, but then assumes that the variable has a null
value.

You can modify the Release build to include debug information.  This does
not cause variables to be initialized, so hopefully you will get a build
that still exhibits the problem behavior but can be debugged.  This would
allow you to debug the Debug and Release configurations side by side and
establish where their behaviors diverge.

Regards,
Eric



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[JURAJ HUSKA]

Thanks Eric,

I did find my error following your suggestion. In the end it came down to an UGLY error represented in the following symbolic code:

double time = someNumberDependingOnPreviousCode;

for(Size i=outsideArray.size()-1; i>=0;i--)
{
    if( outsideSTLVector[i] > time )
     {
         manipulate some numbers to be used outside this for loop;
     }
     else
          break;
}


The problem is two-fold in the above code, which makes it work in debug mode but not in release. (Can you find it quick without reading below?:-)).


The first catch is that the loop variable is of type QuantLib:Size, which is just a typedef for an unsigned int. When it happens that "time = 0" and outsideArray[i] >0 for all "i" in the relevant range, then the for loop keeps running all the way down to i=0, then decrements "i" from this zero value, which for an unsigned int happens to produce (on my computer) 4294967295 and then it tests the loop condition that is now happily satisfied due to the large value of "i". Thus it enters the loop again and now tries to access "outsideSTLVector[4294967295]" in the if condition. Now comes the second catch. In the debug mode this evaluates to a garbage value of, roughly,  "-7.845 e+298" so a negative number which makes the if condition false (since time = 0) and the break then forces execution of out the loop without mangling up the numbers manipulated inside the if. In the release mode, however, the garbage value happens to be roughly outsideSTLVector[4294967295] = 2.189 e-303 (>0) so the if condition is satisfied and hell breaks loose... 

Anyway, bottom line is, this was a trivial programming error which cost me a loooooot of time (it just happened that I stepped through the loop hundreds of times but the "right" circumstances for it to go wrong only happened once in the entire run of the program...).

nice weekend to QuantLib users,

Juraj

On Fri, Feb 22, 2008 at 5:23 AM, Eric Ehlers <[hidden email]> wrote:

Hi Juraj,

> I ran into a debug vs. release problem using QuantLib code, it will most
> likely be my (programming related) error but I wonder if anyone has had
> similar experience and a way to fix it.

In Debug build, all variables are initialized to zero.  In the Release
build they aren't and any variable that is not explicitly initialized by
your code will have an undefined value.  When an application malfunctions
in Release and not in Debug, a common cause is that the code neglects to
initialize a variable, but then assumes that the variable has a null
value.

You can modify the Release build to include debug information.  This does
not cause variables to be initialized, so hopefully you will get a build
that still exhibits the problem behavior but can be debugged.  This would
allow you to debug the Debug and Release configurations side by side and
establish where their behaviors diverge.

Regards,
Eric

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Eric Ehlers-2]

Hi Juraj,

> Thanks Eric,
>
> I did find my error following your suggestion. In the end it came down to
> an
> UGLY error represented in the following symbolic code:
>
> double time = someNumberDependingOnPreviousCode;
>
> for(Size i=outsideArray.size()-1; i>=0;i--)
> {
>     if( outsideSTLVector[i] > time )
>      {
>          manipulate some numbers to be used outside this for loop;
>      }
>      else
>           break;
> }
>
>
> The problem is two-fold in the above code, which makes it work in debug
> mode
> but not in release. (Can you find it quick without reading below?:-)).
>
>
> The first catch is that the loop variable is of type QuantLib:Size, which
> is
> just a typedef for an unsigned int. When it happens that "time = 0" and
> outsideArray[i] >0 for all "i" in the relevant range, then the for loop
> keeps running all the way down to i=0, then decrements "i" from this zero
> value, which for an unsigned int happens to produce (on my computer)
> 4294967295 and then it tests the loop condition that is now happily
> satisfied due to the large value of "i". Thus it enters the loop again and
> now tries to access "outsideSTLVector[4294967295]" in the if condition.
> Now
> comes the second catch. In the debug mode this evaluates to a garbage
> value
> of, roughly,  "-7.845 e+298" so a negative number which makes the if
> condition false (since time = 0) and the break then forces execution of
> out
> the loop without mangling up the numbers manipulated inside the if. In the
> release mode, however, the garbage value happens to be roughly
> outsideSTLVector[4294967295] = 2.189 e-303 (>0) so the if condition is
> satisfied and hell breaks loose...
>
> Anyway, bottom line is, this was a trivial programming error which cost me
> a
> loooooot of time (it just happened that I stepped through the loop
> hundreds
> of times but the "right" circumstances for it to go wrong only happened
> once
> in the entire run of the program...).
>
> nice weekend to QuantLib users,
>
> Juraj

I'm surprised that outsideSTLVector[4294967295] returns garbage - I would
expect instead in both Debug and Release that statement would cause the
app to crash on an attempt to access a subscript that is presumably out of
range.  No matter, I'm sure I'm missing something trivial, very glad to
hear you worked it out!

Happy rest of weekend to you too.

Regards,
Eric



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users