On Wed, Mar 25, 2015 at 07:57:25PM -0500, Steven Munroe 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? > > It depends on which code is allocating the stack. > > The default GLIBC implementation under pthread_create will allocate it > as single anonymous mmap of 8MB then use mprotect on the lowest page to > mark the guard page no-access. As in: 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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
