Re: Reboots?

[Roland McGrath]

> Yes. Well, I now noticed that I could provoke it crashing badly when
> I wait for proc to get E_BAD_ACCESS, and then run
> 
> print mach_thread_self()

Well, that is not surprising.  You are telling gdb to call a function in
the inferior process.  What gdb does to simulate the call is write the
memory locations in the process to push arguments (none here) and return
address (i.e. the thread's current PC value) onto the stack and then change
the thread's PC to the address of the function.  If the stack pointer is
bogus, gdb will be trying to write bad memory.  In the case of this
function, which is a system call taking no arguments, it can manage to
actually make the call and just fault again when it tries to return.

> And at some time (when running mach_thread_self several times in threads
> where the above error already happened) the kernel will panic with
> thread_invoke or thread_dispatch. Seems that there is some
> non-robustness in this area.

Indeed.  It would be ideal if we could isolate the precise sequence of
actions on thread (i.e. thread_{suspend,abort,resume} calls and state changes)
that makes the kernel panic.

> > Well, put it on the list of things to figure out one of these days.  We
> > would like to know what sequence of events confused the kernel so it
> > panicked, and fix the kernel to be robust in the face of such situations.
> 
> Could it be directly related to what makes proc unhappy?

I don't see how.