This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
- From: Samuel Thibault <samuel dot thibault at gnu dot org>
- To: Svante Signell <svante dot signell at gmail dot com>
- Cc: Thomas Schwinge <thomas at codesourcery dot com>, Ian Lance Taylor <iant at google dot com>, gcc-patches at gcc dot gnu dot org, bug-hurd at gnu dot org, fotis dot koutoulakis at gmail dot com, Roland McGrath <roland at hack dot frob dot com>
- Date: Fri, 2 May 2014 11:57:53 +0200
- Subject: Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
- Authentication-results: sourceware.org; auth=none
- References: <87ip10o90k dot fsf at kepler dot schwinge dot homeip dot net> <20140404191416 dot GG5350 at type> <1397027146 dot 1276 dot 29 dot camel at G3620 dot my dot own dot domain> <87fvln6jjp dot fsf at schwinge dot name> <20140416220345 dot GZ5545 at type dot youpi dot perso dot aquilenet dot fr> <20140418080311 dot GA5626 at type dot bordeaux dot inria dot fr> <1398328750 dot 568 dot 74 dot camel at G3620 dot my dot own dot domain> <20140501224530 dot GD5592 at type dot youpi dot perso dot aquilenet dot fr> <1399017803 dot 8487 dot 5 dot camel at PackardBell-PC> <1399018692 dot 8487 dot 7 dot camel at PackardBell-PC>
Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit :
> task130(pid1182)->vm_allocate (33562796 8364 0) = 0x3 ((os/kern) no space available)
> task130(pid1182)->vm_allocate (33571160 8364 0) = 0 33570816
While inspecting this, I realized this is from __pthread_stack_alloc,
the only caller of vm_allocate with anywhere set to 0 which would have
such behavior. 8364 is really small for a stack (but that's expected
from -fsplit-stack), and the thing is: we have a bogus libpthread which
includes guardsize into stacksize. I guess this is what happens: gcc
believes there is 8K, but our libpthread actually removes 4K from it for
guardsize, so the process will crash as soon as 4K are used on the
stack.
So we just need to fix guardsize in our libpthread.
Samuel