This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [Cygwin64] dash segfault
Hi Peter,
On Mar 11 11:57, Peter Rosin wrote:
> On 2013-03-11 10:46, Corinna Vinschen wrote:
> > On Mar 11 06:51, Peter Rosin wrote:
> >> Thread 1 (Thread 9636.0xb268):
> >> #0 strlen (str=0x1 <Address 0x1 out of bounds>)
> >> at /usr/src/debug/cygwin-1.7.18-2/newlib/libc/string/strlen.c:68
> >> #1 0x00000001800bf65e in strdup (s=0x1 <Address 0x1 out of bounds>)
> >> at /usr/src/debug/cygwin-1.7.18-2/winsup/cygwin/malloc_wrapper.cc:213
> >
> > This doesn't look like the same problem as the one which crashes in
> > free(). But it might have the same reason. A pointer value of 1
> > indicates that some function returned a NULL pointer but the calling
> > function didn't check the return value. If you still have that in
> > GDB, can you check where the value is coming from?
>
> It's still kicking in GDB, but I'm not sure how I'm going to find out
> where the bogus 1 is coming from? Assuming that frame #5 is correct and
> that it really is at var.c:298, that line is
>
> s = savestr(s);
>
> with s pointing to "old_library=" (0x6ff:fff841c8). savestr is a simple
> wrapper around strdup, so anything replacing that pointer with 1 must
> be coming from some non-obvious place. But it really is weird, because
> the value that is transformed into 1 is passed in ecx and not on the
> stack, so a trashed stack does not explain it (unless the stack is
> trashed in a way that totally fools me).
>
> I need more help to help out with this.
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.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat