Re: [boost] Why does boost::thread::thread_start_function havecatch(...)? (Win32)

From: James Talbut (James.Talbut_at_[hidden])
Date: 2008-05-08 08:35:37

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_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Anthony Williams
> Sent: 08 May 2008 09:58
> To: boost_at_[hidden]
> Subject: Re: [boost] Why does 
> boost::thread::thread_start_function havecatch(...)? (Win32)
> 
> "James Talbut" <James.Talbut_at_[hidden]> 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.
________________________________________________________________________