sys_clone causing troubles

[GoogleCodeExporter]

At mozilla, we've been working on a way to lazily decompress libraries at 
runtime on Linux/Android, and the result is that as code jumps in places that 
are yet undecompressed, we get a segmentation fault and handle everything in a 
segfault handler.

We also use breakpad for our crash reporting system, so obviously, we hook 
breakpad into the loop. In practice, we have a segfault handler that checks 
whether the segfault happens in a portion of library, or elsewhere, and in the 
latter case, we dispatch the segfault to breakpad's handler.

It works quite well, but when breakpad wants to create the minidump, it 
sys_clone()s and does the work from there. Unfortunately, our segfault handler 
doesn't get any signal in the cloned process.

However, it does when replacing sys_clone with fork. So I went ahead and 
replaced sys_clone with a syscall(__NR_clone) call, and got the same behavior 
as sys_clone (i.e. segfaults not caught) with the following code:
syscall(__NR_clone, CLONE_FILES | CLONE_FS | CLONE_UNTRACED, stack);

However, NOT setting a separate stack DOES make segfaults getting caught:
syscall(__NR_clone, CLONE_FILES | CLONE_FS | CLONE_UNTRACED, NULL);

The sys_clone implementation in linux_syscall_support.h doesn't allow the stack 
parameter to be NULL, but the kernel implementation does, and uses the original 
stack in that case.

Now, I know what I'm trying is pretty unorthodox, but I don't see a compelling 
reason to force a separate stack to create the minidump. As a matter of fact, I 
don't see a compelling reason to use sys_clone instead of fork, besides the 
CLONE_UNTRACED flag.

How would you feel about modifying sys_clone in linux_syscall_support.h to 
allow stack to be NULL, and pass it that in linux/handler/exception_handler.cc?

Original issue reported on code.google.com by gland...@gmail.com on 24 Jan 2012 at 1:24

[GoogleCodeExporter]

Original comment by ted.mielczarek on 24 Jan 2012 at 1:27

[GoogleCodeExporter]

Actually, I can find one compelling reason not to use fork: pthread_atfork.

Original comment by gland...@gmail.com on 24 Jan 2012 at 1:38

[GoogleCodeExporter]

It turns out that when setting to run signals on an alternate stack, it works. 
Breakpad does this, but our code resets that.

Original comment by gland...@gmail.com on 24 Jan 2012 at 3:30

[GoogleCodeExporter]

Original comment by ted.mielczarek on 24 Jan 2012 at 3:51

• Changed state: Invalid