Boost 1.43 - Exception before main() is called
I recently upgrade from boost 1.42 to 1.43. All of a sudden, the project I
was working on seems to be throwing an exception before main() is called. I
was able to reproduce this error in the example below. Using 1.42, it
executes just fine. Using 1.43, an exception is thrown before main is
reached.
In some of my classes, I have a static mutex variable that I lock before I
manipulate other static variables in the class (as seen below).
main.cpp - Start
#include "Test.hpp"
int main()
{
Test test;
return 0;
}
main.cpp - End
Test.hpp - Start
#ifndef DEFINE_TEST_HPP
#define DEFINE_TEST_HPP
#include
BoostTest.exe!boost::copy_exceptionboost::exception_detail::bad_alloc_( const boost::exception_detail::bad_alloc_ & e) Line 47 C++
BoostTest.exe!boost::exception_detail::get_bad_alloc<42>() Line 80 + 0x9f bytes C++ BoostTest.exe!`dynamic initializer for 'boost::exception_detail::exception_ptr_bad_alloc<42>::e''() Line 94 + 0x28 bytes C++ msvcr100d.dll!_initterm(void (void)* * pfbegin, void (void)* * pfend) Line 873 C BoostTest.exe!__tmainCRTStartup() Line 473 + 0xf bytes C BoostTest.exe!mainCRTStartup() Line 371 C kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes Did something change between 1.42 and 1.43 that would cause this? -Rob Yull
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 12 May 2010, Rob Yull wrote:
I recently upgrade from boost 1.42 to 1.43. All of a sudden, the project I was working on seems to be throwing an exception before main() is called. I was able to reproduce this error in the example below. Using 1.42, it executes just fine. Using 1.43, an exception is thrown before main is reached.
I would guess you are trying to lock the static mutex before its constructor has run. I believe the only guarantee C++ provides wrt static initialization order is that POD types will be initialized before non-POD types. This link might be helpful: http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkvqxysACgkQ5vihyNWuA4WNFACgyGsUNhd4no488HdfTyQ82AVE +bwAn14bax0UTbNMd7KhwO75FIG9mMpn =g847 -----END PGP SIGNATURE-----
That was one of the first thoughts that I had. In my included example, the first time I try to lock the mutex is in the class constructor. The class's constructor (where the mutex is locked for the first time) isn't called until after main() is (thought this may lead to a problem if the Test instance was also declared as a static or global). So I would think that any static initialization should be complete by the time the class instance is created. (correct me if I'm wrong here). -Rob Yull -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Frank Mori Hess Sent: Wednesday, May 12, 2010 11:20 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Boost 1.43 - Exception before main() is called -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 12 May 2010, Rob Yull wrote:
I recently upgrade from boost 1.42 to 1.43. All of a sudden, the project I was working on seems to be throwing an exception before main() is called. I was able to reproduce this error in the example below. Using 1.42, it executes just fine. Using 1.43, an exception is thrown before main is reached.
I would guess you are trying to lock the static mutex before its constructor has run. I believe the only guarantee C++ provides wrt static initialization order is that POD types will be initialized before non-POD types. This link might be helpful: http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkvqxysACgkQ5vihyNWuA4WNFACgyGsUNhd4no488HdfTyQ82AVE +bwAn14bax0UTbNMd7KhwO75FIG9mMpn =g847 -----END PGP SIGNATURE----- _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Wed, May 12, 2010 at 7:13 AM, Rob Yull
The call stack (>>> is where the exception is caught).
KernelBase.dll!_RaiseException@16() + 0x58 bytes
msvcr100d.dll!_CxxThrowException(void * pExceptionObject, const _s__ThrowInfo * pThrowInfo) Line 157 C++
BoostTest.exe!boost::copy_exceptionboost::exception_detail::bad_alloc_(const boost::exception_detail::bad_alloc_ & e) Line 47 C++
BoostTest.exe!boost::exception_detail::get_bad_alloc<42>() Line 80 + 0x9f bytes C++
BoostTest.exe!`dynamic initializer for 'boost::exception_detail::exception_ptr_bad_alloc<42>::e''() Line 94 + 0x28 bytes C++
msvcr100d.dll!_initterm(void (void)* * pfbegin, void (void)* * pfend) Line 873 C
BoostTest.exe!__tmainCRTStartup() Line 473 + 0xf bytes C
BoostTest.exe!mainCRTStartup() Line 371 C
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
Did something change between 1.42 and 1.43 that would cause this?
May be related to changes I made in Boost Exception however I can't reporduce the crash with the latest trunk revision an MSVC 9. Anything more specific you can add? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Wed, May 12, 2010 at 7:13 AM, Rob Yull
The call stack (>>> is where the exception is caught).
KernelBase.dll!_RaiseException@16() + 0x58 bytes
msvcr100d.dll!_CxxThrowException(void * pExceptionObject, const _s__ThrowInfo * pThrowInfo) Line 157 C++
BoostTest.exe!boost::copy_exceptionboost::exception_detail::bad_alloc_ (const boost::exception_detail::bad_alloc_ & e) Line 47 C++
BoostTest.exe!boost::exception_detail::get_bad_alloc<42>() Line 80 + 0x9f bytes C++
BoostTest.exe!`dynamic initializer for 'boost::exception_detail::exception_ptr_bad_alloc<42>::e''() Line 94 + 0x28 bytes C++
msvcr100d.dll!_initterm(void (void)* * pfbegin, void (void)* * pfend) Line 873 C
BoostTest.exe!__tmainCRTStartup() Line 473 + 0xf bytes C
BoostTest.exe!mainCRTStartup() Line 371 C
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
Did something change between 1.42 and 1.43 that would cause this?
May be related to changes I made in Boost Exception however I can't reporduce the crash with the latest trunk revision an MSVC 9. Anything more specific you can add?
I do have my compilers (VC2005 Pro and VC 2010 Express) set to break on exceptions, which is how I really first noticed it (though it does show up in the output window along with all of the loaded symbols as well). When the debugger halts, it does look like hitting continue doesn't break execution. There may be a try/catch block somewhere handling it, so it might be something ignorable (just annoying). I guess the better way to say it is at some point during the static initialization, boost 1.43 is throwing a bad_alloc for some reason, but may be handling it. -Rob Yull
On Wed, May 12, 2010 at 1:08 PM, Rob Yull
Did something change between 1.42 and 1.43 that would cause this?
May be related to changes I made in Boost Exception however I can't reporduce the crash with the latest trunk revision an MSVC 9. Anything more specific you can add?
I do have my compilers (VC2005 Pro and VC 2010 Express) set to break on exceptions
Oh I see. Well, this behavior is by design, it does not indicate a failure. I understand that this is a problem for the "break when exceptions are thrown" option. Will fix, but feel free to submit a trac ticket just in case. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Wed, May 12, 2010 at 1:08 PM, Rob Yull
wrote: Did something change between 1.42 and 1.43 that would cause this? May be related to changes I made in Boost Exception however I can't reporduce the crash with the latest trunk revision an MSVC 9. Anything more specific you can add? I do have my compilers (VC2005 Pro and VC 2010 Express) set to break on exceptions
Oh I see. Well, this behavior is by design, it does not indicate a failure.
I understand that this is a problem for the "break when exceptions are thrown" option. Will fix, but feel free to submit a trac ticket just in case.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
I am also experiencing this somewhat annoying issue. Was a trac ticket ever created?
On Tue, Jun 1, 2010 at 11:06 AM, Kenny Riddile
Emil Dotchevski wrote:
On Wed, May 12, 2010 at 1:08 PM, Rob Yull
wrote: Did something change between 1.42 and 1.43 that would cause this? May be related to changes I made in Boost Exception however I can't reporduce the crash with the latest trunk revision an MSVC 9. Anything more specific you can add?
I do have my compilers (VC2005 Pro and VC 2010 Express) set to break on exceptions
Oh I see. Well, this behavior is by design, it does not indicate a failure.
I understand that this is a problem for the "break when exceptions are thrown" option. Will fix, but feel free to submit a trac ticket just in case.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
I am also experiencing this somewhat annoying issue. Was a trac ticket ever created?
Yes and it was closed soon after. The problem is fixed in trunk, I apologize for the inconvenience. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
Yes and it was closed soon after. The problem is fixed in trunk, I apologize for the inconvenience. :)
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Not a problem...It's not like I would complain about a minor annoyance in a quality, free library anyways :)
participants (4)
-
Emil Dotchevski
-
Frank Mori Hess
-
Kenny Riddile
-
Rob Yull