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