edmundo@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
l4-hackers@os.inf.tu-dresden.de