Re: Hurd CVS and X Debugging [Was: Re: Plans for X]
> (gdb) where
> #0 0x106914c in evc_wait () from /lib/libc.so.0.2
> #1 0x10697f9 in mach_msg () from /lib/libc.so.0.2
> #2 0x103414b in cproc_block () from /lib/libthreads.so.0.2
> #3 0x103c47c in ports_interrupt_notified_rpcs () from /lib/libports.so.0.2
> #4 0x1069625 in mach_port_deallocate () from /lib/libc.so.0.2
> #5 0x103be07 in ports_do_mach_notify_dead_name () from /lib/libports.so.0.2
> #6 0x103ce93 in _ports_record_interruption () from /lib/libports.so.0.2
> #7 0x103cf17 in ports_notify_server () from /lib/libports.so.0.2
> #8 0x103aa8d in ports_end_rpc () from /lib/libports.so.0.2
> #9 0x103ae15 in ports_manage_port_operations_one_thread ()
> from /lib/libports.so.0.2
> Cannot access memory at address 0x1.
This is bogus. You have the wrong symbols for the binary in question, or
else the stack is just clobbered.
> (gdb) where
> #0 0x106914c in evc_wait () from /lib/libc.so.0.2
> #1 0x10697f9 in mach_msg () from /lib/libc.so.0.2
> #2 0x103414b in cproc_block () from /lib/libthreads.so.0.2
> #3 0x10348aa in __mutex_lock_solid () from /lib/libthreads.so.0.2
> #4 0x80494c5 in trivfs_goaway ()
> #5 0x102adef in trivfs_open () from /lib/libtrivfs.so.0.2
> #6 0x10279ab in trivfs_S_fsys_getroot () from /lib/libtrivfs.so.0.2
> #7 0x1027cab in trivfs_S_fsys_syncfs () from /lib/libtrivfs.so.0.2
> #8 0x10285d9 in trivfs_fsys_server () from /lib/libtrivfs.so.0.2
> #9 0x1024d63 in trivfs_demuxer () from /lib/libtrivfs.so.0.2
> #10 0x103ae03 in ports_manage_port_operations_one_thread ()
> from /lib/libports.so.0.2
> #11 0x1069d3a in mach_msg_server_timeout () from /lib/libc.so.0.2
> #12 0x103aee6 in ports_manage_port_operations_one_thread ()
> from /lib/libports.so.0.2
> #13 0x10356ba in cthread_body () from /lib/libthreads.so.0.2
> (gdb) kill
> Kill the program being debugged? (y or n) y
This one looks plausible.
> Items: need to see if sources for mouse, kbd, and streamdev are in cvs;
They are not. Those are Marcus's hacks.
Reply to: