X-Spam-Check-By: sourceware.org
Message-ID: <447476F5.3090205@cygwin.com>
Date: Wed, 24 May 2006 11:08:37 -0400
From: "Larry Hall (Cygwin)" <reply-to-list-only-lh AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051223 Fedora/1.5-0.2.fc4.remi Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: 1.15.19 dlopen() dies with no dlerror()
References: <Pine DOT GSO DOT 4 DOT 58 DOT 0604111406110 DOT 24175 AT sue> <4472AF3B DOT 2050300 AT kleckner DOT net> <4473B387 DOT 2020905 AT kleckner DOT net> <4473C5C9 DOT 50104 AT cygwin DOT com> <4473CF07 DOT 9090201 AT kleckner DOT net> <4473D20E DOT 5090507 AT cygwin DOT com> <4473DF11 DOT 6080603 AT kleckner DOT net>
In-Reply-To: <4473DF11.6080603@kleckner.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Jim Kleckner wrote:
> 
> 
> 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?

I think if you follow this thread, your questions will be answered.

<http://cygwin.com/ml/cygwin/2006-05/msg00639.html>

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746

--
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/