This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Statically initialising pthread attributes in dynamic dlls.
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