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

[Dmitry V. Levin]

Hi,

On Fri, Feb 08, 2013 at 06:07:59PM -0700, kawillia at ucalgary.ca wrote:
> 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.

Thanks for reporting, it was print_stack_t() mishandling umove() return
code, I've pushed the following commit to fix it:
http://strace.git.sourceforge.net/git/gitweb.cgi?p=strace/strace;a=commitdiff;h=v4.7-58-g338c069

> 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!).

strace is expected to decode syscalls properly, in particular, it
shouldn't complain when syscall arguments are complete nonsense.
If you are aware of other cases when strace doesn't follow this rule,
please let us know.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20130209/b820062f/attachment.bin>