Why does boost::thread::thread_start_function have catch(...)? (Win32)
By calling std::terminate in the catch handler we lose the JIT debugger - and thus information about what the exception is that we haven't caught. Without the catch the process is still going to be killed, so what's the benefit of having that? Thanks. Jim P Consider the environment. Please don't print this email. ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________
On Thursday 01 May 2008 13:23:35 James Talbut wrote:
By calling std::terminate in the catch handler we lose the JIT debugger - and thus information about what the exception is that we haven't caught. Without the catch the process is still going to be killed, so what's the benefit of having that?
Probably because not all implementations can allow threads to exit properly with an exception (since that is an area completely uncovered by the current C++ standard, along with threading in general). But I agree, that where possible it should not have a catch(...) and it should behave like exiting from main() with an exception behaves (and if your implementation does not make this behaviour the same then bad luck). -- Mihai RUSU Email: dizzy@roedu.net "Linux is obsolete" -- AST
Mind if I add this as a bug against thread? Jim
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of dizzy Sent: 02 May 2008 08:15 To: boost@lists.boost.org Subject: Re: [boost] Why does boost::thread::thread_start_function havecatch(...)? (Win32)
On Thursday 01 May 2008 13:23:35 James Talbut wrote:
By calling std::terminate in the catch handler we lose the JIT debugger - and thus information about what the exception is that we haven't caught. Without the catch the process is still going to be killed, so what's the benefit of having that?
Probably because not all implementations can allow threads to exit properly with an exception (since that is an area completely uncovered by the current C++ standard, along with threading in general). But I agree, that where possible it should not have a catch(...) and it should behave like exiting from main() with an exception behaves (and if your implementation does not make this behaviour the same then bad luck).
-- Mihai RUSU Email: dizzy@roedu.net "Linux is obsolete" -- AST _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________
"James Talbut" <James.Talbut@omg3d.com> writes:
Mind if I add this as a bug against thread?
It's not a bug. It works as intended. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
"James Talbut" <James.Talbut@omg3d.com> writes:
By calling std::terminate in the catch handler we lose the JIT debugger - and thus information about what the exception is that we haven't caught. Without the catch the process is still going to be killed, so what's the benefit of having that?
It's not specified in either the pthreads docs or the Windows docs what happens if the thread function leaks an exception, since these are C APIs. Depending on the compiler/platform a leaked exception in a thread may either just terminate the thread, may terminate the whole process, or may cause undefined behaviour. I know that some platforms don't support exceptions in C stack frames, and will throw a wobbly. By catching the exception and calling terminate(), the thread library makes it explicit that this is an error. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
The Windows docs do specify what happens with an uncaught exception: http://msdn.microsoft.com/en-us/library/ac9f67ah(VS.80).aspx And this document implies (very strongly, IMO) that this applies on any thread (given that it states that terminating the current thread is a viable option). Similarly the docs for set_terminate state that is operates on multiple threads: http://msdn.microsoft.com/en-us/library/t6fk7h29(VS.80).aspx The MS implementation of C++ exceptions is directly based on SEH, and the behaviour of uncaught SEH is well defined. Have to admit I'm not sure it's actually defined to be based on SEH though. There are also big problems with using catch(...) with VC if anyone makes attempts to handle SEH exceptions as C++ exceptions (and boost::test requires us to do this :( ). I know that I'm asking for a platform specific change, but the pain of this catch on Windows is quite significant. As a trivial example: DWORD WINAPI ThreadProc( LPVOID lpParameter ) { throw 14; } void function() { throw 14; } int main(int argc, char * argv[]) { // Comment out one or the other, so much easier than command line args CreateThread( NULL, 0, ThreadProc, NULL, 0, NULL ); //boost::thread t( function ); Sleep( 1000000 ); } With the native call I get straight into the JIT handler, and windbg can report the line calling "throw 14". With the boost::thread call I get told that the application has requested that it be terminated in an unusual way - and the debugger knows nothing about my exception. Jim
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Anthony Williams Sent: 08 May 2008 09:58 To: boost@lists.boost.org Subject: Re: [boost] Why does boost::thread::thread_start_function havecatch(...)? (Win32)
"James Talbut" <James.Talbut@omg3d.com> writes:
By calling std::terminate in the catch handler we lose the JIT debugger - and thus information about what the exception is that we haven't caught. Without the catch the process is still going to be killed, so what's the benefit of having that?
It's not specified in either the pthreads docs or the Windows docs what happens if the thread function leaks an exception, since these are C APIs. Depending on the compiler/platform a leaked exception in a thread may either just terminate the thread, may terminate the whole process, or may cause undefined behaviour. I know that some platforms don't support exceptions in C stack frames, and will throw a wobbly.
By catching the exception and calling terminate(), the thread library makes it explicit that this is an error.
Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________
"James Talbut" <James.Talbut@omg3d.com> writes:
The Windows docs do specify what happens with an uncaught exception: http://msdn.microsoft.com/en-us/library/ac9f67ah(VS.80).aspx And this document implies (very strongly, IMO) that this applies on any thread (given that it states that terminating the current thread is a viable option). Similarly the docs for set_terminate state that is operates on multiple threads: http://msdn.microsoft.com/en-us/library/t6fk7h29(VS.80).aspx
Those are the Microsoft compiler docs for Visual Studio 8. They don't apply to e.g. Borland or gcc or Digital Mars compilers on Windows. In the current working draft of C++0x, the terminate_handler passed to set_terminate must still terminate execution of the program, even though multiple threads are now permitted. If Microsoft continues to allow termination of just that thread this is non-conforming.
I know that I'm asking for a platform specific change, but the pain of this catch on Windows is quite significant.
As a trivial example: DWORD WINAPI ThreadProc( LPVOID lpParameter ) { throw 14; }
void function() { throw 14; }
int main(int argc, char * argv[]) { // Comment out one or the other, so much easier than command line args CreateThread( NULL, 0, ThreadProc, NULL, 0, NULL ); //boost::thread t( function );
Sleep( 1000000 ); }
With the native call I get straight into the JIT handler, and windbg can report the line calling "throw 14". With the boost::thread call I get told that the application has requested that it be terminated in an unusual way - and the debugger knows nothing about my exception.
I agree that this can be useful, but you could always run your app in a debugger and trap exceptions, or add a SEH filter to the top-level thread function to trigger the debugger. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
participants (3)
-
Anthony Williams -
dizzy -
James Talbut