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

[Justus Winter]

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