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@
