On Wed, Mar 25, 2015 at 06:30:25PM +0000, David Woodhouse wrote: > On Tue, 2015-03-24 at 11:35 -0500, Steven Munroe wrote: > > I am not sure how ocaml is generating code for PPC64, you could look in > > to split stack support, but at this time GCC does not implement split > > stack. > ... for PPC64. > > I wouldn't want to do it in OCaml before it's supported in GCC and the > runtime. But once it *is*, it shouldn't be hard to make OCaml support > it. > > It's mostly just a matter of emitting the right instructions in the > function prologue and epilogue, in emit.mlp. > > But it does depend on the runtime support for allocating more stack > while not overflowing the 'slop' space on the existing stack, and > linker support for expanding the stack frame size when calling through > to legacy non-split-stack functions, and probably other things. So not > something we'd want to do purely within OCaml. > > I'm a little confused about what the problem is, though. In summary: when you run ocamlopt to compile a sufficiently complicated OCaml program, ocamlopt segfaults. We found the cure is to do 'ulimit -s 65536' before running ocamlopt. > 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... can that > be right? Richard, what does 'ulimit -s' report *before* you increase > it? $ ulimit -s 8192 (For reference, all the limits are attached below). That is from Fedora 20 ppc64 (not -le). The server is a POWER 7 LPAR. The page size is 64K. I don't currently have access to a newer Fedora machine, but the same segfault was reported in current Rawhide and it was cured in the same way, so it seems unlikely that the default stack size is different there. Rich. $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 496059 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 4096 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
