On Wed, Mar 25, 2015 at 08:03:31PM +0000, David Woodhouse wrote:
On Wed, 2015-03-25 at 19:45 +0000, Richard W.M. Jones wrote:
> On Wed, Mar 25, 2015 at 06:30:25PM +0000, David Woodhouse wrote:
> > If the compiler is single-threaded, and increasing the stack ulimit
> > fixes the problem, that implies that the default stack ulimit is less
> > than the 8MiB-64KiB that it takes to reach the guard page...
>
> Just so I'm clear, is the stack supposed to grow down automatically
> (ie. does the stack automatically use MAP_GROWSDOWN), or is OCaml
> supposed to do something when the stack hits the guard page?
>
> I guess it's also possible that an OCaml stack frame is so big that it
> skips the guard page, or that GCC does some kind of stack "filling" to
> trigger the guard page which OCaml does not do.
This is easy to trigger, right? Can you catch it in gdb and 't a a bt'
I won't bore you with the full stack trace, but the top and bottom
and some interesting registers are below.
It confirms a few things:
- Stack is overflowing because of a highly recursive function (which
does eventually bottom-out, if you give it a big enough stack).
- Compiler is single threaded.
- %r1 (at top) - %r1 (at bottom) is approximately 8 MB
- Avg. size of each stack frame is ~ 168 bytes.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW