Re: Hurd CVS and X Debugging [Was: Re: Plans for X]
On Tue, Oct 24, 2000 at 02:11:24AM -0400, Roland McGrath wrote:
> > (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.
Curious, because /hurd/mouse wasn't misbehaving at this time. But the
address 0x1 definitely looks wrong. Or are you referring to the rest
of the traceback which I haven't "traced back" yet in the sources?
This seems to be easy enough to reproduce I can do it again to verify.
It may take a few days to get to it though.
I started gdb in /hurd as "gdb mouse", then did "set noninvasive on",
then "attach <mouse pid>", snapped this, detached, waited for problems,
then reattached and snapped the following. I don't think I reverified
the mouse pid in case the translator may have restarted but I can't
imagine that the pid would have been recycled that fast. Next time I
think I'll just stay attached anyway....
>
> > (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.
This was snapped when mouse was sucking 100% cpu. Anything I should look
at/for in particular next time around? Of course, arguments, locals,
and location in bottom proc, anything else?
>
> > Items: need to see if sources for mouse, kbd, and streamdev are in cvs;
>
> They are not. Those are Marcus's hacks.
OK, I guess I'll stick with the released debs for now since I need at
least the kbd and mouse translators for X. No, I just checked, I have
stripped binaries from the 0921 debs so I'll probably rebuild hurd first
from the 20000921.tar.gz in the debian source archive with -g everywhere
and unstripped. Hopefully, then I'll be set up to do debugging properly.
Thanks,
Steve
--
Steve Bowman <sbowman@frostwork.net> (preferred)
Buckeye, AZ <sbowman@goodnet.com> <bowmanc@acm.org>
<http://www.goodnet.com/~sbowman/>
Powered by Debian GNU/Linux and GNU/Hurd <http://www.debian.org>
Reply to: