strace hangs on sigaltstack system call with invalid arguments (hacky patch attached)

[kawillia at ucalgary.ca]

Hello:

I've been using strace for a while now, and just found what I would
consider to be a bug in strace. Essentially, if a traced program executes
a particular system call (SYS_sigaltstack) with `invalid' arguments (which
cause the kernel implementation to simply fail immediately), strace hangs
and does not send a ptrace(PTRACE_SYSCALL) to the child.

Attached is a simple program that reproduces this behaviour for me,
compiled and executed on both 32- and 64- bit x86 Linux using strace 4.7;
the behaviour exists on both my precompiled version from the Arch
repositories as well as one compiled from source.

The issue seems to be that umoven does not differentiate between a
PTRACE_PEEKDATA call that fails with errno ESRCH (i.e. invalid process)
and one with EIO/EFAULT (i.e. invalid memory address), instead treating
both as if the process died. This gets caught in the trace() function.
This causes sys_sigaltstack to believe that the process magically died,
and treats it as such, presumably waiting for a waitpid() to finish (I
didn't check that detail, sorry.)

I've attached a patch that `fixes' this. In particular, it makes umoven()
return -2 in circumstances where the parameters caused an invalid memory
read instead of -1, and makes sys_sigaltstack check for such a condition.
This is obviously a bad idea, but it's a proof-of-concept patch I suppose.
With this patch, strace doesn't hang on the sample any more. I'm not
suggesting this patch for inclusion into the main strace source tree --
I'd say it's too hacky.

There's obviously a philosophical issue at stake here as well -- should
stace behave nicely on programs that don't behave nicely? It seems as if
converting everything to conform to this sort of duality of error types
from umoven() would be difficult to me (I'm a newcomer to strace,
obviously!).

Thoughts, comments, feedback, etc. would be appreciated.

Kent
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 1972 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20130208/c0cb2892/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hang.c
Type: text/x-csrc
Size: 151 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20130208/c0cb2892/attachment.bin>