Michael Hudson-Doyle <michael.hud...@linaro.org> writes: > Hi all, > > Apologies if this is the wrong list, and for the somewhat vague > description of my problem. > > I've been working on porting Go (via gccgo) to aarch64 and things have > mostly been going well. However, under some circumstances, I'm seeing > crashes. What's happening is that when a signal -- SIGCHLD in this case > -- is being handled, instead of being executed on the stack passed to > sigaltstack, the signal is being handled on some *other* thread's stack, > which unsurprisingly ends badly when a signal context object is smashed > over whatever the original thread had put there.
[...] > There are some more details on this bug: > https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1279620 but I > don't have anything like a minimal example unfortunately. I'll try to > come up with one tomorrow, but in the mean time: does this ring any > bells at all with anyone? I couldn't see any obvious reasons for this > behaviour in the kernel code :/ It's not minimal, but I have a way that someone other than me can (hopefully) reproduce the bug. 1) Get yourself an Ubuntu Trusty image running on aarch64 2) Install libgo4-dbg and gdb and their dependencies 3) Turn off transparent huge pages: * echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled 4) Download these files and chuck them in the same directory: * http://people.linaro.org/~mwhudson/sas-test * http://people.linaro.org/~mwhudson/pkgs.json 5) Chuck this in .gdbinit: set height 0 define hook-quit set confirm off end set breakpoint pending on br __go_panic set breakpoint pending on br runtime_signalstack commands printf "XXX sigaltstack requesting stack: 0x%lx - 0x%lx\n", p, p+n c end br sig_tramp_info commands printf "XXX signal: $sp: 0x%010lx", $sp c end 6) Run "gdb --args ./sas-test install | tee gdb.out" and type run 7) grep for XXX in gdb.out and see if the stacks that the signals are being handled on lines up with what is being passed to sigaltstack. When I do this I see: XXX sigaltstack requesting stack: 0x8506000 - 0x850e000 XXX sigaltstack requesting stack: 0x8b2c000 - 0x8b34000 XXX sigaltstack requesting stack: 0x9180000 - 0x9188000 XXX sigaltstack requesting stack: 0x9192000 - 0x919a000 XXX sigaltstack requesting stack: 0x919f000 - 0x91a7000 XXX signal: $sp: 0x0009604240[Switching to Thread 0x7fa6c36270 (LWP 1034)] XXX signal: $sp: 0x0009804710 XXX signal: $sp: 0x0009a040a0[Switching to Thread 0x7fb7ff3000 (LWP 1028)] XXX signal: $sp: 0x00098042b0[Switching to Thread 0x7fa6c36270 (LWP 1034)] XXX signal: $sp: 0x0009a04780 XXX signal: $sp: 0x0009604780 XXX signal: $sp: 0x0009c09710 XXX signal: $sp: 0x0009a04710 XXX signal: $sp: 0x0009604710 XXX signal: $sp: 0x0009c09780 XXX signal: $sp: 0x0009804710 XXX signal: $sp: 0x0009a04780 XXX signal: $sp: 0x0009604780 XXX signal: $sp: 0x0009c09710 XXX signal: $sp: 0x0009804780 ... Those signal $sp's don't appear to bear any relation to the addresses passed to sigaltstack... Cheers, mwh _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
