Message ID | 87ip10o90k.fsf@kepler.schwinge.homeip.net |
---|---|
State | New |
Headers | show |
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.
diff --git gcc/config/i386/gnu.h gcc/config/i386/gnu.h index 35063e6..4a91c84 100644 --- gcc/config/i386/gnu.h +++ gcc/config/i386/gnu.h @@ -36,6 +36,12 @@ along with GCC. If not, see <http://www.gnu.org/licenses/>. #endif #ifdef TARGET_LIBC_PROVIDES_SSP + +/* Not supported yet. */ +# undef TARGET_THREAD_SSP_OFFSET + /* Not supported yet. */ -#undef TARGET_THREAD_SSP_OFFSET +# undef TARGET_CAN_SPLIT_STACK +# undef TARGET_THREAD_SPLIT_STACK_OFFSET + #endif