How to get stack bounds of current process?

[Kostik Belousov]

On Mon, May 10, 2010 at 09:45:21PM +0400, Lev Serebryakov wrote:
> Hello, Kostik.
> You wrote 10 мая 2010 г., 18:58:17:
> 
> 
> >>   I'm  proting  some  application from Linux, which discover its stack
> >>  bounds   by   reading  and  pasing  "/proc/self/maps".  FreeBSD  have
> >>  "/prov/curproc/map", but I can not find how to determine which record
> >>  is  for  stack  (I've  looked  into implementation of proc_fs, but it
> >>  doesn't contain any specail processing for process stack).
> >> 
> >>   How could I determine stack bounds of current process on FreeBSD
> >> 7/8/9?
> > I think the right question is why the program needs the information at all.
> 
> > Really, the system has no data to answer your question. Which stack are
> > you asking for ? The stack of main thread, set up by kernel, is very
> > different from the stack established by the threading library for
> > newly created thread. What should happen for signal altstacks ?
> > Also, the threading library clips the main thread stack to match its
> > size with default stack size (I do think this is unsafe and wrong).
>   It   is   port   of   new  openjdk7  build.  It  adds  function with
> this comment in Linux-specific code (BSD port is based on Linux one):
> 
> // Linux uses a growable mapping for the stack, and if the mapping for
> // the stack guard pages is not removed when we detach a thread the
> // stack cannot grow beyond the pages where the stack guard was
> // mapped.  If at some point later in the process the stack expands to
> // that point, the Bsd kernel cannot expand the stack any further
> // because the guard pages are in the way, and a segfault occurs.
> //
> // However, it's essential not to split the stack region by unmapping
> // a region (leaving a hole) that's already part of the stack mapping,
> // so if the stack mapping has already grown beyond the guard pages at
> // the time we create them, we have to truncate the stack mapping.
> // So, we need to know the extent of the stack mapping when
> // create_stack_guard_pages() is called.
> 
> // Find the bounds of the stack mapping.  Return true for success.
> //
> // We only need this for stacks that are growable: at the time of
> // writing thread stacks don't use growable mappings (i.e. those
> // creeated with MAP_GROWSDOWN), and aren't marked "[stack]", so this
> // only applies to the main thread.
> 
> // If the (growable) stack mapping already extends beyond the point
> // where we're going to put our guard pages, truncate the mapping at
> // that point by munmap()ping it.  This ensures that when we later
> // munmap() the guard pages we don't leave a hole in the stack
> // mapping.
> 
>   Solaris   code   simple   map/unmap   needed  pages,  and Linux port
> checks  stack region and applies special processing for growable stack
> area...
> 
>   I'm not sure, should BSD port behaves as Linux or as Solaris one.
I still do not understand what the program does and why.
Text you posted assumes reader understands what the code does
and what goals are achieved there.

I did mentioned that the threading library puts unmapped region to
clip the main thread stack, is this the issue the author of comment
worried ? And why this makes him worry ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20100510/4f1d5e11/attachment.pgp