> (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.
