boost exception question when threading library header is included.
I am building a small ap to test the ASIO library. I run my test ap and things run as expected. But when I set my IDE options (MSVC 8.0) to trap when an exception is thrown, I get an exception thrown before main(.. is invoked. The call stack looks like: msvcr90d.dll!_CxxThrowException(void * pExceptionObject=0x0012fc3c, const _s__ThrowInfo * pThrowInfo=0x0047f944) Line 161 C++ time_pair.exe!boost::copy_exception<boost::exception_detail::bad_alloc_>(const boost::exception_detail::bad_alloc_ & e={...}) Line 47 C++ time_pair.exe!boost::exception_detail::get_bad_alloc<42>() Line 80 + 0x9f bytes C++ time_pair.exe!`dynamic initializer for 'boost::exception_detail::exception_ptr_bad_alloc<42>::e''() Line 94 + 0x28 bytes C++ msvcr90d.dll!_initterm(void (void)* * pfbegin=0x004743c4, void (void)* * pfend=0x00474758) Line 903 C time_pair.exe!__tmainCRTStartup() Line 497 + 0xf bytes C time_pair.exe!mainCRTStartup() Line 399 C this seems to point an attempt to copy something non_copyable in the boost.exception library. Can anyone help me understand what's going on here and what I should do about it? Here is a small test which you can use to demonstrate the problem #include <boost/thread.hpp> int main(int argc, char * argv[]){ return 0; } Robert Ramey
On Thu, Jun 09, 2011 at 10:25:51PM -0800, Robert Ramey wrote:
I am building a small ap to test the ASIO library. I run my test ap and things run as expected.
But when I set my IDE options (MSVC 8.0) to trap when an exception is thrown, I get an exception thrown before main(.. is invoked. The call stack looks like:
msvcr90d.dll!_CxxThrowException(void * pExceptionObject=0x0012fc3c, const _s__ThrowInfo * pThrowInfo=0x0047f944) Line 161 C++
Did you mean MSVC 9.0 (2008) above? Your symbols say it is.
time_pair.exe!boost::copy_exception<boost::exception_detail::bad_alloc_>(const boost::exception_detail::bad_alloc_ & e={...}) Line 47 C++
time_pair.exe!boost::exception_detail::get_bad_alloc<42>() Line 80 + 0x9f bytes C++
time_pair.exe!`dynamic initializer for 'boost::exception_detail::exception_ptr_bad_alloc<42>::e''() Line 94 + 0x28 bytes C++
msvcr90d.dll!_initterm(void (void)* * pfbegin=0x004743c4, void (void)* * pfend=0x00474758) Line 903 C
time_pair.exe!__tmainCRTStartup() Line 497 + 0xf bytes C
time_pair.exe!mainCRTStartup() Line 399 C
this seems to point an attempt to copy something non_copyable in the boost.exception library.
Can anyone help me understand what's going on here and what I should do about it?
By "trap an exception", do you refer to some capability of breaking when any exception is thrown or just uncaught ones? Exceptions are part of normal C++ life, they do and will occur during the natural execution of programs, no matter what your philosophy on them are. If I configure the IDE to break whenever an exception is thrown and caught, I'd never get anywhere. Does this have any effects that you want to avoid? Do you want someone to investigate why an exception is thrown in the first place? I don't see anything immediately actionable here.
Here is a small test which you can use to demonstrate the problem
#include <boost/thread.hpp> int main(int argc, char * argv[]){ return 0; }
-- Lars Viklund | zao@acc.umu.se
Lars Viklund wrote:
On Thu, Jun 09, 2011 at 10:25:51PM -0800, Robert Ramey wrote:
By "trap an exception", do you refer to some capability of breaking when any exception is thrown or just uncaught ones?
It is my custom when running my projects to set the IDE so it traps in the debugger any time an exception is thrown. Since I only throw and exception when I have an error, this only happens when I have a bug.
Exceptions are part of normal C++ life, they do and will occur during the natural execution of programs, no matter what your philosophy on them are. If I configure the IDE to break whenever an exception is thrown and caught, I'd never get anywhere.
I don't know how to respond to this.
Does this have any effects that you want to avoid? Do you want someone to investigate why an exception is thrown in the first place?
How can just including a header invoke an exception - before main(..) is even called and not have it be a bug?
Here is a small test which you can use to demonstrate the problem
#include <boost/thread.hpp> int main(int argc, char * argv[]){ return 0; }
Where is the bug in the above test program? Robert Ramey
On Fri, Jun 10, 2011 at 08:29:58AM -0800, Robert Ramey wrote:
Lars Viklund wrote:
On Thu, Jun 09, 2011 at 10:25:51PM -0800, Robert Ramey wrote:
By "trap an exception", do you refer to some capability of breaking when any exception is thrown or just uncaught ones?
It is my custom when running my projects to set the IDE so it traps in the debugger any time an exception is thrown. Since I only throw and exception when I have an error, this only happens when I have a bug.
Other people operate according to different creeds. I know of and work in a SDK where the application routinely catches file_not_found exceptions many times during its startup phase, which I consider being well within its right to do. It might be beneficial to submit a feature request to your vendor for narrowing and filtering such things to your own code, as it can probably be a quite useful debugging asset to have when iterating on code.
Exceptions are part of normal C++ life, they do and will occur during the natural execution of programs, no matter what your philosophy on them are. If I configure the IDE to break whenever an exception is thrown and caught, I'd never get anywhere.
I don't know how to respond to this.
Please do not interpret my message as trying to insult you or the way you develop software. If you have a consistent philosophy on when exceptions are warranted, excellent for you. I'm just saying that there are use cases where exceptions are downright essential or are the only way to do something in a feasible way.
Does this have any effects that you want to avoid? Do you want someone to investigate why an exception is thrown in the first place?
How can just including a header invoke an exception - before main(..) is even called and not have it be a bug?
Here is a small test which you can use to demonstrate the problem
#include <boost/thread.hpp> int main(int argc, char * argv[]){ return 0; }
Where is the bug in the above test program?
There is no bug in neither your code nor the Boost.Thread code. The library is very well operating within the standard, assuming that it throws and catches exceptions where allowed. The only reason you notice that implementation detail at all is that you've told your runtime environment to introspect the execution so intrusively. In closing words, I should re-iterate that I mean no offense by my response. I'm just making my standpoint clear and trying to extract any information on what the issue was with the library. As I interpreted it, it could be that you've found that it invoked undefined behaviour by utilizing exceptions too early in the processes, didn't catch the exceptions in all cases, or something of that kind. -- Lars Viklund | zao@acc.umu.se
Lars Viklund wrote:
On Fri, Jun 10, 2011 at 08:29:58AM -0800, Robert Ramey wrote:
There is no bug in neither your code nor the Boost.Thread code. The library is very well operating within the standard, assuming that it throws and catches exceptions where allowed.
well, it doesn't catch them. I don't think the standard says anything about when exceptions are allowed. But really, throwing exceptions before main is called can't be considered acceptable practice since there is no way to catch them.
The only reason you notice that implementation detail at all is that you've told your runtime environment to introspect the execution so intrusively.
which I should be able to do without getting any unwanted side effects.
As I interpreted it, it could be that you've found that it invoked undefined behaviour by utilizing exceptions too early in the processes, didn't catch the exceptions in all cases, or something of that kind.
I can live with that and still call it a bug. Anyway it seems it's been fixed (whether it's a bug or not). Robert Ramey
On Fri, Jun 10, 2011 at 9:29 AM, Robert Ramey <ramey@rrsd.com> wrote:
How can just including a header invoke an exception - before main(..) is even called and not have it be a bug?
Exception != bug. You seem to misunderstand the problem. The library used to throw an exception as part of its initialization, which it catches itself, also as part of its initialization. This turned out to be annoying if you have the IDE break on exceptions, and so in the current version the code was refactored to work without throwing and catching an exception. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Jun 10, 2011, at 2:25 AM, Robert Ramey wrote:
I am building a small ap to test the ASIO library. I run my test ap and things run as expected.
But when I set my IDE options (MSVC 8.0) to trap when an exception is thrown, I get an exception thrown before main(.. is invoked. The call stack looks like:
[... call stack details snipped ...] this seems to point an attempt to copy something non_copyable in the boost.exception library.
Can anyone help me understand what's going on here and what I should do about it?
This also confused me for a while when I first ran into it (on linux, under gdb, using "catch throw"). What I'm seeing is that boost.exception forces a call to its get_bad_alloc() function at static initialization time in an attempt to ensure (early?) once-only initialization of the function scoped static variable within get_bad_alloc. That first call to get_bad_alloc() (at static initialization time) calls copy_exception, which is implemented as a try/catch around a throw of the argument exception, with the catch clause returning the result of current_exception. It is that throw within copy_exception that is tripping the trap on exceptions. Once you recognize that's where you are at, you can safely continue from the trap, let the copy_exception complete, and the application startup proceed. It looks like things are being done differently in this area on trunk and current release branches, but I'm not sure how far back that change goes. (I'm presently using boost 1.43, which is where I looked to figure out what was happening.) So it might be that this annoying behavior has been eliminated in a more recent version of boost (or possibly the next version).
Kim Barrett wrote:
On Jun 10, 2011, at 2:25 AM, Robert Ramey wrote:
It looks like things are being done differently in this area on trunk and current release branches, but I'm not sure how far back that change goes. (I'm presently using boost 1.43, which is where I looked to figure out what was happening.) So it might be that this annoying behavior has been eliminated in a more recent version of boost (or possibly the next version).
Turns out I'm also using boost 1.43 for this project and test. Robert Ramey
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Friday, June 10, 2011 12:32 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] boost exception question when threadinglibrary header is included.
Kim Barrett wrote:
On Jun 10, 2011, at 2:25 AM, Robert Ramey wrote:
It looks like things are being done differently in this area on trunk and current release branches, but I'm not sure how far back that change goes. (I'm presently using boost 1.43, which is where I looked to figure out what was happening.) So it might be that this annoying behavior has been eliminated in a more recent version of boost (or possibly the next version).
Turns out I'm also using boost 1.43 for this project and test.
Robert Ramey
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Take a look at this 2010 thread: <http://lists.boost.org/boost-users/2010/05/58956.php> Appears the author was also using 1.43 and experiencing the same issue. The final response indicates the issue was resolved in 'trunk' which would probably be 1.44 or closely thereafter. Roger
participants (1)
-
Emil Dotchevski -
Kim Barrett -
Lars Viklund -
Robert Ramey -
Roger Stewart