Stack Checking in modula3

[demoitem]

Hi,

I was running down a problem with network objects producing a segv on
my linux box and finally discovered that the recursive pickler would
overflow the stack on a linked list of 25 or so items
which was documented in the pickle source. On trying to reproduce the
problem I discovered that it only occurs in a thread (using the
threadposix model) which is not the main. The main thread will
allocate as much stack as you like until you run out of virtual memory.

I was wondering what options there are to give better diagnostics of
stack overflow than simple segv's in an m3 program. Presumably the
pthread model will duplicate the main thread model in allocation of
more stack until vm exhaustion. At that point it would be nice to know
it was a stack problem and hence a probably recursive programming fault
than tracing through the nightmare of possible library bugs.

Regards

Peter

[Olaf Wagner]

demoitem wrote:
> Hi,
>
> I was running down a problem with network objects producing a segv on
> my linux box and finally discovered that the recursive pickler would
> overflow the stack on a linked list of 25 or so items
> which was documented in the pickle source. On trying to reproduce the
> problem I discovered that it only occurs in a thread (using the
> threadposix model) which is not the main. The main thread will
> allocate as much stack as you like until you run out of virtual memory.

Then M3 cannot be blamed, as it simply uses the threads provided by the
operating system environment in this case.

> I was wondering what options there are to give better diagnostics of
> stack overflow than simple segv's in an m3 program. Presumably the
> pthread model will duplicate the main thread model in allocation of
> more stack until vm exhaustion. At that point it would be nice to know
> it was a stack problem and hence a probably recursive programming fault
> than tracing through the nightmare of possible library bugs.

Usually a thread implementation should allocate a guard page at the end
of a thread's stack and protect it via mprotect or an equivalent, so
that the hardware/operating system delivers a signal on a write attempt.
IIRC this was done by the user level thread implementation of M3. This
signal can then be mapped to a meaningful runtime exception. I'm not
sure if this really works in CM3 as I've never tested it.

Olaf

[Riley]

I know this is only a workaround, and you may already know this, but, FWIW:

You can use Thread.SizedClosure instead of Thread.Closure to fork your
thread that the pickling runs on. Then set field stackSize of the closure
before forking. I used 4Meg on i386 and can write a 600K pickle.