Re: Kernel bug in handling signals (bug 15615281)
Re: Kernel bug in handling signals (bug 15615281)
- Subject: Re: Kernel bug in handling signals (bug 15615281)
- From: "Ben L. Titzer" <email@hidden>
- Date: Thu, 19 Dec 2013 19:27:31 +0100
Well I supposed you passed the of first test of trust :)
Although you might not like the source code--none of it is written in C :)
Checkout the repository here:
https://code.google.com/p/virgil/
The binary in question is generated by my compiler from the test program in test/execute/rtex_divzero06.v3
% bin/v3c -target=x86-darwin-test -output=/tmp/ test/execute/rtex_divzero06.v3
There is some assembly language linkage that is generated by the compiler itself that sets up the default signal handlers. That assembly is generated in
https://code.google.com/p/virgil/source/browse/aeneas/src/x86/X86Darwin.v3
in genSignalHandlerInstall()
That code is basically:
// generate code that installs a signal handler
|
def genSigHandlerInstall(asm: X86Assembler, signo: int, handler: Addr) {
|
asm.push_i(0); // sa_flags
|
asm.push_i(0); // sa_mask
|
asm.push_i(X86Addrs.ABS_CONST); // sa_handler: handler address
|
recordPatch(asm, handler);
|
asm.push_i(2); // TODO: why a nonzero value here?
|
asm.movd_rm_r(X86Regs.EBX, X86Regs.ESP);
|
asm.push_i(0); // sigaction *oact
|
asm.push(X86Regs.EBX); // sigaction *act
|
asm.push_i(signo); // signal number
|
asm.push_i(0); // "dummy" value
|
asm.movd_rm_i(X86Regs.EAX, 46); // sigaction
|
asm.intK(0x80);
|
asm.add.rm_i(X86Regs.ESP, 32); // pop params off stack
|
}
As you can see there is some hackery going on there. I wasn't exactly sure what I should be passing to the kernel, since it has been a pain to trace through exactly how all the structs are encoded. This all works fine on 10.6. I use the signal handlers to catch access violations (e.g. a null pointer deref by the program generates a SIGSEGV, by design of my address layout), and then generate a stacktrace.
Perhaps I am misusing the syscall. But still, I should *not* be able to crash the kernel, and the behavior certainly shouldn't depend on the 64-bitness of the forking shell (!). As noted above, when forked from a 32-bit shell, then it all works as expected.
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden