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

[Svante Signell]

±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
>