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.
Given the stack dump above, I tend to believe that #AC was never really stressed.
[1] http://nxr.netbsd.org/xref/src/sys/arch/amd64/amd64/machdep.c#695 -- jym@