Re: Statically initialising pthread attributes in dynamic dlls.

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Mon, Feb 22, 2010 at 01:01:38PM +0100, Corinna Vinschen wrote:
>On Feb 22 12:34, Corinna Vinschen wrote:
>> On Feb 22 10:33, Andrew West wrote:
>> > Trying to initialise a pthread attribute in a static variable seems
>> > to cause a segfault. I've attach a simple test case compiled using;
>> > 
>> > g++ -g mutex.cpp -o mutex.dll -lpthread
>> > g++ -g test.cpp -o test.exe -ldl
>> > 
>> > I've cropped the code down to the essential bits, so no error
>> > reporting if it can't find the dll, etc.
>> > 
>> > The only other bits of information I can give which might or might
>> > not be helpful are;
>> > 
>> > 1) Calling pthread_mutexattr_init in a static variable in the
>> > executable works.
>> > 2) If I remove the pthread_mutexattr_init/pthread_mutexattr_destroy
>> > calls it works.
>> > 3) Delaying the pthread_mutexattr_init call until the first time the
>> > Mutex class is used works BUT then the
>> > segfault happens when dlclose is called.
>> > 
>> > I haven't managed to track down the cause of the segfault yet, I'm
>> > getting a bit lost in the debugger :/
>> 
>> I did.
>> 
>> It's the verifyable_object_isvalid() function in thread.cc.  The
>> statement
>> 
>>   if ((*object)->magic != magic)
>> 
>> results in a SEGV since *object is NULL.  That should not be a problem,
>> in theory, since that's what the efault handler should be good for.
>> But for some reason, after this SEGV occured, nothing happens, it just
>> crashes.
>> 
>> Are the constructors called before the exception handling has been
>> set up?  The _cytgtls::handle_exception methid is never called.
>
>Beep!  Wrong answer.  Actually the exception handler is called and
>me.return_from_fault() is called as well.  But for some reason, which
>is beyond me, it doesn't return from return_from_fault().  Instead,
>it steps into the OS and gets terminated.  So there *is* something
>not quite ok with the fault handling in this case.
>
>Btw., I can avoid all the weird effects by changing one single line:
>
>Index: thread.cc
>===================================================================
>RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v
>retrieving revision 1.220
>diff -u -p -r1.220 thread.cc
>--- thread.cc	12 Feb 2010 20:07:13 -0000	1.220
>+++ thread.cc	22 Feb 2010 12:00:37 -0000
>@@ -110,7 +110,7 @@ verifyable_object_isvalid (void const *o
>       (static_ptr2 && *object == static_ptr2) ||
>       (static_ptr3 && *object == static_ptr3))
>     return VALID_STATIC_OBJECT;
>-  if ((*object)->magic != magic)
>+  if (!*object || (*object)->magic != magic)
>     return INVALID_OBJECT;
>   return VALID_OBJECT;
> }
>
>Unfortunately it wouldn't help if the object is mallocated so that
>*object is some random value.

I'll look into it.  I have threads somewhat pulled apart at this point
(heh) so any changes you make will likely conflict with my sandbox.

It wouldn't be a terrible thing to check this for NULL early in the
function since it's a cheap test but we do have to figure out why the
efault handler isn't properly triggering since that would be
catastrophic.

Have you tried regenerating tlsoffsets.h, just in case?

cgf