Re: 1.15.19 dlopen() dies with no dlerror()

[Jim Kleckner <jek_subs1 at kleckner dot net>]

Larry Hall (Cygwin) wrote:
> Jim Kleckner wrote:
> > Larry Hall (Cygwin) wrote:
> > > Jim Kleckner wrote:
> > > > Jim Kleckner wrote:
> > > > > Michael McKerns wrote:
> > > > > > Yes, yes...  I've not given you enough information...
> > > > > > ...
> > > > > > See:
> > > > > > http://cygwin.com/cygwin-ug-net/dll.html
> > > > > > http://cygwin.com/faq.html#faq.programming.dll-relocatable
> > > > > >   
> > > > > I'm seeing a similar problem with python and 1.5.19 and also tried 
> > > > > the snapshot of 22-May.
> > > > >
> > > > > CYGWIN_NT-5.1 kleckner2 1.5.20s(0.155/4/2) 20060522 00:51:23 i686 
> > > > > Cygwin
> > > > >
> > > > > A simple test case doesn't fail in dlopen().
> > > > >
> > > > > My code is not simple but has been working prior to the most 
> > > > > recent update (which also updated python and other packages).
> > > > > A downrev of python does not make the problem go away.  If I 
> > > > > downrev cygwin, I get complaints about missing entry points.
> > > > >
> > > > > What do you recommend as the best way to isolate this?
> > > >
> > > > I tried using "prev" with setup.exe but that didn't make the 
> > > > problem go away.
> > > >
> > > > A simple test case with python access to a trivial function works 
> > > > fine (can supply if anyone wants).
> > > > The complex dll that used to work simply doesn't return from dlopen.
> > > >
> > > > I downloaded the 20060522 snapshot with debug symbols to get a 
> > > > backtrace with GDB.
> > > > GDB says there is a seg fault and somehow this is preventing any 
> > > > information from reaching dlerror().
> > > > Without the dlerror() info, it is hard to figure out what needs to 
> > > > change with the dll.
> > > > It appears that some constructors are having trouble.
> > > >
> > > > Let me know if there is some single stepping that could be helpful.
> > > > [snip]
> > > > (gdb) bt
> > > > #0  0x610b1ff8 in pthread_key_create (key=0x6622f8, destructor=0) at 
> > >                     ^^^^^^^^^^^^^^^^^^^
> > > Known issue already fixed in the Cygwin snapshot and in GDB's CVS.  
> > > This
> > > is not fatal.  Just continue until you stop seeing this complaint.
> >
> > As noted above, this was tested using snapshot 20060522. Should that 
> > snapshot have the fix you mention?  If it should, then this problem 
> > still exists in that snapshot.
> > If not, then which one should I test?
>
> The part of the fix that is Cygwin-specific is in the Cygwin snapshot you
> have.  But, like I said, there's another part of the fix that's only in
> GDB's CVS version right now.  If you want to be rid of the problem 
> right now,
> you need both changes and that means you'll need to grab GDB's source 
> from
> CVS and build it.  But whether you choose to do this or not should not
> inhibit your original investigation.  Depending on how many times your
> code path takes you through pthread_ket_create(), it may test test your
> tolerance level for the current work-around though. ;-)
Thanks for pointing me into the GDB and SIGSEGV discussions.
I didn't see the relationship to the dlopen() problem.

I didn't see discussion of a fix to python which has failing
dlopen() calls presumably because of initializations of mutex objects.
Does python need to do what GDB now does?

Is there a workaround/snapshot in the meantime?


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/