Mail Archives: cygwin/2006/05/24/00:21:04
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/
- Raw text -