Hi! This is tracked down from the GCC Go testsuite, where every execution test would fail à la:
mmap errno 1073741846
fatal error: mmap
That is EINVAL (but that actually is a straw man, as it should turn out),
and mmap has been invoked from [GCC]/libbacktrace/mmap.c:backtrace_alloc
(but that also doesn't matter, as it should turn out), and it's the
simple case where mmap just calls vm_allocate to get private anonymous
memory (just one single page in this case).
What happens is that vm_allocate (which I understand to be a real system
call?!) is returning KERN_SUCCESS but at the same time doesn't set the
address it reserved. At first, I reproducted this behavior with GDB
(»call __vm_allocate(1,0x21ff930,4096,1)«; observe that for the first
call, the value at 0x21ff930 doesn't change) in one of the executables
the GCC Go testsuite left behind, and after having realized that these
are all built with -fsplit-stack, it is reproducable as follows:
#include <mach.h>
#include <stdio.h>
int main(void)
{
int err;
vm_address_t addr = 0;
int i;
for (i = 0; i < 3; ++i)
{
err = vm_allocate(mach_task_self(), &addr, 4096, 1);
printf("%u %p\n", err, (void *) addr);
}
return 0;
}
$ gcc -Wall v.c -fsplit-stack
$ ./a.out
0 (nil)
0 0x102c000
0 0x102e000
GCC's -fsplit-stack is documented at
<http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fsplit_002dstack-2394>
and/or <http://nickclifton.livejournal.com/6889.html>. Due to our
current threavar machinery in glibc, we can't expect it to work,
<http://darnassus.sceen.net/~hurd-web/open_issues/glibc/t/tls-threadvar/>.
But contrary to what I thought, it actually *is* enabled for us, too, so
aside from the threadvar issue, the run-time code accesses %gs:0x30
([GCC]/libgcc/config/i386/morestack.S), which is not appropriate either.
I'm now testing a GCC build with split-stack disabled.
But anyway, what is the split-stack run-time/startup code doing so that
it makes vm_allocate behave erratically? Isn't vm_allocate a real system
call after all, but relies on some threadvar state? It's now too late to
figure it out today, and I have enough other things on my plate anyway.
But surely Richard and/or Samuel will have some comments on this? ;-)
Grüße,
Thomas
pgp3710uOzSrr.pgp
Description: PGP signature
