[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proc failure with gcc-2.95.2

> OK, a small step for you, but a giant leap for me.

Your leaping is just fine. :-)

> # gdb   /hurd/proc   95
> GNU gdb 19990928
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-unknown-gnu0.2"...
> /home/cal/95: No such file or directory.
> Attaching to program `/hurd/proc', pid 95
> warning: Can't modify tracing state for pid 95: No signal thread
> fetch inferior registers: 1: Invalid thread
>                                                                             ###
> After return from screen 1
> (gdb) list

This is never that useful a command.  Do `info threads' here.

> (gdb) cont
> Continuing.
> warning: Can't wait for pid 95: No child processes
> Breakpoint 1, main (argc=134529024, argv=0x1, envp=0x11affa8)
>     at ../../proc/main.c:64
> 64        struct argp argp = { 0, 0, 0, "Hurd process server" };
> (gdb) cont
> Continuing.
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> 0x11738f8 in ?? () from /lib/libmachuser.so.1
> (gdb) cont

Here you can see the crash, and continuing just lets it continue to crash.
If you'd done `info regs' and `bt' here I might have enough information to
figure out the situation.  Another thing you can try (don't try this first,
let's get the info from the bt as it is first) is `info shared' to see if
it is getting the shared library info properly.  If it is, then you can use
the `shared' command to load the symbols for the libraries.  If your
sub-hurd is not using your native hurd's /lib, then you should use 
`set solib-absolute-prefix' and/or `set solib-search-path' to tell it where
to find the libraries.

Reply to: