by Olaf Wagner <wagner@[EMAIL PROTECTED]
>
Oct 9, 2006 at 08:13 AM
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 do***ented 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
