From: hlu@luke.eecs.wsu.edu (HJ Lu) Subject: Re: nm bug (binutils-1.9l) Date: 21 Apr 1993 04:39:26 GMT
In article <1r2fk5INNp7b@lynx.unm.edu> cyrus@jemez.eece.unm.edu (W. Tait Cyrus) writes:
>I don't know if this is a GNU bug or a bug that was introduced when
>the binutils were "ported" to Linux.
>
>Anyway I compiled groff-1.07 and was attempting to do some debuging
>and ran:
> nm groff-1.07/libgroff/font.o
>and nm core dumped. I grabbed the src to binutil-1.9l and compiled
>nm with -g. I know where it is core dumping but I don't have the time
>to figure out the why. The where is in binutils-1.9l/cplus-dem.c
>at line 1250, a free. The value sent to free is 0x1b85b which ?appears?
>to be a valid address. The only thing I can think of is the nm overwrote
>part of malloc/free's internal structure causing free to go out to lunch.
There are a few bugs fixed in libc 4.3.3. More bugs are fixed in
the testing release, currently 4.3.3b.
> The function in question is:
> static void
> string_delete (s)
> string *s;
> {
> if (s->b != NULL)
> {
> free (s->b);
> s->b = s->e = s->p = NULL;
> }
> }
>and a print in gdb of *s shows:
> $37 = {b = 0x1b85b "*", p = 0x1b85c "", e = 0x1b87b ""}
>Unfortunately when gdb 'hits' the problem gdb is now out to lunch too
>printing out:
> 000003c8 t scale_round(int, int, int)
>
> Program received signal 11, Segmentation fault
> 0x5a2c in _free_internal ()
> (gdb) bt
> #0 0x5a2c in _free_internal ()
> #1 0x1b000 in _end ()
> #2 0xbb in fprint_name (stream=0xeb80cd00, name=0x1272f7 "") at nm.c:121
> #3 0x1b8 in fprint_name (stream=0x0, name=0x0) at nm.c:121
>
>Is this a GNU bug or a linux port bug and does anyone have any ideas on
>a solution?
>
You didn't say which version of libc you were using. There is a bug
in old malloc which is fixed libc 4.3.3.
H.J.