Re: Reboots?

[Marcus Brinkmann]

On Sun, Apr 01, 2001 at 03:02:13AM -0400, Roland McGrath wrote:
> > I should mention something. I attached two gdbs, and exited the first one
> > before the second. 
> 
> Ah.  Well I would be unsurprised if that confused things a lot further.
> Obviously this is not a case that matters, but we would like gdb's
> treatment of tasks to be robust and clean in all cases ideally.  It would
> be good to figure out what untoward thing gdb was doing vis a vis suspend
> counts or suchlike.  

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

a couple of time in different threads. First it will get mad at me like
this:

(gdb) print mach_thread_self()

Program received signal EXC_BAD_ACCESS, Could not access memory.
[Switching to thread 78.2]
0x100 in ?? ()
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (__mach_thread_self)
will be abandoned.

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.

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

BTW, Jeff suggested to use glibcs mcheck library in proc to protect against
over- and underruns. I tried it, and it has a real effect on the situation:
It takes *a lot* (two or three times) longer for the binutils build within
the autobuilder to crash proc. If there is some weired malloc interaction,
we probably look at the wrong place entirely.  Uh oh.

Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de