This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [Cygwin64] dash segfault
On Mar 11 17:16, Peter Rosin wrote:
> On 2013-03-11 16:39, Corinna Vinschen wrote:
> > On Mar 11 15:35, Peter Rosin wrote:
> >> On 2013-03-11 13:32, Corinna Vinschen wrote:
> >>> I've just uploaded a new 64 bit Cygwin DLL package 1.7.18-3. Can you
> >>> please restart testing with this version? I'm trying for about an
> >>> hour to reproduce the problem now, but so far I didn't succeeed, which
> >>> is a good sign, hopefully.
> >>
> >> Good new first, it seems to be less frequent! But there's still
> >> something bad going on, so sorry, no cigar...
> >
> > Too bad. Unfortunately the backtrace is not helpful.
> >
> >> Second, there's the non-crash exit (where dash sometimes exits w/o
> >> triggering error_start, this still happens with -3):
> >> [...]
> >> Third (which I haven't reported previously, but I have seen it with -2 as
> >> well), sometimes gdb gets triggered by error_start, but it fails to attach
> >> to the process. When this happens I see this in the gdb window (after the
> >> boilerplate):
> >>
> >> Reading symbols from /usr/bin/dash.exe...done.
> >> Can't attach to process.
> >> /cygdrive/c/Cygwin/home/peda/ggi/cyg64/ggi/default-shared/47784: No such file or directory.
> >> (gdb)
> >
> > Hmm, maybe the process doesn't exist anymore for some reason.
> >
> >> Lastly, I have a tiny unrelated wishlist request of very low priority.
> >> Could the w32api headers be updated to the latest from the mingw64 repo
> >> the next time there's a gcc update? I had a small patch upstreamed that
> >> will enable me to drop a local workaround. Thanks!
> >
> > I'll see to it for the next rebuild, but right now Mingw HEAD doesn't
> > build for me.
> >
> > Can you please test something for me? Can you please try the files
> >
> > ftp://ftp.cygwin.com/pub/cygwin/64bit/cygwin1.dbg.bz2
> > ftp://ftp.cygwin.com/pub/cygwin/64bit/cygwin1.dll.bz2
> >
> > Bunzip them and install into /bin and try again. I would like to test
> > an assumption.
>
> I got one new symptom, at one point there was this "Hangup" in the
> middle of the output:
>
> checking if we should build filter-save... yes
> checking if we should build filter-tcp... yes
> checking if we should build filter-tile... yes
> Hangup
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating gii/Makefile
>
> Also, later I noticed this in the output:
>
> config.status: creating config.h
> config.status: executing depfiles commands
> Segmentation fault
Any stackdump file?
> config.status: executing libtool commands
> exit status: 0
>
> And then last, but not least, in another configure run:
>
> checking for dlfcn.h... yes
> checking for as... as
> checking for dlltool... (cached) dlltool
> checking for objdump... (cached) objdump
> checking for objdir... .libs
> exit status: 0
>
> (exit status is written by my build script)
>
> But no crashes into gdb yet, should I keep going for one of
> those or did you get sufficient answers?
Just run this DLL for the time being.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat