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

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?

Yes.  If you look at those functions you will see that e.g.
mach_port_deallocate can never call ports_interrupt_notified_rpcs.

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

Don't use "set noninvasive on" unless you have to.  There should be nothing
else that depends on the mouse translator, so you won't screw yourself by
gdb suspending it in the normal way.  Since in that mode gdb doesn't stop
the process while examining it, you cannot always trust what you see and
generally need to be aware of a lot of intricacies.



Reply to: