views:

1465

answers:

4

When in release it crashes with an unhandled exception: std::length error.

The call stack looks like this:

msvcr90.dll!__set_flsgetvalue()  Line 256 + 0xc bytes   C
msvcr90.dll!__set_flsgetvalue()  Line 256 + 0xc bytes   C
msvcr90.dll!_getptd_noexit()  Line 616 + 0x7 bytes  C
msvcr90.dll!_getptd()  Line 641 + 0x5 bytes C
msvcr90.dll!rand()  Line 68 C
NEM.exe!CGAL::Random::Random()  + 0x34 bytes    C++
msvcr90.dll!_initterm(void (void)* * pfbegin=0x00000003, void (void)* * pfend=0x00345560)  Line 903 C
NEM.exe!__tmainCRTStartup()  Line 582 + 0x17 bytes  C
kernel32.dll!7c817067()

Has anyone got any clues?

A: 

Crashes before main() are usually caused by a bad constructor in a global or static variable.

Looks like the constructor for class Random.

Adam Pierce
I´ll check into that random thingy. Its something from a library i´m using.. So if that is the case, it ought to be standard library stuff. Odd..
David Reis
Could you be linking to a debug library in your release build?
Zack Mulgrew
msvcr90.dll isn't msvcr90d.dll so it looks like release. Release builds don't fill some uninitialized memory with known values. The problem might be in the owner (creator) of an object of random type.
Windows programmer
A: 

Do you have a global or static variable of type Random? Is it possible that you're trying to construct it before the library it's in has been properly initialized?

Note that the order of construction of global and static variables is not fixed and might change going from debug to release.

David Norman
+1  A: 

Examining the stack dump:

InitTerm is simply a function that walks a list of other functions and executes each in step - this is used for, amongst other things, global constructors (on startup), global destructors (on shutdown) and atexit lists (also on shutdown).

You are linking with CGAL, since that CGAL::Random::Random in your stack dump is due to the fact that CGAL defines a global variable called default_random of the CGAL::Random::Random type. That's why your error is happening before main, the default_random is being constructed.

From the CGAL source, all it does it call the standard C srand(time(NULL)) followed by the local get_int which, in turn, calls the standard C rand() to get a random number.

However, you're not getting to the second stage since your stack dump is still within srand().

It looks like it's converting your thread into a fiber lazily, i.e., this is the first time you've tried to do something in the thread and it has to set up fiber-local storage before continuing.

So, a couple of things to try and investigate.

1/ Are you running this code on pre-XP? I believe fiber-local storage (__set_flsgetvalue) was introduced in XP. This is a long shot but we need to clear it up anyway.

2/ Do you need to link with CGAL? I'm assuming your application needs something in the CGAL libraries, otherwise don't link with it. It may be a hangover from another project file.

3/ If you do use CGAL, make sure you're using the latest version. As of 3.3, it supports a dynamic linking which should prevent the possibility of mixing different library versions (both static/dynamic and debug/nondebug).

4/ Can you try to compile with VC8? The CGAL supported platforms do NOT yet include VC9 (VS2008). You may need to follow this up with the CGAL team itself to see if they're working on that support.

5/ And, finally, do you have Boost installed? That's another long shot but worth a look anyway.

If none of those suggestions help, you'll have to wait for someone more knowledgable than I to come along, I'm afraid.

Best of luck.

paxdiablo
Yours answer seems helpful. As to your questions:I´m running on XP.I DO use CGAL.Using CGAL 3.3.1Don´t have VC8, unfortunately.I DO have boost and use it on the same program.
David Reis
I downloaded the compiled CGAL libs for VC9 fromthis site http://acg.cs.tau.ac.il/cgal-at-tau/installing-cgal-and-related-programs-on-windows
David Reis
Ah, an external site, not the actual CGAL site. That site has a "contact me" link if there's any problems, have to tried that? In addition, you can try filing a bug report directly with CGAL, see http://www.cgal.org/mailing_list.html. Apologies if you've already done this.
paxdiablo
The CGAL people will probably insist you try it in a supported configuration first to see if it's a real bug or an environment issue.
paxdiablo
A: