#48 Testsuite crashes with JSON_MEMORY_POOL under mingw32

[Pat Le Cat]

I have Windows7 32bit and use mingw32 4.6.2. I compiled libjson for C++ switched several compiler flags on and off and found out that the JSON_MEMORY_POOL can be compiled in the library and Testsuite, but once I run the testapp.exe it simply crashes (no error code). I use msys to build libjson, it doesn't work with pure mingw under the Windows shell.

[Jonathan Wallace]

Can you give me a backtrace or a valgrind trace?

[Pat Le Cat]

No like I said it's mingw on Win7, there are no such tools there. (sorry but I can't add a comment otherwise!)

[Jonathan Wallace]

If you run it with gdb, what happens? It should provide a backtrace, I know gdb has been ported to mingw.

[Anonymous]

The same crash happens with MSVC v16 (VS2010). I ran it in the debugger and discovered that it is caused by an uninitialized global variable, specifically it is bucket_pool_8<...> json_generic_mempool declared in JSONMemory.cpp. The constructor for this variable hasn't been called yet when another global variable is constructed and triggers an allocation.
In general, C++ doesn't make any guarantees about the order of execution of static constructors that are in different compilation units. See this thread for more info: http://stackoverflow.com/questions/211237/static-variables-initialisation-order. Gcc has an init_priority attribute that could help, but that is of course not portable. A better fix might be a referenced-counted initializer like cin, cout use - this page has an example: http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Nifty_Counter.

[Anonymous]

This seems to be related to the problem in issue 3531017, except with constructors instead of destructors. Maybe if all of the global/static declarations could be put into just one cpp file then you could guarantee the order that constructors/destructors would be invoked.