Re: more info on boot crash

[Marcus Brinkmann]

On Sun, Jul 28, 2002 at 04:37:09PM -0400, Roland McGrath wrote:
> But note that send-once
> right names are always unique and don't match the receive right name, so
> those don't tell you much.

Ayup, right.

> If in fact what's going on is a random wrong
> reply message then one thing to look at is step through
> __mig_get_reply_port and make sure it's doing the proper thread-local thing.
> 2904 is device_read_reply, which should be cause for suspicion.

We might have a winner.  Here is what I think I might have
found out:

In the thread which does the dir-lookup, the esp is 0x2b5c1.
All the funky __hurd_sigthread_stack_base, __hurd_sigthread_stack_end and
__hurd_sigthread_variables are 0.  So in __hurd_threadvar_location_from_sp,
it boils down to this expression:

 return &((unsigned long int *) ((__stack & __hurd_threadvar_stack_mask)
                                 + __hurd_threadvar_stack_offset))[__index];

Funny though that __hurd_threadvar_stack_mask is 0, too (in all threads, I
think).

It all ends up as __hurd_threadvar_stack_offset[__index].

__hurd_threadvar_stack_offset was 0xbffffeec (for all threads).  As a
pointer to an unsigned int, it contained 33, which, if you remember, was the
port number of the reply port in the device_read message as well.

I set a break point at __mig_get_reply_port and saw 33 all the time, in more
than one thread (I think), but also 91 (might be the mod_refs trick, I got
confused at that point).  From what I saw in gdb, it appeared to me they all
evaluate to the same.  I could not run __hurd_threadvar_location manually in
gdb, it being extern inline, but I will try to run __mig_get_reply_port in
several threads.

If you need to know more, please let me know.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/