Re: Statically initialising pthread attributes in dynamic dlls.

2010-02-24 Thread Christopher Faylor
On Wed, Feb 24, 2010 at 05:38:09PM +, Andrew West wrote: >On 24/02/2010 05:26, Dave Korn wrote: >>Yeh, that works nicely. Here's what I tested, along with a couple of >> extra >> test cases I used to check whether exception handling was still working >> before >> and after the dlopen cal

Re: Statically initialising pthread attributes in dynamic dlls.

2010-02-24 Thread Andrew West
On 24/02/2010 05:26, Dave Korn wrote: Yeh, that works nicely. Here's what I tested, along with a couple of extra test cases I used to check whether exception handling was still working before and after the dlopen call. With the current state of HEAD, the first one works (by which I mean "pri

Re: Statically initialising pthread attributes in dynamic dlls.

2010-02-24 Thread Dave Korn
On 24/02/2010 07:23, Christopher Faylor wrote: > > Unless you can show that LoadLibrary isn't smart enough to clean up > after itself in this scenario, I think it's a non-issue. I'll just wait for you to finish reading the thread before I reply! cheers, DaveK -- Problem reports:

Re: Statically initialising pthread attributes in dynamic dlls.

2010-02-23 Thread Christopher Faylor
On Wed, Feb 24, 2010 at 01:39:31AM +, Dave Korn wrote: >On 24/02/2010 00:44, Christopher Faylor wrote: > >> I never saw the cygwin exception handler on the list twice when I was >> debugging this. That isn't supposed to happen and I don't see how it >> could happen unless Windows is doing it s

Re: Statically initialising pthread attributes in dynamic dlls.

2010-02-23 Thread Dave Korn
On 24/02/2010 04:52, Dave Korn wrote: > I think the answer lies here, in this comment in dll_dllcrt0_1: > >> /* Make sure that our exception handler is installed. >> That should always be the case but this just makes sure. >> >> At some point, we may want to just remove this code si

Re: Statically initialising pthread attributes in dynamic dlls.

2010-02-23 Thread Dave Korn
On 24/02/2010 01:39, Dave Korn wrote: > On 24/02/2010 00:44, Christopher Faylor wrote: >> Anyway, I've revisited this code, just like I knew I would, and have >> added YA in a long series of tweaks which seems to fix your particular >> problem. The fix is in the latest snapshot. > > :( I think

Re: Statically initialising pthread attributes in dynamic dlls.

2010-02-23 Thread Dave Korn
On 24/02/2010 00:44, Christopher Faylor wrote: > I never saw the cygwin exception handler on the list twice when I was > debugging this. That isn't supposed to happen and I don't see how it > could happen unless Windows is doing it since the code in > _cygtls::init_exception_handler is supposed t

Re: Statically initialising pthread attributes in dynamic dlls.

2010-02-23 Thread Christopher Faylor
On Tue, Feb 23, 2010 at 05:28:06PM +, Andrew West wrote: >On 23/02/2010 10:00, Andrew West wrote: >> With the code I'm testing against, the exception handler isn't called >> in the library and it bombs out there. :( >> The dll initialisation stuff calls '_cygtls::init_exception_handler' >> bu

Re: Statically initialising pthread attributes in dynamic dlls.

2010-02-23 Thread Dave Korn
On 23/02/2010 17:28, Andrew West wrote: > > Further to this ( possibly instead of this ). When the code reaches this > point inside the call to pthread_mutexattr_init; > > if ((*object)->magic != magic) > > Shouldn't the SEH contain the cytls exception handler as the first item > in the list? I

Re: Statically initialising pthread attributes in dynamic dlls.

2010-02-23 Thread Andrew West
On 23/02/2010 10:00, Andrew West wrote: With the code I'm testing against, the exception handler isn't called in the library and it bombs out there. :( The dll initialisation stuff calls '_cygtls::init_exception_handler' but it doesn't insert it because it finds it's already there ( from test.ex

Re: Statically initialising pthread attributes in dynamic dlls.

2010-02-22 Thread Dave Korn
On 22/02/2010 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 You must have accidentally omitted "-shared" here, since it wouldn't li