On 21.04.12 19:38, Jean-Yves Migeon wrote: > Le 21/04/12 16:31, Jean-Yves Migeon a écrit : >>> Okay, thanks for the report. So this rules out Virtual Box, it seems to >>> happen on native amd64 too. >>> >>> I am taking a look right now. >> >> This seems to be a bug in the trap handling code. The signal is caught >> correctly (it reaches T_ALIGNFLT|T_USER in trap()), but things blow up >> just after: we end signalling the process with a SIGILL (which does not >> come from trap()). >> >> Using 32 bits compat mode (cc -m 32) also causes the crash. So something >> in e_trapsignal() or userret() goes wrong. Still digging. > > Interesting. The "uncatchable" SIGILL comes from sendsig_siginfo [1] and > is used in a way that the signal will force-exit the program (when the > copyout fails). It's a "feature" I was not aware of. > > Anyway, upon entering trap() for this exception (trap11), it looks like > the trapframe is a mess: > > pid 470 (malign): BUS/SEGV (107) at rip 0 addr 7f7ff7701020 > rip 0x0 rsp 0x50202 rfl 0x1f > rdi 0x7f7ff7701080 rsi 0x8 rdx 0xf7701078 > rcx 0x0 r8 0x7 r9 0x7f7ff770178 > [...] > > rip 0x0 and rsp 0x50202 look really abnormal to me. I'll have a look in > FreeBSD, that's probably a group of exceptions that have to be handled > differently.
rip 0x0 often means that a function pointer has been called which is NULL. Christoph
