L4-Linux on 486

[Michael Hohmuth]

edmundo at rano.demon.co.uk writes:

> (1) The Fiasco assertion about stack space (thread.cc:316) has failed
> several times.

I can reproduce this: Under heavy interrupt load, a thread's kernel
stack can overflow on slow machines.  I'm still thinking about what
the best way is to correct the problem.

> (2) Frequently cc1 segfaults when compiling a large file. Annoyingly,
> it hasn't done it since I built one with debugging symbols.

Maybe this is a symptom of an undetected kernel-stack overflow: When
the kernel accidentally touches user memory, this can lead to
page-fault messages being sent to the thread's pager and the thread
being killed.

> (3) The following C code causes massive strafing[1] of the disc which
> I can terminate only by rebooting as the process seems to ignore all
> signals.
> 
> {
>   unsigned char a[4096*1024];
>   int i;
>   unsigned char c;
> 
>   for (c = 0; ; c++) {
>     for (i = 0; i < sizeof(a); i += 4096)
>       a[i] = c;
>   }
> }
> 
> On one occasion cc1 gave the same behaviour.
> 
> Can anyone tell me if this behaviour is a bug? It might just be a
> "limitation" of L4-Linux, in which I'm in trouble, because it's the
> only nasty behaviour which I can reproduce in a simple way.
> 
> I only have 8 MB of memory, by the way, so the code above is expected
> to exercise the disc. I just don't expect it to be unkillable. A
> program that mallocs lots of 4000-byte blocks doesn't become
> unkillable in the same way.

I'd say the unkillable process is a bug, but the disk thrashing is to
be expected on a low-memory machine.  I'll try reproducing this later
-- I'll tackle the stack-overflow problem first.

Michael
-- 
hohmuth at innocent.com, hohmuth at sax.de
http://www.sax.de/~hohmuth/