POSIX: catch more crash-indicating signals for in-process crash dumping.

POSIX: catch more crash-indicating signals for in-process crash dumping.

TEST=none
BUG=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=46043

[Mark Mentovai, 2010-04-29 17:10:42]

LGTM

http://codereview.chromium.org/1801007/diff/1/2
File base/process_util_posix.cc (right):

http://codereview.chromium.org/1801007/diff/1/2#newcode105
base/process_util_posix.cc:105: void StackDumpSignalHandler(int signal) {
This bad boy should probably print the value of “signal” so that we know what
signal was received.

[agl, 2010-04-29 17:18:18]

LGTM modulo Mark's comment.

http://codereview.chromium.org/1801007/diff/1/2
File base/process_util_posix.cc (right):

http://codereview.chromium.org/1801007/diff/1/2#newcode632
base/process_util_posix.cc:632: success &= (signal(SIGSYS,
&StackDumpSignalHandler) != SIG_ERR);
I don't think I've ever seen SIGSYS. It's probably useless to include it here
unless it's a Mac thing.

[Paweł Hajdan Jr., 2010-04-29 17:33:51]

Updated. Could you take another look?

[agl, 2010-04-29 17:39:19]

LGTM

[Mark Mentovai, 2010-04-29 18:04:50]

LG regardless

http://codereview.chromium.org/1801007/diff/6001/7001
File base/process_util_posix.cc (right):

http://codereview.chromium.org/1801007/diff/6001/7001#newcode633
base/process_util_posix.cc:633: 
SIGSYS is “bad argument to system call.” The Mac kernel raises it when an
unrecognized system call is chosen. I don’t have time to check the Linux kernel
right now, but I bet that’s the only case it occurs on Linux also. Since system
calls are normally made through libc wrappers, and libc is normally tied pretty
well to the kernel in this area, it’s highly unlikely that this signal would be
raised.

However, the default disposition for SIGSYS is “core dump,” and if we want to
catch all of the signals that normally induce a dump, it ought to be included in
this list.

“man 3 signal” on the Mac lists SIGQUIT, SIGTRAP, SIGEMT, and SIGSYS as other
signals that by default dump core, in addition to those listed here. I don’t
really mind if you don’t include them, but you might consider adding them to the
mix.

As the list grows, you might also consider looping over an array int
stack_dump_signals[] = {SIGILL, SIGABRT, ...} instead of writing the same line
potentially nine times.

[agl, 2010-04-29 18:23:56]

http://codereview.chromium.org/1801007/diff/6001/7001
File base/process_util_posix.cc (right):

http://codereview.chromium.org/1801007/diff/6001/7001#newcode633
base/process_util_posix.cc:633: 
On 2010/04/29 18:04:50, Mark Mentovai wrote:
> SIGSYS is “bad argument to system call.” The Mac kernel raises it when an
> unrecognized system call is chosen. I don’t have time to check the Linux
kernel
> right now, but I bet that’s the only case it occurs on Linux also.

Linux returns ENOSYS.

If it's a Macism (or rather a SysVism) then put it in if you like. Either way,
LGTM.

[Mark Mentovai, 2010-04-29 18:26:06]

agl wrote:
> http://codereview.chromium.org/1801007/diff/6001/7001
> File base/process_util_posix.cc (right):
>
> http://codereview.chromium.org/1801007/diff/6001/7001#newcode633
> base/process_util_posix.cc:633:
> On 2010/04/29 18:04:50, Mark Mentovai wrote:
>>
>> SIGSYS is “bad argument to system call.” The Mac kernel raises it when
>
> an
>>
>> unrecognized system call is chosen. I don’t have time to check the
>
> Linux kernel
>>
>> right now, but I bet that’s the only case it occurs on Linux also.
>
> Linux returns ENOSYS.

Sets errno? Even if you try to enter a system call directly via int
0x80/syscall/sysenter? How’s that possible?

Mark

[Mark Mentovai, 2010-04-29 18:32:30]

Oh, maybe you meant -ENOSYS? That could work.

Mark

I wrote:
> agl wrote:
>> http://codereview.chromium.org/1801007/diff/6001/7001
>> File base/process_util_posix.cc (right):
>>
>> http://codereview.chromium.org/1801007/diff/6001/7001#newcode633
>> base/process_util_posix.cc:633:
>> On 2010/04/29 18:04:50, Mark Mentovai wrote:
>>>
>>> SIGSYS is “bad argument to system call.” The Mac kernel raises it when
>>
>> an
>>>
>>> unrecognized system call is chosen. I don’t have time to check the
>>
>> Linux kernel
>>>
>>> right now, but I bet that’s the only case it occurs on Linux also.
>>
>> Linux returns ENOSYS.
>
> Sets errno? Even if you try to enter a system call directly via int
> 0x80/syscall/sysenter? How’s that possible?
>
> Mark
>