Core dump on 32-bit Cygwin if program calls dlopen

Corinna Vinschen
Tue Jul 22 08:27:00 GMT 2014

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:
> > >On Jul 17 06:02, JonY wrote:
> > >>On 7/16/2014 15:02, Corinna Vinschen wrote:
> > >>>On Jul 15 16:39, Corinna Vinschen wrote:
> > >>>>On Jul 15 21:55, JonY wrote:
> > >>>>>On 7/15/2014 21:08, Corinna Vinschen wrote:
> > >>>>>>>
> > >>>>>>>FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
> > >>>>>>
> > >>>>>>JonY, do you have a chance to have a look into this issue?
> > >>>>>
> > >>>>>Sorry, I have been busy these few weeks, but I am well aware that there
> > >>>>>is a problem with one of the libgcc changes, but has yet to investigate it.
> > >>>>>
> > >>>>>I believe Jon Turney has looked into it somewhat.
> > 
> > I think this is the same or a similar problem to the one I reported at [1].
> > I also created a gcc bug [2], with a suggested patch.
> > 
> > >>>>Sounds good.  Thanks in advance.
> > >>>
> > >>>Yesterday I asked my collegues to take a stab at the issue and one of
> > >>>them, DJ Delorie, came up with a libgcc patch already.  It hasn't been
> > >>>sent upstream yet.  Can we give it a try, perhaps by creating a new
> > >>>libgcc DLL, please?
> > >>
> > >>Thanks, I'll get to it this weekend, should I make the new gcc an
> > >>experimental version? Or is just the libgcc binary required?
> > >
> > >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

JonY, can we get a new crtbegin.o with DJ's patch for testing?

I'm not set up to build GCC right now.  It would be cool if we could
get just this single file for testing purposes.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <>

More information about the Cygwin mailing list