Core dump on 32-bit Cygwin if program calls dlopen

[Jon TURNEY]

On 22/07/2014 09:27, Corinna Vinschen wrote:
> On Jul 17 20:24, Corinna Vinschen wrote:
>> On Jul 17 16:31, Jon TURNEY wrote:
>>> On 17/07/2014 08:37, Corinna Vinschen wrote:
>>>> It's the libgcc DLL which gives us grief, so a new libgcc package is
>>>> sufficent, afaics.  We should check if this DLL fixes the problem and
>>>> then make it "curr" soon, I think.
>>>
>>> I briefly tested this other patch with my test case from the mail above, and
>>> it doesn't seem to help.
>>> [...]
>> I asked DJ to take another look, but I guess ultimately we need the
>> attention of one of the GCC Windows maintainers.  Kai Tietz seems to be
>> unavailable right now, unfortunately.
>
> Looks like I totally misunderstood DJ's patch.  The patch does *not*
> change libgcc, it changes cygmin-crtbegin.c, thus the crtbegin.o file
> which is statically linked into the executable.
>
> That means, to fix the issue, you don't have to replace libgcc, you
> have to recompile the executable against the new crtbegin.o.
>
> DJ still claims his patch is the correct one.  The simple testcase
> dlopen'ing cyggs-9.dll works fine with the new crtbegin.o, according to
> him.

Sorry, I hadn't tested it correctly.

Building my test with an updated crtbegin.o as well, my test case is fixed.

I agree this patch seems better than my suggested one, as it makes 
crtbegin do the right thing in the face of unbalanced libgcc 
load/unload, rather than attempting to balance the libgcc load/unload as 
mine does.


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