This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Statically initialising pthread attributes in dynamic dlls.
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Mon, 22 Feb 2010 13:01:38 +0100
- Subject: Re: Statically initialising pthread attributes in dynamic dlls.
- References: <4B825D76.6000105@gmail.com> <20100222113416.GR5683@calimero.vinschen.de>
- Reply-to: cygwin-developers at cygwin dot com
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.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat