GCC's -fsplit-stack disturbing Mach's vm_allocate

Hi!

On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor <iant@google.com> wrote:
> Go can work without split stack.  In that case libgo will use much
> larger stacks for goroutines, to reduce the chance of running out of
> stack space (see StackMin in libgo/runtime/proc.c).  So the number of
> simultaneous goroutines that can be run will be limited.  This is
> usually OK on x86_64 but it does hamper Go programs running on 32-bit
> x86.

OK, but that's not the most pressing issue we're having right now.
Anyway, as it stands, the split-stack code doesn't work on Hurd, so I
disabled it in r200434 as follows:

gcc/
	* config/i386/gnu.h [TARGET_LIBC_PROVIDES_SSP]
	(TARGET_CAN_SPLIT_STACK, TARGET_THREAD_SPLIT_STACK_OFFSET):
	Undefine.



Grüße,
 Thomas

Hello,

Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a écrit :
> On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor <iant@google.com> wrote:
> > Go can work without split stack.  In that case libgo will use much
> > larger stacks for goroutines, to reduce the chance of running out of
> > stack space (see StackMin in libgo/runtime/proc.c).  So the number of
> > simultaneous goroutines that can be run will be limited.  This is
> > usually OK on x86_64 but it does hamper Go programs running on 32-bit
> > x86.
> 
> OK, but that's not the most pressing issue we're having right now.
> Anyway, as it stands, the split-stack code doesn't work on Hurd, so I
> disabled it in r200434 as follows:

Maybe you'd want to re-enable it, now that we have got rid of threadvars :)

Samuel

On Fri, 2014-04-04 at 21:14 +0200, Samuel Thibault wrote:
> Hello,
> 
> Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a écrit :
> > On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor <iant@google.com> wrote:
> > > Go can work without split stack.  In that case libgo will use much
> > > larger stacks for goroutines, to reduce the chance of running out of
> > > stack space (see StackMin in libgo/runtime/proc.c).  So the number of
> > > simultaneous goroutines that can be run will be limited.  This is
> > > usually OK on x86_64 but it does hamper Go programs running on 32-bit
> > > x86.
> > 
> > OK, but that's not the most pressing issue we're having right now.
> > Anyway, as it stands, the split-stack code doesn't work on Hurd, so I
> > disabled it in r200434 as follows:
> 
> Maybe you'd want to re-enable it, now that we have got rid of threadvars :)

I don't think it is a good idea. I've patched gcc-4.9-20140406 to make
gccgo build and tested with -fsplit-stack enabled (with and without the
gold linker). Without split stack around 70 libgo tests pass and 50
fails. With it enabled all tests fail. Simple examples are the following
C code (from Thomas) and GO code:

1)
cat test_split_stack.c 
#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-4.9 test_split_stack.c -fsplit-stack
    $ ./a.out
    0 (nil)
    0 0x102c000
    0 0x1027800

    $ gcc-4.9 test_split_stack.c
    $ ./a.out
    0 0x102c000
    0 0x125b000
    0 0x125c000

2)
cat hello.go:
package main

import "fmt"

func main() {
        fmt.Printf("Hello, world.\n")
}

gccgo-4.9 -g hello.go
 ./a.out
Hello, world.

LD_PRELOAD=../gcc-4.9-4.9-20140406/build/i486-gnu/libgo/.libs/libgo.so.5.0.0 ./a.out
mmap errno 1073741846
fatal error: mmap

runtime stack:
^C

Something is still not OK with the treads library?

Patches for gccgo on GNU/Hurd will be submitted to the Debian BTS.

Hi!

On Wed, 9 Apr 2014 09:05:46 +0200, Svante Signell <svante.signell@gmail.com> wrote:
> On Fri, 2014-04-04 at 21:14 +0200, Samuel Thibault wrote:
> > Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a écrit :
> > > On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor <iant@google.com> wrote:
> > > > Go can work without split stack.  In that case libgo will use much
> > > > larger stacks for goroutines, to reduce the chance of running out of
> > > > stack space (see StackMin in libgo/runtime/proc.c).  So the number of
> > > > simultaneous goroutines that can be run will be limited.  This is
> > > > usually OK on x86_64 but it does hamper Go programs running on 32-bit
> > > > x86.
> > > 
> > > OK, but that's not the most pressing issue we're having right now.
> > > Anyway, as it stands, the split-stack code doesn't work on Hurd, so I
> > > disabled it in r200434 as follows:
> > 
> > Maybe you'd want to re-enable it, now that we have got rid of threadvars :)
> 
> I don't think it is a good idea. I've patched gcc-4.9-20140406 to make
> gccgo build and tested with -fsplit-stack enabled (with and without the
> gold linker). Without split stack around 70 libgo tests pass and 50
> fails. With it enabled all tests fail. [...]

> LD_PRELOAD=../gcc-4.9-4.9-20140406/build/i486-gnu/libgo/.libs/libgo.so.5.0.0 ./a.out
> mmap errno 1073741846
> fatal error: mmap

Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
and similar configury is correct for the Hurd, and figure out what's
going on with the zero-page unmapping (discussed earlier in this thread),
and then mmap failing with 1073741846 (EINVAL).


> Patches for gccgo on GNU/Hurd will be submitted to the Debian BTS.

Just a suggestion, but in my opinion, it'd make more sense to first get
such patches integrated upstream.  (Same also for the GCC Ada patches.)
GCC Go support (as well as Ada) clearly is not a critical thing to first
get into Debian GNU/Hurd, and the total maintenance/integration overhead
would be lower if these patches would just percolate into Debian GCC from
upstream.


Grüße,
 Thomas

Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> and similar configury is correct for the Hurd,

It's not.  I've checked what TARGET_THREAD_SPLIT_STACK_OFFSET is, it's
an offset inside the tcbhead_t structure, and we don't have that field
at all...  We may want to extend our tcbhead_t the same way as Linux
i386.

> and figure out what's
> going on with the zero-page unmapping (discussed earlier in this thread),
> and then mmap failing with 1073741846 (EINVAL).

Here is the backtrace

#0  __vm_map (target_task=1, address=address@entry=0x1029cc4, size=size@entry=0, mask=mask@entry=0, anywhere=1, memory_object=memory_object@entry=0, offset=offset@entry=0, 
    copy=copy@entry=1, cur_protection=cur_protection@entry=1, max_protection=max_protection@entry=7, inheritance=inheritance@entry=1)
    at /usr/src/eglibc-2.18/build-tree/hurd-i386-libc/mach/vm_map.c:56
#1  0x0118a3e8 in __mmap (addr=0x0, len=0, prot=4, flags=2, fd=-1, offset=0) at ../sysdeps/mach/hurd/mmap.c:145
#2  0x0804960d in __morestack_load_mmap ()
#3  0x08049d12 in __libc_csu_init ()
#4  0x010b4671 in __libc_start_main (main=0x80489dd <main>, argc=1, argv=0x1029de4, init=0x8049cc0 <__libc_csu_init>, fini=0x8049d30 <__libc_csu_fini>, rtld_fini=0xfb90 <_dl_fini>, 
    stack_end=0x1029ddc) at libc-start.c:246
#5  0x08048901 in _start ()

It's indeed:

/* This function is called at program startup time to make sure that
   mmap, munmap, and getpagesize are resolved if linking dynamically.
   We want to resolve them while we have enough stack for them, rather
   than calling into the dynamic linker while low on stack space.  */

void
__morestack_load_mmap (void)
{
  /* Call with bogus values to run faster.  We don't care if the call
     fails.  Pass __MORESTACK_CURRENT_SEGMENT to make sure that any
     TLS accessor function is resolved.  */
  mmap (__morestack_current_segment, 0, PROT_READ, MAP_ANONYMOUS, -1, 0);
  mprotect (NULL, 0, 0);
  munmap (0, getpagesize ());
}

Yes...

So, do we really want to let munmap poke a hole at address 0 and thus
let further vm_map() return address 0?

Samuel

On Fri, Apr 11, 2014 at 11:51:44PM +0200, Samuel Thibault wrote:
> It's indeed:
> 
> /* This function is called at program startup time to make sure that
>    mmap, munmap, and getpagesize are resolved if linking dynamically.
>    We want to resolve them while we have enough stack for them, rather
>    than calling into the dynamic linker while low on stack space.  */
> 
> void
> __morestack_load_mmap (void)
> {
>   /* Call with bogus values to run faster.  We don't care if the call
>      fails.  Pass __MORESTACK_CURRENT_SEGMENT to make sure that any
>      TLS accessor function is resolved.  */
>   mmap (__morestack_current_segment, 0, PROT_READ, MAP_ANONYMOUS, -1, 0);
>   mprotect (NULL, 0, 0);
>   munmap (0, getpagesize ());
> }
> 
> Yes...
> 
> So, do we really want to let munmap poke a hole at address 0 and thus
> let further vm_map() return address 0?

We probably don't. AIUI, the first page is always mapped, and always
with PROT_NONE to make sure null pointers are catched. Considering other
systems have predefined ranges depending on the mapping type, instead
of blindly starting at the beginning of the map like vm_map() does, it's
perfectly valid to unmap the first page, which is normally the right
way to catch null pointers. So, since we do want to catch null pointers,
we do want to keep that first page, but only the first page. Or rather,
a range large enough to catch accesses through null pointers, e.g. it
could even be 64 or 128 KiB. We could alter glibc so that the first
mapping has this special size, and have munmap override its given range
to skip that area.

Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> and similar configury is correct for the Hurd,

I have added the corresponding field, so we can just use the same offset
as on Linux.

Samuel

Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
> Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> > Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> > and similar configury is correct for the Hurd,
> 
> I have added the corresponding field, so we can just use the same offset
> as on Linux.

I have uploaded packages on http://people.debian.org/~sthibault/tmp/ so
Svante can try setting TARGET_THREAD_SPLIT_STACK_OFFSET to 0x30 with
them.

Samuel

On Fri, 2014-04-18 at 10:03 +0200, Samuel Thibault wrote:
> Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
> > Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> > > Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> > > and similar configury is correct for the Hurd,
> > 
> > I have added the corresponding field, so we can just use the same offset
> > as on Linux.
> 
> I have uploaded packages on http://people.debian.org/~sthibault/tmp/ so
> Svante can try setting TARGET_THREAD_SPLIT_STACK_OFFSET to 0x30 with
> them.

Status report:
- Without split stack enabled around 70 libgo tests pass and 50 fails,
most of them with a segfault.
- Enabling split stack and using the libc Samuel built all 122 libgo
tests fail with a segfault.
- In both cases simple go programs work, like hello+sqrt.go below.
- The segfault seems to be located at the same code piece according to
gdb (maybe due to exception handling)

cat hello+sqrt.go
package main
import (
        "fmt"
)
func main() {
        fmt.Printf("Hello, world.  Sqrt(2) = %v\n", Sqrt(2))
}

I have not been able to use a local go library function, e.g. package
newmath, and the go frontend is not yet available for GNU/Hurd.

However, it seems that something triggers the segfaults when running
make -C build/i486-gnu/libgo check (both with and w/o split-stack)
while setting the keep parameter in ./src/libgo/testsuite/gotest
and running them manually some of them work?? As a first glance, about
the same number of tests succeeds with and w/o split stack :) Some of
the failing tests still seems random, sometimes they pass, sometimes
they fail.

Quoting Svante Signell (2014-04-24 10:39:10)
> On Fri, 2014-04-18 at 10:03 +0200, Samuel Thibault wrote:
> > Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
> > > Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> > > > Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> > > > and similar configury is correct for the Hurd,
> > > 
> > > I have added the corresponding field, so we can just use the same offset
> > > as on Linux.
> > 
> > I have uploaded packages on http://people.debian.org/~sthibault/tmp/ so
> > Svante can try setting TARGET_THREAD_SPLIT_STACK_OFFSET to 0x30 with
> > them.
> 
> Status report:
> - Without split stack enabled around 70 libgo tests pass and 50 fails,
> most of them with a segfault.
> - Enabling split stack and using the libc Samuel built all 122 libgo
> tests fail with a segfault.
> - In both cases simple go programs work, like hello+sqrt.go below.
> - The segfault seems to be located at the same code piece according to
> gdb (maybe due to exception handling)
> 
> cat hello+sqrt.go
> package main
> import (
>         "fmt"
> )
> func main() {
>         fmt.Printf("Hello, world.  Sqrt(2) = %v\n", Sqrt(2))
> }

How is that even a valid go program? Sqrt is not defined.

> I have not been able to use a local go library function, e.g. package
> newmath, and the go frontend is not yet available for GNU/Hurd.

What do you mean exactly by "local go library function"?

> However, it seems that something triggers the segfaults when running
> make -C build/i486-gnu/libgo check (both with and w/o split-stack)
> while setting the keep parameter in ./src/libgo/testsuite/gotest
> and running them manually some of them work?? As a first glance, about
> the same number of tests succeeds with and w/o split stack :) Some of
> the failing tests still seems random, sometimes they pass, sometimes
> they fail.

For reference, here are my notes about one of these crashes (Svante,
is this still current?):

~~~ snip ~~~
First, there is a rpctrace bug (or, i'm misinterpreting the output):

  93<--142(pid1182)->dir_lookup ("etc/hostname" 1 0) = 0 1 ""    158<--160(pid1182)

Here, we do a dir_lookup and get port 158.

  158<--160(pid1182)->io_read_request (-1 255) = 0 "hurd-2013\n"
  158<--160(pid1182)->io_readable_request () = 0 0

Here, we use it to do stuff with that file.

task130(pid1182)->mach_port_deallocate (pn{ 23}) = 0 

Here, we deallocate the port.  Note how the port name (pn?) says 23,
even though it's clearly port 158 that is getting deallocated, b/c we
get port 158 back from the next rpc:

  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libnss_files.so.2" 4194305 0) = 0 1 ""    158<--157(pid1182)

Now, the get to the real issue.  From the backtrace (http://paste.debian.net/95410/)
we know that it segfaults in mmap:

Program received signal SIGSEGV, Segmentation fault.
0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
132	   intr-msg.c: No such file or directory.
[...]
Thread 4 (Thread 1205.4):
#0  0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
        err = <optimized out>
        err = <optimized out>
        user_option = 3
        user_timeout = 48
        m = 0x532370
        msgh_bits = 0
        remote_port = 268509186
        msgid = 21118
        save_data = <optimized out>
        __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
#1  0x00000005 in ?? ()
No symbol table info available.
#2  0x01a7a8dd in __mmap (addr=0x0, len=49880, prot=5, flags=33, fd=8, offset=0)
    at ../sysdeps/mach/hurd/mmap.c:92
        __ulink = {resource = {next = 0x0, prevp = 0x2cfcc}, thread = {next = 0x0, 
            prevp = 0x1b81c5c}, cleanup = 0x19a2c70 <_hurd_port_cleanup>, cleanup_data = 0x99}
        __ctty_ulink = {resource = {next = 0x0, prevp = 0x19fc6bc <_int_malloc+12>}, thread = {
            next = 0x17, prevp = 0x5}, cleanup = 0x0, cleanup_data = 0x700f2}
        __result = <optimized out>
        descriptor = 0x1b5e467 <__io_map+7>
        robj = 0
        wobj = 4608
        err = <optimized out>
        vmprot = 0
        memobj = <optimized out>
        mapaddr = 0
#3  0x00007b27 in _dl_map_object_from_fd (name=name@entry=0x532b58 "libnss_files.so.2", fd=8,
[...]

Note how weird the remote_port = 268509186 looks.  Here is the rpctrace again:

  158<--157(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  158<--157(pid1182)->io_read_request (-1 512) = 0 "\x7fELF\x01\x01\x01"
  158<--157(pid1182)->io_stat_request () = 0 {23 5 0 458994 0 1885249733 0 33188 1 0 0 46752 0 1398335701 0 1397789836 0 1398160744 0 8192 96 0 0 0 0 0 0 0 0 0 0 0}
  158<--157(pid1182)->io_map_request () = 0    133<--160(pid1182)  (null)

So we call io_map, get a read memobj and no write memobj.

task130(pid1182)->vm_map (0 49880 0 1    133<--160(pid1182) 0 1 5 7 1) = 0 2453504

We map that somewhere.

task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0 

Deallocate the port.  Again, for some strange reason 133 == pn{ 25}.

  158<--157(pid1182)->io_map_request () = 0    133<--162(pid1182)  (null)

Some more io_map.

task130(pid1182)->vm_map (2498560 8192 0 0    133<--162(pid1182) 40960 1 3 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (2498560 8192) = 0 

Hum?

task130(pid1182)->vm_map (2498560 8192 0 0    133<--162(pid1182) 40960 1 3 7 1) = 0 2498560
task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0 

Success!

task130(pid1182)->mach_port_deallocate (pn{ 23}) = 0 

Get rid of port 158.  That looks rather allright from the ipc perspective.
Why do we see the process crash at presumably this very moment? I guess it
could still crash here due to the fact that rpctrace can not differentiate
between different threads in the tracee.

task130(pid1182)->vm_protect (2498560 4096 0 1) = 0 
  93<--142(pid1182)->dir_lookup ("etc/hosts" 4194305 0) = 0 1 ""    158<--160(pid1182)
  158<--160(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  158<--160(pid1182)->io_stat_request () = 0 {23 5 0 81987 0 1368845833 0 33188 1 0 0 248 0 1398335660 0 1368797592 0 1368797592 0 8192 8 0 0 0 0 0 0 0 0 0 0 0}
  158<--160(pid1182)->io_read_request (-1 8192) = 0 "127.0.0.1    localhost\n127.0.1.1    hurd-2013.my.own.domain    hurd-2013\n\n# The following"
  158<--160(pid1182)->io_read_request (-1 8192) = 0 ""
task130(pid1182)->mach_port_destroy (pn{ 24}) ...159
task130(pid1182)->mach_port_deallocate (pn{ 23}) ...134
159... = 0 
134... = 0 
task130(pid1182)->vm_allocate (0 36864 1) = 0 2506752
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 21}) ...134
task130(pid1182)->mach_port_deallocate (pn{ 11}) ...159
134... = 0 
159... = 0 
task130(pid1182)->vm_allocate (33562796 8364 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (33571160 8364 0) = 0 33570816
task130(pid1182)->mach_port_allocate (1) = 0 pn{ 23}
task130(pid1182)->mach_port_insert_right (pn{ 23}  133) = 0 
task130(pid1182)->mach_port_set_qlimit (pn{ 23} 1) = 0 
task130(pid1182)->thread_create () = 0    160<--157(pid1182)
task130(pid1182)->vm_protect (33570816 1 0 0) = 0 
  146<--150(pid-1)-> 2400 ( thread151(pid1182)  task130(pid1182) 1 2 33557926) ...159
  139<--144(pid1182)->proc_dostop_request ( thread138(pid1182)) = 0 
  93<--142(pid1182)->dir_lookup ("servers/crash" 0 0) = 0 1 ""    163<--161(pid1182)
task130(pid1182)->mach_port_mod_refs (pn{  6} 0 1) = 0 
  109<--141(pid1182)->dir_mkfile (18 384) = 0    165<--164(pid1182)
  163<--161(pid1182)->crash_dump_task ( task130(pid1182)    165<--164(pid1182) 11 2 2 1 2 33557926    118<--145(pid1182)) ...134
 159->   71 ();
134... = 0 
Child 1182 Segmentation fault
~~~ snip ~~~

Justus

±On Sat, 2014-04-26 at 08:53 +0200, Justus Winter wrote:
> Quoting Svante Signell (2014-04-24 10:39:10)
> > On Fri, 2014-04-18 at 10:03 +0200, Samuel Thibault wrote:
> > > Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
> > > > Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> > > > > Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> > > > > and similar configury is correct for the Hurd,
> > > > 
> > > > I have added the corresponding field, so we can just use the same offset
> > > > as on Linux.
> > > 
> > > I have uploaded packages on http://people.debian.org/~sthibault/tmp/ so
> > > Svante can try setting TARGET_THREAD_SPLIT_STACK_OFFSET to 0x30 with
> > > them.
> > 
> > Status report:
> > - Without split stack enabled around 70 libgo tests pass and 50 fails,
> > most of them with a segfault.
> > - Enabling split stack and using the libc Samuel built all 122 libgo
> > tests fail with a segfault.
> > - In both cases simple go programs work, like hello+sqrt.go below.
> > - The segfault seems to be located at the same code piece according to
> > gdb (maybe due to exception handling)
> > 
> > cat hello+sqrt.go
> > package main
> > import (
> >         "fmt"
> > )
> > func main() {
> >         fmt.Printf("Hello, world.  Sqrt(2) = %v\n", Sqrt(2))
> > }
> 
> How is that even a valid go program? Sqrt is not defined.

Here is the sqrt.go:
// Package main is a trivial example package.
package main

// Sqrt returns an approximation to the square root of x.
func Sqrt(x float64) float64 {
        z := 1.0
        for i := 0; i < 1000; i++ {
                z -= (z*z - x) / (2 * z)
        }
        return z
}
gccgo-4.9 -g hello+sqrt.go sqrt.go

> > I have not been able to use a local go library function, e.g. package
> > newmath, and the go frontend is not yet available for GNU/Hurd.
> 
> What do you mean exactly by "local go library function"?

Like having sqrt.go in a separate directory:

cat newmath/sqrt.go
// Package newmath is a trivial example package.
package newmath

// Sqrt returns an approximation to the square root of x.
func Sqrt(x float64) float64 {
        z := 1.0
        for i := 0; i < 1000; i++ {
                z -= (z*z - x) / (2 * z)
        }
        return z
}

> > However, it seems that something triggers the segfaults when running
> > make -C build/i486-gnu/libgo check (both with and w/o split-stack)
> > while setting the keep parameter in ./src/libgo/testsuite/gotest
> > and running them manually some of them work?? As a first glance, about
> > the same number of tests succeeds with and w/o split stack :) Some of
> > the failing tests still seems random, sometimes they pass, sometimes
> > they fail.
> 
> For reference, here are my notes about one of these crashes (Svante,
> is this still current?):

Yes it is, thanks for your help so far. Is the rpctrace bug you
mentioned that the wrong ports are reported?

> ~~~ snip ~~~
> First, there is a rpctrace bug (or, i'm misinterpreting the output):
> 
>   93<--142(pid1182)->dir_lookup ("etc/hostname" 1 0) = 0 1 ""    158<--160(pid1182)
> 
> Here, we do a dir_lookup and get port 158.
> 
>   158<--160(pid1182)->io_read_request (-1 255) = 0 "hurd-2013\n"
>   158<--160(pid1182)->io_readable_request () = 0 0
> 
> Here, we use it to do stuff with that file.
> 
> task130(pid1182)->mach_port_deallocate (pn{ 23}) = 0 
> 
> Here, we deallocate the port.  Note how the port name (pn?) says 23,
> even though it's clearly port 158 that is getting deallocated, b/c we
> get port 158 back from the next rpc:
> 
>   93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libnss_files.so.2" 4194305 0) = 0 1 ""    158<--157(pid1182)
> 
> Now, the get to the real issue.  From the backtrace (http://paste.debian.net/95410/)
> we know that it segfaults in mmap:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
> 132	   intr-msg.c: No such file or directory.
> [...]
> Thread 4 (Thread 1205.4):
> #0  0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
>         err = <optimized out>
>         err = <optimized out>
>         user_option = 3
>         user_timeout = 48
>         m = 0x532370
>         msgh_bits = 0
>         remote_port = 268509186
>         msgid = 21118
>         save_data = <optimized out>
>         __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
> #1  0x00000005 in ?? ()
> No symbol table info available.
> #2  0x01a7a8dd in __mmap (addr=0x0, len=49880, prot=5, flags=33, fd=8, offset=0)
>     at ../sysdeps/mach/hurd/mmap.c:92
>         __ulink = {resource = {next = 0x0, prevp = 0x2cfcc}, thread = {next = 0x0, 
>             prevp = 0x1b81c5c}, cleanup = 0x19a2c70 <_hurd_port_cleanup>, cleanup_data = 0x99}
>         __ctty_ulink = {resource = {next = 0x0, prevp = 0x19fc6bc <_int_malloc+12>}, thread = {
>             next = 0x17, prevp = 0x5}, cleanup = 0x0, cleanup_data = 0x700f2}
>         __result = <optimized out>
>         descriptor = 0x1b5e467 <__io_map+7>
>         robj = 0
>         wobj = 4608
>         err = <optimized out>
>         vmprot = 0
>         memobj = <optimized out>
>         mapaddr = 0
> #3  0x00007b27 in _dl_map_object_from_fd (name=name@entry=0x532b58 "libnss_files.so.2", fd=8,
> [...]
> 
> Note how weird the remote_port = 268509186 looks.  Here is the rpctrace again:
> 
>   158<--157(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
>   158<--157(pid1182)->io_read_request (-1 512) = 0 "\x7fELF\x01\x01\x01"
>   158<--157(pid1182)->io_stat_request () = 0 {23 5 0 458994 0 1885249733 0 33188 1 0 0 46752 0 1398335701 0 1397789836 0 1398160744 0 8192 96 0 0 0 0 0 0 0 0 0 0 0}
>   158<--157(pid1182)->io_map_request () = 0    133<--160(pid1182)  (null)
> 
> So we call io_map, get a read memobj and no write memobj.
> 
> task130(pid1182)->vm_map (0 49880 0 1    133<--160(pid1182) 0 1 5 7 1) = 0 2453504
> 
> We map that somewhere.
> 
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0 
> 
> Deallocate the port.  Again, for some strange reason 133 == pn{ 25}.
> 
>   158<--157(pid1182)->io_map_request () = 0    133<--162(pid1182)  (null)
> 
> Some more io_map.
> 
> task130(pid1182)->vm_map (2498560 8192 0 0    133<--162(pid1182) 40960 1 3 7 1) = 0x3 ((os/kern) no space available) 
> task130(pid1182)->vm_deallocate (2498560 8192) = 0 
> 
> Hum?
> 
> task130(pid1182)->vm_map (2498560 8192 0 0    133<--162(pid1182) 40960 1 3 7 1) = 0 2498560
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0 
> 
> Success!
> 
> task130(pid1182)->mach_port_deallocate (pn{ 23}) = 0 
> 
> Get rid of port 158.  That looks rather allright from the ipc perspective.
> Why do we see the process crash at presumably this very moment? I guess it
> could still crash here due to the fact that rpctrace can not differentiate
> between different threads in the tracee.
> 
> task130(pid1182)->vm_protect (2498560 4096 0 1) = 0 
>   93<--142(pid1182)->dir_lookup ("etc/hosts" 4194305 0) = 0 1 ""    158<--160(pid1182)
>   158<--160(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
>   158<--160(pid1182)->io_stat_request () = 0 {23 5 0 81987 0 1368845833 0 33188 1 0 0 248 0 1398335660 0 1368797592 0 1368797592 0 8192 8 0 0 0 0 0 0 0 0 0 0 0}
>   158<--160(pid1182)->io_read_request (-1 8192) = 0 "127.0.0.1    localhost\n127.0.1.1    hurd-2013.my.own.domain    hurd-2013\n\n# The following"
>   158<--160(pid1182)->io_read_request (-1 8192) = 0 ""
> task130(pid1182)->mach_port_destroy (pn{ 24}) ...159
> task130(pid1182)->mach_port_deallocate (pn{ 23}) ...134
> 159... = 0 
> 134... = 0 
> task130(pid1182)->vm_allocate (0 36864 1) = 0 2506752
> task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
> task130(pid1182)->mach_port_deallocate (pn{ 21}) ...134
> task130(pid1182)->mach_port_deallocate (pn{ 11}) ...159
> 134... = 0 
> 159... = 0 
> task130(pid1182)->vm_allocate (33562796 8364 0) = 0x3 ((os/kern) no space available) 
> task130(pid1182)->vm_allocate (33571160 8364 0) = 0 33570816
> task130(pid1182)->mach_port_allocate (1) = 0 pn{ 23}
> task130(pid1182)->mach_port_insert_right (pn{ 23}  133) = 0 
> task130(pid1182)->mach_port_set_qlimit (pn{ 23} 1) = 0 
> task130(pid1182)->thread_create () = 0    160<--157(pid1182)
> task130(pid1182)->vm_protect (33570816 1 0 0) = 0 
>   146<--150(pid-1)-> 2400 ( thread151(pid1182)  task130(pid1182) 1 2 33557926) ...159
>   139<--144(pid1182)->proc_dostop_request ( thread138(pid1182)) = 0 
>   93<--142(pid1182)->dir_lookup ("servers/crash" 0 0) = 0 1 ""    163<--161(pid1182)
> task130(pid1182)->mach_port_mod_refs (pn{  6} 0 1) = 0 
>   109<--141(pid1182)->dir_mkfile (18 384) = 0    165<--164(pid1182)
>   163<--161(pid1182)->crash_dump_task ( task130(pid1182)    165<--164(pid1182) 11 2 2 1 2 33557926    118<--145(pid1182)) ...134
>  159->   71 ();
> 134... = 0 
> Child 1182 Segmentation fault
> ~~~ snip ~~~
> 
> Justus
>

Quoting Svante Signell (2014-04-26 13:59:57)
> > For reference, here are my notes about one of these crashes (Svante,
> > is this still current?):
> 
> Yes it is, thanks for your help so far. Is the rpctrace bug you
> mentioned that the wrong ports are reported?
> 
> > ~~~ snip ~~~
> > [...]
> > task130(pid1182)->mach_port_deallocate (pn{ 23}) = 0 
> > 
> > Here, we deallocate the port.  Note how the port name (pn?) says 23,
> > even though it's clearly port 158 that is getting deallocated [...]

Reading the source revealed that 'pn{ 23}' makes it explicit that this
is a port name, not a right.  And indeed:

routine mach_port_deallocate(
		task		: ipc_space_t;
		name		: mach_port_name_t);

For port rights, which we know are valid in the tracee, we translate
the name so that the name used by the tracee is displayed in the log.
A comment in the source correctly states:

/* Note that MACH_MSG_TYPE_PORT_NAME does not indicate a port right.
   It indicates a port name, i.e. just an integer--and we don't know
   what task that port name is meaningful in.  If it's meaningful in a
   traced task, then it refers to our intercepting port rather than
   the original port anyway.  */

We could try to be clever here, at least for the reference counting
RPC.

Justus

Hello,

Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
> - Without split stack enabled around 70 libgo tests pass and 50 fails,
> most of them with a segfault.
> - Enabling split stack and using the libc Samuel built all 122 libgo
> tests fail with a segfault.

Please provide segfault backtrace, rpctrace, etc.  Otherwise we won't be
able to help you.

Samuel

On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote:
> Hello,
> 
> Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
> > - Without split stack enabled around 70 libgo tests pass and 50 fails,
> > most of them with a segfault.
> > - Enabling split stack and using the libc Samuel built all 122 libgo
> > tests fail with a segfault.
> 
> Please provide segfault backtrace, rpctrace, etc.  Otherwise we won't be
> able to help you.

You already have one in this thread, analysed by Justus:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01736.html

The full rpctrace and gdb backtrace for that case was published on
paste.debian.net, but are gone now. I can upload again if you need them,
or do you want it attached to a mail?

On Fri, 2014-05-02 at 10:03 +0200, Svante Signell wrote:
> On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote:
> > Hello,
> > 
> > Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
> > > - Without split stack enabled around 70 libgo tests pass and 50 fails,
> > > most of them with a segfault.
> > > - Enabling split stack and using the libc Samuel built all 122 libgo
> > > tests fail with a segfault.
> > 
> > Please provide segfault backtrace, rpctrace, etc.  Otherwise we won't be
> > able to help you.
> 
> You already have one in this thread, analysed by Justus:
> http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01736.html
> 
> The full rpctrace and gdb backtrace for that case was published on
> paste.debian.net, but are gone now. I can upload again if you need them,
> or do you want it attached to a mail?

On request, here are the traces attached.
Starting program: /home/srs/DEBs/gcc/libgo_tests/test_net/./a.out 
[New Thread 1205.5]
[New Thread 1205.6]
[New Thread 1205.7]

Program received signal SIGSEGV, Segmentation fault.
0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
132	intr-msg.c: No such file or directory.

Thread 7 (Thread 1205.7):
#0  0x00000000 in ?? ()
No symbol table info available.

Thread 6 (Thread 1205.6):
#0  __thread_get_state (target_thread=target_thread@entry=154, flavor=flavor@entry=5, 
    old_state=old_state@entry=0x2001dfc, old_stateCnt=old_stateCnt@entry=0x2001dec)
    at /usr/src/eglibc-2.18/build-tree/hurd-i386-libc/mach/RPC_thread_get_state.c:108
        Mess = <error reading variable Mess (Cannot access memory at address 0x2000d8c)>
        InP = 0x2000d8c
        OutP = 0x2000d8c
        msg_result = <optimized out>
        msgh_size = <optimized out>
#1  0x01b24050 in __thread_set_pcsptp (thread=154, set_ip=set_ip@entry=1, 
    ip=0x1b1fa50 <entry_point>, set_sp=set_sp@entry=1, sp=0x200609c, set_tp=set_tp@entry=1, 
    tp=0x600ec4) at ../libpthread/sysdeps/mach/hurd/i386/pt-machdep.c:53
        err = <optimized out>
        state = {gs = 27257018, fs = 6291472, es = 28419716, ds = 4608, edi = 32, esi = 0, 
          ebp = 151, esp = 7, ebx = 2124, edx = 268509186, ecx = 0, eax = 268509186, eip = 1, 
          cs = 268509184, efl = 0, uesp = 268509186, ss = 0}
        state_count = 17
#2  0x01b23f63 in __pthread_setup (thread=0x6004d0, 
    entry_point=entry_point@entry=0x1b1fa50 <entry_point>, 
    start_routine=start_routine@entry=0x15b6d40 <stack_split_initialize_thread>, 
    arg=arg@entry=0x6004c0) at ../libpthread/sysdeps/mach/hurd/i386/pt-setup.c:96
        tcb = <optimized out>
        err = <optimized out>
        ktid = 149
        __PRETTY_FUNCTION__ = "__pthread_setup"
#3  0x01b1fb84 in __pthread_create_internal (thread=thread@entry=0x2001efc, 
    attr=attr@entry=0x2001f60, 
    start_routine=start_routine@entry=0x15b6d40 <stack_split_initialize_thread>, 
    arg=arg@entry=0x6004c0) at ./pthread/pt-create.c:147
        err = 0
        pthread = 0x6004d0
        setup = <optimized out>
        sigset = 110
        __PRETTY_FUNCTION__ = "__pthread_create_internal"
#4  0x01b1fee3 in pthread_create (thread=0x2001f5c, attr=0x2001f60, 
    start_routine=0x15b6d40 <stack_split_initialize_thread>, arg=0x6004c0)
    at ./pthread/pt-create.c:75
        err = 33562092
        pthread = 0x19fe868 <__libc_malloc+8>
#5  0x015b6e73 in __wrap_pthread_create (tid=0x2001f5c, attr=0x2001f60, 
    start_routine=0x12ec7c0 <runtime_mstart>, arg=0x2030f800)
    at ../../../src/libgcc/generic-morestack-thread.c:161
        err = <optimized out>
        args = <optimized out>
#6  0x012eba18 in runtime_newosproc (mp=<optimized out>) at ../../../src/libgo/runtime/proc.c:212
        clear = 4294967279
        old = 0
        tid = 19797113
        ret = 33562464
        attr = {schedparam = {__sched_priority = 0}, stackaddr = 0x0, stacksize = 8364, 
          guardsize = 1, detachstate = __PTHREAD_CREATE_DETACHED, 
          inheritsched = __PTHREAD_EXPLICIT_SCHED, contentionscope = __PTHREAD_SCOPE_SYSTEM, 
          schedpolicy = 0}
#7  newm (fn=0x2001f58, p=0x2001f60) at ../../../src/libgo/runtime/proc.c:1344
        mp = 0x2030f800
#8  0x012ebd01 in handoffp (p=0x2030b000) at ../../../src/libgo/runtime/proc.c:1425
No locals.
#9  0x012ee3f4 in retake (now=<optimized out>) at ../../../src/libgo/runtime/proc.c:2797
        i = 0
        s = 33562092
        p = 0x1b1fa50 <entry_point>
#10 sysmon () at ../../../src/libgo/runtime/proc.c:2741
        gp = 0x0
#11 0x012ec8a0 in runtime_mstart (mp=0x810d5f0) at ../../../src/libgo/runtime/proc.c:1018
No locals.
#12 0x015b6d90 in stack_split_initialize_thread (varg=0x810cc40)
    at ../../../src/libgcc/generic-morestack-thread.c:127
        args = 0x810cc40
        err = <optimized out>
        start_routine = 0x12ec7c0 <runtime_mstart>
        arg = 0x2030d000
#13 0x01b1fa96 in entry_point (self=0x810cc50, 
    start_routine=0x15b6d40 <stack_split_initialize_thread>, arg=0x810cc40)
    at ./pthread/pt-create.c:63
No locals.
#14 0x00000000 in ?? ()
No symbol table info available.

Thread 5 (Thread 1205.5):
#0  0x0197aa4c in mach_msg_trap ()
    at /usr/src/eglibc-2.18/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
No locals.
#1  0x0197b22e in __mach_msg (msg=msg@entry=0x1ffdf20, option=option@entry=3, send_size=32, 
    rcv_size=rcv_size@entry=4096, rcv_name=rcv_name@entry=141, timeout=timeout@entry=0, 
    notify=notify@entry=0) at msg.c:110
        ret = <optimized out>
#2  0x0197b8ef in __mach_msg_server_timeout (demux=demux@entry=0x198bce0 <msgport_server>, 
    max_size=max_size@entry=4096, rcv_name=rcv_name@entry=141, option=option@entry=0, 
    timeout=timeout@entry=0) at msgserver.c:150
        request = 0x1ffdf20
        reply = 0x1ffef30
        mr = 0
        __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
#3  0x0197b9db in __mach_msg_server (demux=demux@entry=0x198bce0 <msgport_server>, max_size=4096, 
    rcv_name=141) at msgserver.c:195
No locals.
#4  0x0198bdcd in _hurd_msgport_receive () at msgportdemux.c:67
No locals.
#5  0x01b1fa96 in entry_point (self=0x810c120, start_routine=0x198bd70 <_hurd_msgport_receive>, 
    arg=0x0) at ./pthread/pt-create.c:63
No locals.
#6  0x00000000 in ?? ()
No symbol table info available.

Thread 4 (Thread 1205.4):
#0  0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
        err = <optimized out>
        err = <optimized out>
        user_option = 3
        user_timeout = 48
        m = 0x532370
        msgh_bits = 0
        remote_port = 268509186
        msgid = 21118
        save_data = <optimized out>
        __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
#1  0x00000005 in ?? ()
No symbol table info available.
#2  0x01a7a8dd in __mmap (addr=0x0, len=49880, prot=5, flags=33, fd=8, offset=0)
    at ../sysdeps/mach/hurd/mmap.c:92
        __ulink = {resource = {next = 0x0, prevp = 0x2cfcc}, thread = {next = 0x0, 
            prevp = 0x1b81c5c}, cleanup = 0x19a2c70 <_hurd_port_cleanup>, cleanup_data = 0x99}
        __ctty_ulink = {resource = {next = 0x0, prevp = 0x19fc6bc <_int_malloc+12>}, thread = {
            next = 0x17, prevp = 0x5}, cleanup = 0x0, cleanup_data = 0x700f2}
        __result = <optimized out>
        descriptor = 0x1b5e467 <__io_map+7>
        robj = 0
        wobj = 4608
        err = <optimized out>
        vmprot = 0
        memobj = <optimized out>
        mapaddr = 0
#3  0x00007b27 in _dl_map_object_from_fd (name=name@entry=0x532b58 "libnss_files.so.2", fd=8, 
    fbp=fbp@entry=0x5326dc, realname=0x810d768 "/lib/i386-gnu/libnss_files.so.2", 
    loader=loader@entry=0x0, l_type=l_type@entry=2, mode=mode@entry=-1879048191, 
    stack_endp=stack_endp@entry=0x5326d8, nsid=nsid@entry=0) at dl-load.c:1287
        c = <optimized out>
        nloadcmds = <optimized out>
        loadcmds = 0x532494
        has_holes = <optimized out>
        l = 0x810d790
        header = <optimized out>
        phdr = <optimized out>
        ph = <optimized out>
        maplength = <optimized out>
        type = <optimized out>
        st = {st_fstype = 23, st_fsid = 5, st_ino = 458994, st_gen = 1885249733, st_rdev = 0, 
          st_mode = 33188, st_nlink = 1, st_uid = 0, st_gid = 0, st_size = 46752, st_atim = {
            tv_sec = 1398336580, tv_nsec = 0}, st_mtim = {tv_sec = 1397789836, tv_nsec = 0}, 
          st_ctim = {tv_sec = 1398160744, tv_nsec = 0}, st_blksize = 8192, st_blocks = 96, 
          st_author = 0, st_flags = 0, st_spare = {0, 0, 0, 0, 0, 0, 0, 0}}
        errstring = <optimized out>
        errval = 0
        r = <optimized out>
        make_consistent = <optimized out>
        __PRETTY_FUNCTION__ = "_dl_map_object_from_fd"
        stack_flags = <optimized out>
#4  0x00008bb1 in _dl_map_object (loader=0x0, loader@entry=0x195a020, 
    name=name@entry=0x532b58 "libnss_files.so.2", type=type@entry=2, 
    trace_mode=trace_mode@entry=0, mode=mode@entry=-1879048191, nsid=0) at dl-load.c:2605
        fd = <optimized out>
        realname = 0x810d768 "/lib/i386-gnu/libnss_files.so.2"
        name_copy = <optimized out>
        l = <optimized out>
        fb = {len = 512, 
          buf = "\177ELF\001\001\001\000\000\000\000\000\000\000\000\000\003\000\003\000\001\000\000\000\220\032\000\000\064\000\000\000\360\261\000\000\000\000\000\000\064\000 \000\t\000(\000\036\000\035\000\006\000\000\000\064\000\000\000\064\000\000\000\064\000\000\000 \001\000\000 \001\000\000\005\000\000\000\004\000\000\000\003\000\000\000\t\216\000\000\t\216\000\000\t\216\000\000\r\000\000\000\r\000\000\000\004\000\000\000\001\000\000\000\001", '\000' <repeats 15 times>, "t\254\000\000t\254\000\000\005\000\000\000\000\020\000\000\001\000\000\000̮\000\000̾\000\000̾\000\000\374\001\000\000\f\004\000\000\006\000\000\000\000\020\000\000\002\000\000\000خ\000\000ؾ\000\000ؾ\000\000\b\001\000\000\b\001\000\000\006\000\000\000"...}
        __PRETTY_FUNCTION__ = "_dl_map_object"
        found_other_class = false
        stack_end = 0x1e00000
#5  0x000136e0 in dl_open_worker (a=0x5329fc) at dl-open.c:235
        args = 0x5329fc
        file = 0x532b58 "libnss_files.so.2"
        mode = -2147483647
        call_map = 0x195a020
        dst = <optimized out>
        __PRETTY_FUNCTION__ = "dl_open_worker"
        new = <optimized out>
        r = <optimized out>
        reloc_mode = <optimized out>
        nmaps = <optimized out>
        l = <optimized out>
        maps = <optimized out>
        relocation_in_progress = <optimized out>
        any_tls = <optimized out>
        first_static_tls = <optimized out>
#6  0x0000f5f1 in _dl_catch_error (objname=objname@entry=0x5329f4, 
    errstring=errstring@entry=0x5329f8, mallocedp=mallocedp@entry=0x5329f3, 
    operate=operate@entry=0x13620 <dl_open_worker>, args=args@entry=0x5329fc) at dl-error.c:177
        errcode = <optimized out>
        old = 0x532a94
        c = {objname = 0x0, errstring = 0x0, malloced = 208, env = {{__jmpbuf = {163840, 79392, 
                5450476, 5450296, 5450096, 62936}, __mask_was_saved = 26671407, 
              __saved_mask = 26671407}}}
        catchp = 0x28968 <data.8679>
#7  0x00013063 in _dl_open (file=0x532b58 "libnss_files.so.2", mode=-2147483647, 
    caller_dlopen=0x1aaa53a <__nss_lookup_function+650>, nsid=<optimized out>, argc=1, 
    argv=0x1dffdc4, env=0x1dffdcc) at dl-open.c:661
        args = {file = 0x532b58 "libnss_files.so.2", mode = -2147483647, 
          caller_dlopen = 0x1aaa53a <__nss_lookup_function+650>, 
          caller_dl_open = 0x1abdcbb <do_dlopen+91>, map = 0x0, nsid = 0, argc = 1, 
          argv = 0x1dffdc4, env = 0x1dffdcc}
        objname = 0x1 <Address 0x1 out of bounds>
        errstring = 0x0
        malloced = true
        errcode = <optimized out>
        __PRETTY_FUNCTION__ = "_dl_open"
#8  0x01abdcbb in do_dlopen (ptr=0x532b20) at dl-libc.c:87
        args = 0x532b20
#9  0x0000f5f1 in _dl_catch_error (objname=0x532ae8, errstring=0x532aec, mallocedp=0x532ae7, 
    operate=0x1abdc60 <do_dlopen>, args=0x532b20) at dl-error.c:177
        errcode = <optimized out>
        old = 0x0
        c = {
          objname = 0x1b16524 <main_arena+68> "\b\375\020\b0\332\020\b0\332\020\b0\332\020\b,e\261\001,e\261\001\064e\261\001\064e\261\001<e\261\001<e\261\001De\261\001De\261\001Le\261\001Le\261\001Te\261\001Te\261\001\\e\261\001\\e\261\001de\261\001de\261\001le\261\001le\261\001te\261\001te\261\001|e\261\001|e\261\001\204e\261\001\204e\261\001\214e\261\001\214e\261\001\224e\261\001\224e\261\001\234e\261\001\234e\261\001\244e\261\001\244e\261\001\254e\261\001\254e\261\001\264e\261\001\264e\261\001\274e\261\001\274e\261\001\304e\261\001\304e\261\001\314e\261\001\314e\261\001\324e\261\001\324e\261\001\334e\261\001\334e\261\001"..., errstring = 0x0, malloced = false, env = {{__jmpbuf = {
                163840, 163104, 5450476, 5450504, 5450352, 62936}, __mask_was_saved = 0, 
              __saved_mask = 56}}}
        catchp = 0x28968 <data.8679>
#10 0x01abddab in dlerror_run (operate=operate@entry=0x1abdc60 <do_dlopen>, 
    args=args@entry=0x532b20) at dl-libc.c:46
        objname = 0x0
        last_errstring = 0x0
        malloced = false
        result = <optimized out>
#11 0x01abde32 in __libc_dlopen_mode (name=name@entry=0x532b58 "libnss_files.so.2", 
    mode=mode@entry=-2147483647) at dl-libc.c:163
        args = {name = 0x532b58 "libnss_files.so.2", mode = -2147483647, 
          caller_dlopen = 0x1aaa53a <__nss_lookup_function+650>, 
          map = 0x1abddf0 <__libc_dlopen_mode>}
#12 0x01aaa53a in nss_load_library (ni=<optimized out>, ni=<optimized out>) at nsswitch.c:399
        shlen = <optimized out>
        saved_errno = <optimized out>
        shlib_name = 0x532b58 "libnss_files.so.2"
#13 __nss_lookup_function (ni=0x810fa20, fct_name=fct_name@entry=0x1ad8781 "gethostbyname4_r")
    at nsswitch.c:507
        known = <optimized out>
        found = <optimized out>
        result = <optimized out>
#14 0x01a40c59 in gaih_inet (name=<optimized out>, service=<optimized out>, 
    req=req@entry=0x2032f200, pai=pai@entry=0x533154, naddrs=naddrs@entry=0x533160)
    at ../sysdeps/posix/getaddrinfo.c:857
        fct4 = 0x0
        pat = 0x5330a8
        no_inet6_data = 0
        nip = 0x810fa20
        status = NSS_STATUS_UNAVAIL
        no_more = 0
        old_res_options = <optimized out>
        tmpbuflen = 1056
        no_data = 0
        inet6_status = NSS_STATUS_UNAVAIL
        tp = <optimized out>
        st = 0x533040
        at = 0x533010
        rc = 5452000
        got_ipv6 = false
        canon = 0x0
        orig_name = <optimized out>
        alloca_used = 1152
        port = <optimized out>
        malloc_name = <optimized out>
        malloc_addrmem = false
        addrmem = 0x0
        malloc_canonbuf = false
        canonbuf = 0x0
        malloc_tmpbuf = false
        tmpbuf = 0x532be0 ""
        result = 0
        __PRETTY_FUNCTION__ = "gaih_inet"
#15 0x01a42bc8 in getaddrinfo (name=<optimized out>, service=<optimized out>, hints=0x2032f200, 
    pai=0x203066a8) at ../sysdeps/posix/getaddrinfo.c:2490
        i = 0
        last_i = 0
        nresults = 0
        p = 0x0
        gaih_service = {name = 0x12d8996 <__go_copy+6> "\201\303\372OY", num = 25614736}
        pservice = <optimized out>
        local_hints = {ai_flags = -1, ai_family = 60530, ai_socktype = 26619956, 
          ai_protocol = 26583072, ai_addrlen = 1, ai_addr = 0x5, ai_canonname = 0x0, 
          ai_next = 0x104e000}
        in6ai = 0x0
        in6ailen = 0
        seen_ipv4 = false
        seen_ipv6 = false
        check_pf_called = false
        end = 0x533154
        naddrs = 0
        __PRETTY_FUNCTION__ = "getaddrinfo"
#16 0x08092442 in net.cgoLookupIPCNAME (name=...) at cgo_unix.go:117
        res = 0x203066a8
        hints = 0x2032f200
        h = 0x2032d4c0 "localhost"
        gerrno = <optimized out>
        completed = false
        err = {__methods = 0x0, __object = 0x0}
        cname = <optimized out>
        addrs = {__values = 0x0, __count = 0, __capacity = 0}
#17 0x080a74bb in net.cgoLookupIP (name=...) at cgo_unix.go:171
No locals.
#18 net.lookupIP (host=...) at lookup_unix.go:64
No locals.
#19 net.$nested123 () at lookup.go:41
        $closure = 0x0
#20 0x080abc09 in net.Do.pN16_net.singleflight (g=0x810b150 <net.lookupGroup>, key=..., 
    fn=0x203066a0) at singleflight.go:45
        c = 0x20316330
#21 0x080a738c in net.lookupIPMerge (host.param=...) at lookup.go:40
        addrsi = <optimized out>
        shared = <optimized out>
        err = {__methods = 0x0, __object = 0x0}
        addrs = {__values = 0x0, __count = 0, __capacity = 0}
        host = 0x20306698
#22 0x080a72e2 in net.LookupIP (host=...) at lookup.go:31
No locals.
#23 0x080c51f7 in net.$init0 () at ipraw_test.go:53
No locals.
#24 net..import () at conn_test.go:8
No locals.
#25 0x080c8044 in main.init () at _testmain.go:1
No locals.
#26 0x080c81c5 in __morestack () at ../../../src/libgcc/config/i386/morestack.S:362
No locals.
#27 0x012ed808 in runtime_main (dummy=0x0) at ../../../src/libgo/runtime/proc.c:550
        d = {__next = 0x0, __frame = 0x185f93, __panic = 0x0, __pfn = 0x12ed880 <initDone>, 
          __arg = 0xffffffff, __retaddr = 0x0, __makefunc_can_recover = false, __free = false}
        frame = false
#28 0x012eb47f in kickoff () at ../../../src/libgo/runtime/proc.c:229
No locals.
#29 0x019cbec8 in makecontext () at ../sysdeps/mach/hurd/i386/makecontext.S:95
No locals.
#30 0x00000000 in ?? ()
No symbol table info available.
A debugging session is active.

	Inferior 1 [bogus thread id 0] will be killed.

Quit anyway? (y or n)
task130(pid1182)->vm_statistics () = 0 {4096 431565 4762 9123 5800 41985 0 8257 892 499991 64136 41788 41214}
task130(pid1182)->vm_region (134217728) = 0 134512640 774144 5 7 1 0    137<--135(pid1182) 0
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
task130(pid1182)->vm_region (135286784) = 0 135286784 20480 3 7 1 0    137<--138(pid1182) 770048
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
task130(pid1182)->vm_region (135307264) = 0 135307264 4096 3 7 1 0    137<--135(pid1182) 0
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
task130(pid1182)->vm_region (135311360) = 0 135311360 4096 3 7 1 0  (null) 0
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_region (135315456) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_map (135315456 2012168192 0 0  (null) 0 1 0 0 1) = 0 135315456
task130(pid1182)->vm_map (0 4096 0 0  (null) 0 1 0 0 1) = 0 0
task130(pid1182)->task_get_special_port (4) = 0    137<--138(pid1182)
  137<--138(pid1182)->exec_startup_get_info () = 0 134599838 134512692 288 172032 16777216 0 "./a.out" "QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index" {  107<--135(pid1182)   89<--140(pid1182)   89<--140(pid1182)} {  109<--141(pid1182)   93<--142(pid1182)   105<--143(pid1182)   139<--144(pid1182)   118<--145(pid1182) (null)} {18 0 0 0 0}
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
task130(pid1182)->vm_deallocate (135315456 2012168192) = 0 
task130(pid1182)->vm_map (0 4096 0 1  (null) 0 0 3 7 1) = 0 16969728
  93<--142(pid1182)->dir_lookup ("etc/ld.so.cache" 1 0) = 0 1 ""    137<--146(pid1182)
  137<--146(pid1182)->io_stat_request () = 0 {23 5 0 82072 0 1398453432 0 33188 1 0 0 120318 0 1398334121 0 1398334121 0 1398334121 0 8192 248 0 0 0 0 0 0 0 0 0 0 0}
  137<--146(pid1182)->io_map_request () = 0    147<--138(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (0 120318 0 1    147<--138(pid1182) 0 32 1 7 1) = 0 16973824
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
  93<--142(pid1182)->dir_lookup ("usr/lib/i386-gnu/libgo.so.5" 1 0) = 0 1 ""    137<--148(pid1182)
  137<--148(pid1182)->io_read_request (-1 512) = 0 "\x7fELF\x01\x01\x01"
  137<--148(pid1182)->io_stat_request () = 0 {23 5 0 1753934 0 1398429764 0 33188 1 0 0 10168788 0 1398335701 0 1398191002 0 1398234898 0 8192 19896 0 0 0 0 0 0 0 0 0 0 0}
  137<--148(pid1182)->io_map_request () = 0    147<--146(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (0 9081448 0 1    147<--146(pid1182) 0 32 5 7 1) = 0 17096704
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
  137<--148(pid1182)->io_map_request () = 0    147<--138(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (23552000 2473984 0 0    147<--138(pid1182) 6455296 32 3 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (23552000 2473984) = 0 
task130(pid1182)->vm_map (23552000 2473984 0 0    147<--138(pid1182) 6455296 32 3 7 1) = 0 23552000
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->vm_map (26025984 152168 0 0  (null) 0 0 3 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (26025984 152168) = 0 
task130(pid1182)->vm_map (26025984 152168 0 0  (null) 0 0 3 7 1) = 0 26025984
task130(pid1182)->vm_protect (172032 16777216 0 7) = 0 
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libm.so.6" 1 0) = 0 1 ""    137<--146(pid1182)
  137<--146(pid1182)->io_read_request (-1 512) = 0 "\x7fELF\x01\x01\x01"
  137<--146(pid1182)->io_stat_request () = 0 {23 5 0 458811 0 1885249721 0 33188 1 0 0 276044 0 1398335701 0 1397789835 0 1398160744 0 8192 552 0 0 0 0 0 0 0 0 0 0 0}
  137<--146(pid1182)->io_map_request () = 0    147<--148(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (0 278720 0 1    147<--148(pid1182) 0 32 5 7 1) = 0 26181632
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
  137<--146(pid1182)->io_map_request () = 0    147<--138(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (26456064 8192 0 0    147<--138(pid1182) 270336 32 3 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (26456064 8192) = 0 
task130(pid1182)->vm_map (26456064 8192 0 0    147<--138(pid1182) 270336 32 3 7 1) = 0 26456064
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libgcc_s.so.1" 1 0) = 0 1 ""    137<--148(pid1182)
  137<--148(pid1182)->io_read_request (-1 512) = 0 "\x7fELF\x01\x01\x01"
  137<--148(pid1182)->io_stat_request () = 0 {23 5 0 458816 0 1398429740 0 33188 1 0 0 114436 0 1398335701 0 1398190923 0 1398234897 0 8192 232 0 0 0 0 0 0 0 0 0 0 0}
  137<--148(pid1182)->io_map_request () = 0    147<--146(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (0 117648 0 1    147<--146(pid1182) 0 32 5 7 1) = 0 26464256
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
  137<--148(pid1182)->io_map_request () = 0    147<--138(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (26578944 4096 0 0    147<--138(pid1182) 110592 32 3 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (26578944 4096) = 0 
task130(pid1182)->vm_map (26578944 4096 0 0    147<--138(pid1182) 110592 32 3 7 1) = 0 26578944
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libc.so.0.3" 1 0) = 0 1 ""    137<--146(pid1182)
  137<--146(pid1182)->io_read_request (-1 512) = 0 "\x7fELF\x01\x01\x01"
task130(pid1182)->vm_map (0 4096 0 1  (null) 0 0 3 7 1) = 0 26583040
  137<--146(pid1182)->io_stat_request () = 0 {23 5 0 458796 0 1885249711 0 33261 1 0 0 1825700 0 1398335701 0 1397789834 0 1398160744 0 8192 3576 0 0 0 0 0 0 0 0 0 0 0}
  137<--146(pid1182)->io_map_request () = 0    147<--148(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (0 1833672 0 1    147<--148(pid1182) 0 32 5 7 1) = 0 26587136
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
  137<--146(pid1182)->io_map_request () = 0    147<--138(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (28385280 20480 0 0    147<--138(pid1182) 1794048 32 3 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (28385280 20480) = 0 
task130(pid1182)->vm_map (28385280 20480 0 0    147<--138(pid1182) 1794048 32 3 7 1) = 0 28385280
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->vm_map (28405760 15048 0 0  (null) 0 0 3 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (28405760 15048) = 0 
task130(pid1182)->vm_map (28405760 15048 0 0  (null) 0 0 3 7 1) = 0 28405760
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libpthread.so.0.3" 1 0) = 0 1 ""    137<--148(pid1182)
  137<--148(pid1182)->io_read_request (-1 512) = 0 "\x7fELF\x01\x01\x01"
  137<--148(pid1182)->io_stat_request () = 0 {23 5 0 459002 0 1885249743 0 33261 1 0 0 76661 0 1398335701 0 1397789850 0 1398160744 0 8192 160 0 0 0 0 0 0 0 0 0 0 0}
  137<--148(pid1182)->io_map_request () = 0    147<--146(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (0 62032 0 1    147<--146(pid1182) 0 32 5 7 1) = 0 28422144
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
  137<--148(pid1182)->io_map_request () = 0    147<--138(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (28479488 8192 0 0    147<--138(pid1182) 53248 32 3 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (28479488 8192) = 0 
task130(pid1182)->vm_map (28479488 8192 0 0    147<--138(pid1182) 53248 32 3 7 1) = 0 28479488
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libmachuser.so.1" 1 0) = 0 1 ""    137<--146(pid1182)
  137<--146(pid1182)->io_read_request (-1 512) = 0 "\x7fELF\x01\x01\x01"
  137<--146(pid1182)->io_stat_request () = 0 {23 5 0 458822 0 1885249723 0 33188 1 0 0 87464 0 1398335701 0 1397789835 0 1398160744 0 8192 184 0 0 0 0 0 0 0 0 0 0 0}
  137<--146(pid1182)->io_map_request () = 0    147<--148(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (0 90176 0 1    147<--148(pid1182) 0 32 5 7 1) = 0 28487680
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
  137<--146(pid1182)->io_map_request () = 0    147<--138(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (28573696 8192 0 0    147<--138(pid1182) 81920 32 3 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (28573696 8192) = 0 
task130(pid1182)->vm_map (28573696 8192 0 0    147<--138(pid1182) 81920 32 3 7 1) = 0 28573696
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libhurduser.so.0.3" 1 0) = 0 1 ""    137<--148(pid1182)
  137<--148(pid1182)->io_read_request (-1 512) = 0 "\x7fELF\x01\x01\x01"
  137<--148(pid1182)->io_stat_request () = 0 {23 5 0 458802 0 1885249719 0 33188 1 0 0 198292 0 1398335701 0 1397789835 0 1398160744 0 8192 400 0 0 0 0 0 0 0 0 0 0 0}
  137<--148(pid1182)->io_map_request () = 0    147<--146(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (0 201004 0 1    147<--146(pid1182) 0 32 5 7 1) = 0 28581888
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
  137<--148(pid1182)->io_map_request () = 0    147<--138(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (28778496 8192 0 0    147<--138(pid1182) 192512 32 3 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (28778496 8192) = 0 
task130(pid1182)->vm_map (28778496 8192 0 0    147<--138(pid1182) 192512 32 3 7 1) = 0 28778496
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libihash.so.0.3" 1 0) = 0 1 ""    137<--146(pid1182)
  137<--146(pid1182)->io_read_request (-1 512) = 0 "\x7fELF\x01\x01\x01"
  137<--146(pid1182)->io_stat_request () = 0 {23 5 0 458928 0 1396242757 0 33188 1 0 0 9532 0 1398335701 0 1395834589 0 1396193042 0 8192 24 0 0 0 0 0 0 0 0 0 0 0}
  137<--146(pid1182)->io_map_request () = 0    147<--148(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (0 12340 0 1    147<--148(pid1182) 0 32 5 7 1) = 0 28786688
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
  137<--146(pid1182)->io_map_request () = 0    147<--138(pid1182)  (null)
task130(pid1182)->mach_port_deallocate (pn{  0}) = 0xf ((os/kern) invalid name) 
task130(pid1182)->vm_map (28794880 8192 0 0    147<--138(pid1182) 4096 32 3 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (28794880 8192) = 0 
task130(pid1182)->vm_map (28794880 8192 0 0    147<--138(pid1182) 4096 32 3 7 1) = 0 28794880
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
task130(pid1182)->vm_map (0 4096 0 1  (null) 0 0 3 7 1) = 0 28803072
task130(pid1182)->vm_map (0 4096 0 1  (null) 0 0 3 7 1) = 0 28807168
thread132(pid1182)->i386_set_gdt (-1 {-1892876289 30405303}) = 0 75
task130(pid1182)->mach_port_deallocate (pn{  3}) = 0 
task130(pid1182)->vm_protect (28778496 4096 0 1) = 0 
task130(pid1182)->vm_protect (28573696 4096 0 1) = 0 
task130(pid1182)->vm_protect (26587136 1798144 0 3) = 0 
task130(pid1182)->vm_protect (26587136 1798144 0 5) = 0 
task130(pid1182)->vm_protect (28385280 12288 0 1) = 0 
task130(pid1182)->vm_protect (28794880 4096 0 1) = 0 
task130(pid1182)->vm_protect (28479488 4096 0 1) = 0 
task130(pid1182)->vm_protect (26456064 4096 0 1) = 0 
task130(pid1182)->vm_map (0 4096 0 1  (null) 0 0 3 7 1) = 0 28811264
task130(pid1182)->vm_map (0 8192 0 1  (null) 0 0 3 7 1) = 0 28815360
task130(pid1182)->vm_map (0 16384 0 1  (null) 0 0 3 7 1) = 0 28823552
task130(pid1182)->vm_protect (159744 4096 0 1) = 0 
task130(pid1182)->mach_port_mod_refs (pn{ 11} 1 -1) = 0 
task130(pid1182)->mach_port_deallocate (pn{  1}) = 0 
task130(pid1182)->vm_statistics () = 0 {4096 431189 4801 9457 5803 42011 0 8260 892 501649 64486 42307 41733}
task130(pid1182)->vm_map (135315456 134193152 0 0  (null) 0 0 0 7 1) = 0 135315456
task130(pid1182)->vm_allocate (28803696 4096 1) = 0 28839936
task130(pid1182)->mach_port_mod_refs (pn{ 11} 0 1) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->vm_protect (135315456 135168 0 7) = 0 
task130(pid1182)->vm_allocate (0 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (2097152 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (4194304 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (6291456 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (8388608 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (10485760 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (12582912 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (14680064 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (16777216 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (18874368 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (20971520 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (23068672 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (25165824 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (27262976 2097152 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (29360128 2097152 0) = 0 29360128
task130(pid1182)->mach_port_allocate (1) = 0 pn{ 12}
task130(pid1182)->mach_port_insert_right (pn{ 12}  137) = 0 
task130(pid1182)->mach_port_set_qlimit (pn{ 12} 1) = 0 
task130(pid1182)->vm_protect (29360128 1 0 0) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->vm_deallocate (172032 16777216) = 0 
task130(pid1182)->vm_allocate (26587136 4096 1) = 0 172032
task130(pid1182)->task_set_special_port (4  (null)) = 0 
task130(pid1182)->mach_port_allocate (1) = 0 pn{ 13}
task130(pid1182)->mach_port_insert_right (pn{ 13}  146) = 0 
task130(pid1182)->vm_allocate (31457280 2097152 0) = 0 31457280
task130(pid1182)->mach_port_allocate (1) = 0 pn{ 14}
task130(pid1182)->mach_port_insert_right (pn{ 14}  147) = 0 
task130(pid1182)->mach_port_set_qlimit (pn{ 14} 1) = 0 
task130(pid1182)->thread_create () = 0    138<--148(pid1182)
task130(pid1182)->vm_protect (31457280 1 0 0) = 0 
thread138(pid1182)->thread_get_state (5 17) = 0 {31 31 31 31 0 0 0 0 0 0 0 0 0 23 512 0 31}
thread138(pid1182)->i386_set_gdt (75 {-887816193 147845648}) = 0 75
thread138(pid1182)->thread_set_state (5 {75 31 31 31 0 0 0 0 0 0 0 0 28441168 23 512 33554412 31}) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->vm_allocate (75 4096 1) = 0 176128
task130(pid1182)->mach_port_mod_refs (pn{ 15} 0 1) = 0 
thread138(pid1182)->thread_resume () = 0 
task130(pid1182)->mach_port_deallocate (pn{ 15}) = 0 
task130(pid1182)->task_set_special_port (3    146<--150(pid-1)) = 0 
  139<--144(pid1182)->proc_setmsgport_request (   146<--150(pid-1)) = 0  (null)
  139<--144(pid1182)->proc_set_arg_locations_request (31456724 16948764) = 0 
task130(pid1182)->mach_port_allocate (1) = 0 pn{ 17}
task130(pid1182)->mach_port_allocate (1) = 0 pn{ 18}
task130(pid1182)->mach_port_insert_right (pn{ 17}  151) = 0 
task130(pid1182)->mach_port_set_qlimit (pn{ 18} 1) = 0 
  139<--144(pid1182)->proc_handle_exceptions_request (   151<--153(pid-1)    152<--154(pid-1) 5 {75 31 31 31 0 0 0 0 0 0 0 0 26824928 23 0 28407008 0}) = 0 
thread138(pid1182)->thread_set_special_port (3  153) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 17}) = 0 
  139<--144(pid1182)->proc_getpids_request () = 0 1182 1181 0
  139<--144(pid1182)->proc_getpgrp_request (1182) = 0 1181
task130(pid1182)->vm_deallocate (16965632 20) = 0 
task130(pid1182)->vm_deallocate (16961536 24) = 0 
task130(pid1182)->vm_allocate (26723349 4096 1) = 0 180224
task130(pid1182)->vm_allocate (180224 4096 1) = 0 184320
  107<--135(pid1182)->term_getctty () = 0    118<--145(pid1182)
task130(pid1182)->mach_port_deallocate (pn{ 10}) = 0 
  107<--135(pid1182)->term_open_ctty (1182 1181) = 0    153<--149(pid1182)
  89<--140(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  89<--140(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
task130(pid1182)->vm_deallocate (16957440 12) = 0 
task130(pid1182)->vm_map (0 0 0 1  (null) 0 1 1 7 1) = 0x4 ((os/kern) invalid argument) 
task130(pid1182)->vm_protect (0 0 0 0) = 0 
task130(pid1182)->vm_map (0 0 0 1  (null) 0 1 1 7 1) = 0x4 ((os/kern) invalid argument) 
task130(pid1182)->vm_protect (0 0 0 0) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->vm_allocate (0 1056768 1) = 0 188416
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->vm_allocate (0 262144 1) = 0 1245184
task130(pid1182)->vm_map (136314880 807403520 0 0  (null) 0 1 0 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_map (136314880 807403520 0 1  (null) 0 1 0 7 1) = 0 269508608
task130(pid1182)->vm_allocate (540041216 1048576 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (540041216 1048576) = 0 
task130(pid1182)->vm_allocate (540041216 1048576 0) = 0 540041216
task130(pid1182)->vm_allocate (539910144 131072 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (539910144 131072) = 0 
task130(pid1182)->vm_allocate (539910144 131072 0) = 0 539910144
task130(pid1182)->vm_allocate (269508608 4096 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (269508608 4096) = 0 
task130(pid1182)->vm_allocate (269508608 4096 0) = 0 269508608
task130(pid1182)->vm_allocate (0 65536 1) = 0 1507328
task130(pid1182)->vm_allocate (0 4096 1) = 0 1572864
  109<--141(pid1182)->dir_lookup ("./a.out" 4194305 0) = 0 1 ""    155<--151(pid1182)
  155<--151(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  155<--151(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 0 1 1 7 1) = 0 1576960
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1576960 4096) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 8192 0 1    157<--158(pid1182) 1462272 1 1 7 1) = 0 1576960
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 1462272 1 1 7 1) = 0 1585152
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 86016 0 1    157<--158(pid1182) 1298432 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 86016 0 1    157<--156(pid1182) 1380352 1 1 7 1) = 0 1675264
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_allocate (0 57344 1) = 0 1761280
task130(pid1182)->vm_deallocate (1589248 86016) = 0 
task130(pid1182)->vm_deallocate (1576960 8192) = 0 
task130(pid1182)->vm_deallocate (1585152 4096) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 471040 0 1    157<--158(pid1182) 831488 1 1 7 1) = 0 1818624
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 20}) = 0 
task130(pid1182)->vm_allocate (0 4096 1) = 0 1576960
task130(pid1182)->vm_allocate (0 4096 1) = 0 1581056
task130(pid1182)->vm_allocate (0 4096 1) = 0 1585152
  93<--142(pid1182)->dir_lookup ("usr/lib/i386-gnu/libgo.so.5" 4194305 0) = 0 1 ""    155<--156(pid1182)
  155<--156(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  155<--156(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--151(pid1182) 0 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
  155<--156(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--158(pid1182) 10166272 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--156(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--151(pid1182) 10166272 1 1 7 1) = 0 1593344
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--156(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 307200 0 1    157<--158(pid1182) 155648 1 1 7 1) = 0 2289664
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--156(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 856064 0 1    157<--151(pid1182) 458752 1 1 7 1) = 0 2596864
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_allocate (0 229376 1) = 0 3452928
task130(pid1182)->vm_deallocate (2289664 307200) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
task130(pid1182)->vm_deallocate (1593344 4096) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 20}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libm.so.6" 4194305 0) = 0 1 ""    155<--158(pid1182)
  155<--158(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  155<--158(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 0 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
  155<--158(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--151(pid1182) 274432 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--158(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 274432 1 1 7 1) = 0 1593344
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--158(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 12288 0 1    157<--151(pid1182) 4096 1 1 7 1) = 0 1597440
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--158(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 12288 1 1 7 1) = 0 1609728
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_allocate (0 8192 1) = 0 1613824
task130(pid1182)->vm_deallocate (1597440 12288) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
task130(pid1182)->vm_deallocate (1593344 4096) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 20}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libgcc_s.so.1" 4194305 0) = 0 1 ""    155<--151(pid1182)
  155<--151(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  155<--151(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--158(pid1182) 0 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 110592 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--158(pid1182) 110592 1 1 7 1) = 0 1593344
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 0 1 1 7 1) = 0 1597440
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 8192 0 1    157<--158(pid1182) 0 1 1 7 1) = 0 1601536
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1597440 4096) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
task130(pid1182)->vm_deallocate (1593344 4096) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 20}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libc.so.0.3" 4194305 0) = 0 1 ""    155<--156(pid1182)
  155<--156(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  155<--156(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--151(pid1182) 0 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
  155<--156(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 8192 0 1    157<--158(pid1182) 1818624 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--156(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--151(pid1182) 1818624 1 1 7 1) = 0 1597440
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--156(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 45056 0 1    157<--158(pid1182) 12288 1 1 7 1) = 0 1622016
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--156(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 32768 0 1    157<--151(pid1182) 53248 1 1 7 1) = 0 2289664
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_allocate (0 28672 1) = 0 2322432
task130(pid1182)->vm_deallocate (1622016 45056) = 0 
task130(pid1182)->vm_deallocate (1589248 8192) = 0 
task130(pid1182)->vm_deallocate (1597440 4096) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 20}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/ld.so" 4194305 0) = 0 1 ""    155<--158(pid1182)
  155<--158(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  155<--158(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 0 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
  155<--158(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--151(pid1182) 155648 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--158(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 155648 1 1 7 1) = 0 1593344
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--158(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--151(pid1182) 0 1 1 7 1) = 0 1597440
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--158(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 0 1 1 7 1) = 0 1622016
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1597440 4096) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
task130(pid1182)->vm_deallocate (1593344 4096) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 20}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libpthread.so.0.3" 4194305 0) = 0 1 ""    155<--151(pid1182)
  155<--151(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  155<--151(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--158(pid1182) 0 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 57344 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--158(pid1182) 57344 1 1 7 1) = 0 1593344
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 12288 0 1    157<--156(pid1182) 57344 1 1 7 1) = 0 1626112
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 12288 0 1    157<--158(pid1182) 65536 1 1 7 1) = 0 1638400
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_allocate (0 8192 1) = 0 1650688
task130(pid1182)->vm_deallocate (1626112 12288) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
task130(pid1182)->vm_deallocate (1593344 4096) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 20}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libmachuser.so.1" 4194305 0) = 0 1 ""    155<--156(pid1182)
  155<--156(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  155<--156(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--151(pid1182) 0 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
  155<--156(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--158(pid1182) 86016 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--156(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--151(pid1182) 86016 1 1 7 1) = 0 1593344
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--156(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 8192 0 1    157<--158(pid1182) 4096 1 1 7 1) = 0 1626112
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--156(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 8192 0 1    157<--151(pid1182) 8192 1 1 7 1) = 0 1658880
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1626112 8192) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
task130(pid1182)->vm_deallocate (1593344 4096) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 20}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libhurduser.so.0.3" 4194305 0) = 0 1 ""    155<--158(pid1182)
  155<--158(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  155<--158(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 0 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
  155<--158(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--151(pid1182) 196608 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--158(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 196608 1 1 7 1) = 0 1593344
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--158(pid1182)->io_map_request () = 0    157<--151(pid1182)  (null)
task130(pid1182)->vm_map (0 16384 0 1    157<--151(pid1182) 4096 1 1 7 1) = 0 2351104
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--158(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 12288 0 1    157<--156(pid1182) 16384 1 1 7 1) = 0 1626112
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_allocate (0 12288 1) = 0 2367488
task130(pid1182)->vm_deallocate (2351104 16384) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
task130(pid1182)->vm_deallocate (1593344 4096) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 20}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libihash.so.0.3" 4194305 0) = 0 1 ""    155<--151(pid1182)
  155<--151(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  155<--151(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--158(pid1182) 0 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 8192 1 1 7 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--158(pid1182) 8192 1 1 7 1) = 0 1593344
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--156(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--156(pid1182) 0 1 1 7 1) = 0 1597440
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
  155<--151(pid1182)->io_map_request () = 0    157<--158(pid1182)  (null)
task130(pid1182)->vm_map (0 4096 0 1    157<--158(pid1182) 0 1 1 7 1) = 0 1667072
task130(pid1182)->mach_port_deallocate (pn{ 21}) = 0 
task130(pid1182)->vm_deallocate (1597440 4096) = 0 
task130(pid1182)->vm_deallocate (1589248 4096) = 0 
task130(pid1182)->vm_deallocate (1593344 4096) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 20}) = 0 
task130(pid1182)->vm_allocate (0 719996 1) = 0 3682304
task130(pid1182)->vm_allocate (0 36864 1) = 0 2379776
task130(pid1182)->vm_allocate (0 12288 1) = 0 1589248
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->vm_allocate (0 36864 1) = 0 2416640
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->vm_allocate (33554432 8364 0) = 0 33554432
task130(pid1182)->mach_port_allocate (1) = 0 pn{ 20}
task130(pid1182)->mach_port_insert_right (pn{ 20}  155) = 0 
task130(pid1182)->mach_port_set_qlimit (pn{ 20} 1) = 0 
task130(pid1182)->thread_create () = 0    151<--156(pid1182)
task130(pid1182)->vm_protect (33554432 1 0 0) = 0 
thread151(pid1182)->thread_get_state (5 17) = 0 {31 31 31 31 0 0 0 0 0 0 0 0 0 23 512 0 31}
thread151(pid1182)->i386_set_gdt (75 {-700121089 147845648}) = 0 75
thread151(pid1182)->thread_set_state (5 {75 31 31 31 0 0 0 0 0 0 0 0 28441168 23 512 33562780 31}) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_mod_refs (pn{ 21} 0 1) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
thread151(pid1182)->thread_resume () = 0 
task130(pid1182)->mach_port_deallocate (pn{ 21}) ...134
task130(pid1182)->mach_port_deallocate (pn{ 11}) ...159
134... = 0 
159... = 0 
task130(pid1182)->vm_map (0 2097152 0 1  (null) 0 1 0 7 1) ...159
task130(pid1182)->vm_allocate (0 12288 1) ...134
159... = 0 4403200
134... = 0 2351104
task130(pid1182)->vm_deallocate (4403200 839680) ...134
task130(pid1182)->vm_allocate (0 1056768 1) ...159
134... = 0 
159... = 0 6500352
task130(pid1182)->vm_deallocate (6291456 208896) ...159
  93<--142(pid1182)->dir_lookup ("etc/nsswitch.conf" 4194305 0) ...134
159... = 0 
134... = 0 1 ""    158<--157(pid1182)
task130(pid1182)->vm_protect (5242880 135168 0 3) ...134
  158<--157(pid1182)->term_getctty () ...159
134... = 0 
159... = 0xfffffed1 ((ipc/mig) bad request message ID) 
task130(pid1182)->mach_port_deallocate (pn{ 21}) ...159
  158<--157(pid1182)->io_stat_request () ...134
159... = 0 
134... = 0 {23 5 0 81947 0 1368812549 0 33188 1 0 0 475 0 1398335675 0 1156782799 0 1368797468 0 8192 8 0 0 0 0 0 0 0 0 0 0 0}
task130(pid1182)->mach_port_deallocate (pn{ 21}) ...134
  158<--157(pid1182)->io_read_request (-1 8192) ...159
134... = 0 
159... = 0 "# /etc/nsswitch.conf\n#\n# Example configuration of GNU Name Service Switch functi"
  158<--157(pid1182)->io_read_request (-1 8192) = 0 ""
task130(pid1182)->mach_port_deallocate (pn{ 23}) = 0 
  93<--142(pid1182)->dir_lookup ("etc/host.conf" 4194305 0) = 0 1 ""    158<--160(pid1182)
  158<--160(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  158<--160(pid1182)->io_stat_request () = 0 {23 5 0 81932 0 1368800999 0 33188 1 0 0 9 0 1398335675 0 1154970849 0 1368797442 0 8192 8 0 0 0 0 0 0 0 0 0 0 0}
  158<--160(pid1182)->io_read_request (-1 8192) = 0 "multi on\n"
  158<--160(pid1182)->io_read_request (-1 8192) = 0 ""
task130(pid1182)->mach_port_deallocate (pn{ 23}) = 0 
  93<--142(pid1182)->dir_lookup ("etc/resolv.conf" 4194305 0) = 0 1 ""    158<--157(pid1182)
  158<--157(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  158<--157(pid1182)->io_stat_request () = 0 {23 5 0 82050 0 1398335472 0 33188 1 0 0 20 0 1398335675 0 1398335471 0 1398335471 0 8192 8 0 0 0 0 0 0 0 0 0 0 0}
  158<--157(pid1182)->io_read_request (-1 8192) = 0 "nameserver 10.0.2.3\n"
  158<--157(pid1182)->io_read_request (-1 8192) = 0 ""
task130(pid1182)->mach_port_deallocate (pn{ 23}) = 0 
  93<--142(pid1182)->dir_lookup ("etc/hostname" 1 0) = 0 1 ""    158<--160(pid1182)
  158<--160(pid1182)->io_read_request (-1 255) = 0 "hurd-2013\n"
  158<--160(pid1182)->io_readable_request () = 0 0
task130(pid1182)->mach_port_deallocate (pn{ 23}) = 0 
  93<--142(pid1182)->dir_lookup ("lib/i386-gnu/libnss_files.so.2" 4194305 0) = 0 1 ""    158<--157(pid1182)
  158<--157(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  158<--157(pid1182)->io_read_request (-1 512) = 0 "\x7fELF\x01\x01\x01"
  158<--157(pid1182)->io_stat_request () = 0 {23 5 0 458994 0 1885249733 0 33188 1 0 0 46752 0 1398335701 0 1397789836 0 1398160744 0 8192 96 0 0 0 0 0 0 0 0 0 0 0}
  158<--157(pid1182)->io_map_request () = 0    133<--160(pid1182)  (null)
task130(pid1182)->vm_map (0 49880 0 1    133<--160(pid1182) 0 1 5 7 1) = 0 2453504
task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0 
  158<--157(pid1182)->io_map_request () = 0    133<--162(pid1182)  (null)
task130(pid1182)->vm_map (2498560 8192 0 0    133<--162(pid1182) 40960 1 3 7 1) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_deallocate (2498560 8192) = 0 
task130(pid1182)->vm_map (2498560 8192 0 0    133<--162(pid1182) 40960 1 3 7 1) = 0 2498560
task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 23}) = 0 
task130(pid1182)->vm_protect (2498560 4096 0 1) = 0 
  93<--142(pid1182)->dir_lookup ("etc/hosts" 4194305 0) = 0 1 ""    158<--160(pid1182)
  158<--160(pid1182)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) 
  158<--160(pid1182)->io_stat_request () = 0 {23 5 0 81987 0 1368845833 0 33188 1 0 0 248 0 1398335660 0 1368797592 0 1368797592 0 8192 8 0 0 0 0 0 0 0 0 0 0 0}
  158<--160(pid1182)->io_read_request (-1 8192) = 0 "127.0.0.1\tlocalhost\n127.0.1.1\thurd-2013.my.own.domain\thurd-2013\n\n# The following"
  158<--160(pid1182)->io_read_request (-1 8192) = 0 ""
task130(pid1182)->mach_port_destroy (pn{ 24}) ...159
task130(pid1182)->mach_port_deallocate (pn{ 23}) ...134
159... = 0 
134... = 0 
task130(pid1182)->vm_allocate (0 36864 1) = 0 2506752
task130(pid1182)->mach_port_deallocate (pn{ 11}) = 0 
task130(pid1182)->mach_port_deallocate (pn{ 21}) ...134
task130(pid1182)->mach_port_deallocate (pn{ 11}) ...159
134... = 0 
159... = 0 
task130(pid1182)->vm_allocate (33562796 8364 0) = 0x3 ((os/kern) no space available) 
task130(pid1182)->vm_allocate (33571160 8364 0) = 0 33570816
task130(pid1182)->mach_port_allocate (1) = 0 pn{ 23}
task130(pid1182)->mach_port_insert_right (pn{ 23}  133) = 0 
task130(pid1182)->mach_port_set_qlimit (pn{ 23} 1) = 0 
task130(pid1182)->thread_create () = 0    160<--157(pid1182)
task130(pid1182)->vm_protect (33570816 1 0 0) = 0 
  146<--150(pid-1)-> 2400 ( thread151(pid1182)  task130(pid1182) 1 2 33557926) ...159
  139<--144(pid1182)->proc_dostop_request ( thread138(pid1182)) = 0 
  93<--142(pid1182)->dir_lookup ("servers/crash" 0 0) = 0 1 ""    163<--161(pid1182)
task130(pid1182)->mach_port_mod_refs (pn{  6} 0 1) = 0 
  109<--141(pid1182)->dir_mkfile (18 384) = 0    165<--164(pid1182)
  163<--161(pid1182)->crash_dump_task ( task130(pid1182)    165<--164(pid1182) 11 2 2 1 2 33557926    118<--145(pid1182)) ...134
 159->   71 ();
134... = 0 
Child 1182 Segmentation fault

Svante Signell, le Fri 02 May 2014 10:03:23 +0200, a écrit :
> On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote:
> > Hello,
> > 
> > Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
> > > - Without split stack enabled around 70 libgo tests pass and 50 fails,
> > > most of them with a segfault.
> > > - Enabling split stack and using the libc Samuel built all 122 libgo
> > > tests fail with a segfault.
> > 
> > Please provide segfault backtrace, rpctrace, etc.  Otherwise we won't be
> > able to help you.
> 
> You already have one in this thread, analysed by Justus:
> http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01736.html

Yes, but that stack was without split stack fixed. The backtrace you
have just attached seems different.

Samuel

Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit :
> Thread 4 (Thread 1205.4):
> #0  0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
>         err = <optimized out>
>         err = <optimized out>
>         user_option = 3
>         user_timeout = 48
>         m = 0x532370
>         msgh_bits = 0
>         remote_port = 268509186
>         msgid = 21118
>         save_data = <optimized out>
>         __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"

Ok, reading this again, this looks like what Justus analyzed.

Samuel

Justus Winter, le Sat 26 Apr 2014 08:53:08 +0200, a écrit :
> task130(pid1182)->vm_map (0 49880 0 1    133<--160(pid1182) 0 1 5 7 1) = 0 2453504
> 
> We map that somewhere.
> 
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0 
> 
> Deallocate the port.  Again, for some strange reason 133 == pn{ 25}.
> 
>   158<--157(pid1182)->io_map_request () = 0    133<--162(pid1182)  (null)
> 
> Some more io_map.
> 
> task130(pid1182)->vm_map (2498560 8192 0 0    133<--162(pid1182) 40960 1 3 7 1) = 0x3 ((os/kern) no space available) 
> task130(pid1182)->vm_deallocate (2498560 8192) = 0 
> 
> Hum?
> 
> task130(pid1182)->vm_map (2498560 8192 0 0    133<--162(pid1182) 40960 1 3 7 1) = 0 2498560
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0 
> 
> Success!

See the logic in elf/dl-load.c's _dl_map_object_from_fd and
sysdeps/mach/hurd/mmap.c. _dl_map_object_from_fd first gets somewhere
to map the SO (first __mmap call), and then, if bss is big, it maps
anonymous pages for it with MAP_FIXED, replacing the bss part of the SO:

2453504 + 49880 = 0x2632d8
2498560 + 8192 = 0x264000

So this seems like just normal behavior.

Samuel

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

Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> So we just need to fix guardsize in our libpthread.

(And I'll have a look at it).

Samuel

Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> So we just need to fix guardsize in our libpthread.

It was not so difficult actually.

Svante, could you try this libpthread:

http://people.debian.org/~sthibault/tmp/libpthread.so.0.3

Thanks,
Samuel

On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
> Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> > So we just need to fix guardsize in our libpthread.
> 
> (And I'll have a look at it).

Maybe this can fix the around 40 segfaults (of 50 failures) when split
stack is disabled too? The segfaults are always around the same place in
libpthread.

Svante Signell, le Fri 02 May 2014 12:45:56 +0200, a écrit :
> On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
> > Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> > > So we just need to fix guardsize in our libpthread.
> > 
> > (And I'll have a look at it).
> 
> Maybe this can fix the around 40 segfaults (of 50 failures) when split
> stack is disabled too? The segfaults are always around the same place in
> libpthread. 

Possibly, if libgo uses small stacks already.

Samuel

On Fri, 2014-05-02 at 12:52 +0200, Samuel Thibault wrote:
> Svante Signell, le Fri 02 May 2014 12:45:56 +0200, a écrit :
> > On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
> > > Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> > > > So we just need to fix guardsize in our libpthread.
> > > 
> > > (And I'll have a look at it).
> > 
> > Maybe this can fix the around 40 segfaults (of 50 failures) when split
> > stack is disabled too? The segfaults are always around the same place in
> > libpthread. 
> 
> Possibly, if libgo uses small stacks already.

Status update:
For some (yet) unknown reason all libgo tests fails with a segfault when
run in the build tree: make, sh or something else, the test commands are
rather hard to track.
However, running the tests manually, sigh!, after installing gccgo and
libgo5 from gcc-4.9-4.9.0-1 with split stack support the result is as
follows:

Total: 122
PASS: 95
FAIL: 27
Number of tests succeeding with libpthread's stack guard fixed: 33 (and
the other libc fixes)
Note: In many of the failing tests, only a small subset of each test
fails.

GNU/Hurd should now to be considered for upstream inclusion?
Updated patches will be sent again to gcc-patches for review.

Just to explicitly ask for it:

Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
> For some (yet) unknown reason all libgo tests fails with a segfault when
> run in the build tree: make, sh or something else, the test commands are
> rather hard to track.

Doesn't that dump a core?  Do you have /servers/crash properly pointing
to /servers/crash-dump-core and ulimit -u set to unlimited?

> However, running the tests manually, sigh!, after installing gccgo and
> libgo5 from gcc-4.9-4.9.0-1 with split stack support the result is as
> follows:
> 
> Total: 122
> PASS: 95
> FAIL: 27

Good! :)

> Number of tests succeeding with libpthread's stack guard fixed: 33 (and
> the other libc fixes)

I'm not sure to understand: does it mean only 33 pass instead of 95?

> Note: In many of the failing tests, only a small subset of each test
> fails.

Ok, that's a good sign.

Samuel

On Tue, May 6, 2014 at 4:06 AM, Svante Signell <svante.signell@gmail.com> wrote:
> On Fri, 2014-05-02 at 12:52 +0200, Samuel Thibault wrote:
>> Svante Signell, le Fri 02 May 2014 12:45:56 +0200, a écrit :
>> > On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
>> > > Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
>> > > > So we just need to fix guardsize in our libpthread.
>> > >
>> > > (And I'll have a look at it).
>> >
>> > Maybe this can fix the around 40 segfaults (of 50 failures) when split
>> > stack is disabled too? The segfaults are always around the same place in
>> > libpthread.
>>
>> Possibly, if libgo uses small stacks already.
>
> Status update:
> For some (yet) unknown reason all libgo tests fails with a segfault when
> run in the build tree: make, sh or something else, the test commands are
> rather hard to track.

You can see the commands being run by running something like
    make GOTESTFLAGS=--trace check-target-libgo

Ian

On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
> Just to explicitly ask for it:
> 
> Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
> > For some (yet) unknown reason all libgo tests fails with a segfault when
> > run in the build tree: make, sh or something else, the test commands are
> > rather hard to track.
> 
> Doesn't that dump a core?  Do you have /servers/crash properly pointing
> to /servers/crash-dump-core and ulimit -u set to unlimited?

fsysopts /servers/crash
ext2fs --writable --no-inherit-dir-group --store-type=typed device:hd0s1
ulimit -u
unlimited

> > Number of tests succeeding with libpthread's stack guard fixed: 33 (and
> > the other libc fixes)

Additionally 33 test pass with the fixed libpthread (some of them pass
but segfault before finishing). Still manual testing, no successful
tests with make -C ... check.

Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit :
> On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
> > Just to explicitly ask for it:
> > 
> > Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
> > > For some (yet) unknown reason all libgo tests fails with a segfault when
> > > run in the build tree: make, sh or something else, the test commands are
> > > rather hard to track.
> > 
> > Doesn't that dump a core?  Do you have /servers/crash properly pointing
> > to /servers/crash-dump-core and ulimit -u set to unlimited?
> 
> fsysopts /servers/crash
> ext2fs --writable --no-inherit-dir-group --store-type=typed device:hd0s1

See the type of file, it's a symlink, so just ls -l it.

> > > Number of tests succeeding with libpthread's stack guard fixed: 33 (and
> > > the other libc fixes)
> 
> Additionally 33 test pass with the fixed libpthread (some of them pass
> but segfault before finishing).

Ok, that parenthesis brings the sense to it :)

Samuel

On Tue, 2014-05-06 at 15:07 +0200, Samuel Thibault wrote:
> Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit :
> > On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
> > > Just to explicitly ask for it:
> > > 
> > > Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
> > > > For some (yet) unknown reason all libgo tests fails with a segfault when
> > > > run in the build tree: make, sh or something else, the test commands are
> > > > rather hard to track.
> > > 
> > > Doesn't that dump a core?  Do you have /servers/crash properly pointing
> > > to /servers/crash-dump-core and ulimit -u set to unlimited?
> > 
> > fsysopts /servers/crash
> > ext2fs --writable --no-inherit-dir-group --store-type=typed device:hd0s1
> 
> See the type of file, it's a symlink, so just ls -l it.

ls -l /servers/crash
lrw-r--r-- 1 root root 10 May 17  2013 /servers/crash -> crash-kill

Should I just ln -sf to change?

Svante Signell, le Tue 06 May 2014 15:25:38 +0200, a écrit :
> On Tue, 2014-05-06 at 15:07 +0200, Samuel Thibault wrote:
> > Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit :
> > > On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
> > > > Just to explicitly ask for it:
> > > > 
> > > > Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
> > > > > For some (yet) unknown reason all libgo tests fails with a segfault when
> > > > > run in the build tree: make, sh or something else, the test commands are
> > > > > rather hard to track.
> > > > 
> > > > Doesn't that dump a core?  Do you have /servers/crash properly pointing
> > > > to /servers/crash-dump-core and ulimit -u set to unlimited?
> > > 
> > > fsysopts /servers/crash
> > > ext2fs --writable --no-inherit-dir-group --store-type=typed device:hd0s1
> > 
> > See the type of file, it's a symlink, so just ls -l it.
> 
> ls -l /servers/crash
> lrw-r--r-- 1 root root 10 May 17  2013 /servers/crash -> crash-kill
> 
> Should I just ln -sf to change?

Yes.