On Thu, 2017-09-07 at 10:38 +0200, Svante Signell wrote:
>
> 2) test_sighandler.c:
>
> GNU/Linux:
> ./test_sighandler
> Got signal 11, faulty address is 0xdeadbeef, from 5597bd471de0
> Executable name = '/home/srs/Hurd/DEBs/test_cases/test_sighandler�', len = 47
> [bt] Execution path:
> [bt] ./test_sighandler(func_b+0x11) [0x5597bd471de0]
> [bt] ./test_sighandler(func_b+0x11) [0x5597bd471de0]
> [bt] ./test_sighandler(main+0x6a) [0x5597bd471e54]
> [bt] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f1cdc8d12b1]
> [bt] ./test_sighandler(_start+0x2a) [0x5597bd471ada]
>
> GNU/Hurd:
> ./test_sighandler
> Got signal 4
> Executable name = './test_sighandler', len = 21
> [bt] Execution path:
> [bt] ./test_sighandler(func_b+0x10) [0x8048986]
> [bt] ./test_sighandler(main+0x6f) [0x80489ff]
> [bt] /lib/i386-gnu/libc.so.0.3(__libc_start_main+0xaa) [0x10b6eea]
>
> This is another bug in the backtrace. hex2dec('deadbeef')/1024^3 = 3.4794 GiB
> Even if the address is outside the gnumach range, the program should not fail
> with a SIGILL. Or?
Any ideas why the signal is SIGILL instead of SIGSEGV? How to trace the cause of
this bug?
