On Thu, 2015-03-26 at 08:57 +0000, Richard W.M. Jones wrote:
Is pthread_create used even for the main thread in the process (I
thought the kernel created that). In any case threads aren't being
used explicitly by this process.
Anyway I guess the guard page is just a hole that causes the process
to abort (as observed) and is not a mechanism for automatically
growing the stack.
Right, It's a mechanism for catching stack overflow reliably, rather
than letting it cause random memory corruption.
But for the original stack created by the kernel when the process is
created, I think you just don't have the guard page. All that stops
you is the ulimit.
So... we could potentially look for ways to reduce the stack usage of
OCaml-compiled code, or you get to keep increasing the limit.
It might be worth taking a look at the stack frames and seeing if I
did anything entirely stupid when setting them up, and whether they
can be made smaller. Although if you said it was averaging ~168 bytes,
that doesn't seem *particularly* excessive. Can you see how big the
stack actually does get in your worst case, and how much we'd have to
shrink by in order to get away without tweaking the ulimit?
Perhaps we could also look at using a smaller stack frame between
OCaml functions. If we're never using certain registers in the OCaml
code generator, we don't need to save them or leave space for them on
the stack. All we need to do it ensure that if we're calling out to a C
function, we *do* leave enough space in the stack frame for callee-
saved registers, right?
I concede to being a bit rusty here... :)
--
dwmw2