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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Reply via email to