[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130331205139.GI30576@port70.net>
Date: Sun, 31 Mar 2013 22:51:39 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: pthread_getattr_np
* Rich Felker <dalias@...ifal.cx> [2013-03-31 14:07:17 -0400]:
> Getting the high address (or "top" as you've called it) is trivial;
> your efforts to find the end of the last page that's part of the
> "stack mapping" are unnecessary. Any address that's past the address
> of any automatic variable in the main thread, but such that all pages
> between are valid, is a valid choice for the upper-limit address. The
yes but rlimit counts from the high end of the stack
so if [highend-rlimit, highend] method is used then
you have to find the real high end to have a good
lowend
> hard part is getting the lower-limit. The rlimit is not a valid way to
> measure this. For example, rlimit could be unlimited, or the stack
> might have already grown large before the rlimit was reduced.
yes but there is no valid way: the libs i saw queried
this info once, even though rlimit can change and one
can map or unmap areas in the way of the stack growth
so the api only makes sense if one does not do such
things, in which case rlimit gives a useful estimate
> In practice, it seems like GC applications only care about the start
> (upper limit) of the stack, not the other end; they use the current
> stack pointer for the other limit. We could probe the current stack
> pointer of the target thread by freezing it (with the synccall magic),
> but this seems like it might be excessively costly for no practical
> benefit...
eg. address sanitizer creates a shadow map for the stack so
at least it needs a reasonably sized upper bound on the
stack size (but it does the /proc parsing magic itselfs for
the main thread at startup so we don't have to support that)
if the lowend is not used otherwise then we can give arbitrary
result (eg always returning highend-5MB or using the rlimit
truncated to some value when it's unlimited)
all the calls to this function seem to use pthread_self()
at thread creation or startup time, so synccall is probably
not needed to get a sp
to get a 'precize' lowend one can:
1) parse /proc/self/maps which gives the current [low,high] mapping
and 'prev' the high end of the last mapping below the stack
2) if we are the main thread check if low <= sp <= high
3) check rlimit
lowend = min(max(prev, high-rlimit, high-1G), low)
then we can return [lowend,high] or [lowend,libc_high]
(where libc_high is below the real high, but we need the
real one for the calculations)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
