Roland McGrath <[EMAIL PROTECTED]> writes:
> That probably indicates some memory clobberation.
> Try linking runttys with -lmcheck.
Here is a more comprehensive backtrace with a debug
version of libc:
#0 0x010b7618 in chunk_free (ar_ptr=0x1186d40, p=0x14) at malloc.c:3224
#1 0x010b731a in chunk_alloc (ar_ptr=0x1186d40, nb=104) at malloc.c:2706
#2 0x010b6b53 in __libc_malloc (bytes=100) at malloc.c:2810
#3 0x08048eab in setup_terminal (t=0x804af50, tt=0x118bbe0)
at ../../../hurd/daemons/runttys.c:100
#4 0x0804901b in add_terminal (tt=0x118bbe0) at ../../../hurd/daemons/runttys.c:130
#5 0x080490be in init_ttys () at ../../../hurd/daemons/runttys.c:158
#6 0x0804971a in main () at ../../../hurd/daemons/runttys.c:406
#7 0x0106d20b in __libc_start_main (main=0x804970c <main>, argc=1,
ubp_av=0x1025c30, init=0x8048a9c <_init>, fini=0x8049b00 <_fini>,
rtld_fini=0xca70 <_dl_fini>, stack_end=0x1025c2c)
at ../sysdeps/generic/libc-start.c:129
It looks like chunk_free is not getting passed a very nice pointer (p).
I tried compiling it with mcheck and it "just works" with that linked
in. No segfaults with that linked it. I am having difficulty finding
good documentation on mcheck to figure out exactly what it is doing.
--
Ryan Golbeck <[EMAIL PROTECTED]>
Computer Science
University Of Waterloo
GPG: 1024D/78916B84
1B1B 2A87 3F00 A7FB 40F3 526D 36CF BA44 7891 6B84
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
