Bug 105371

Created attachment 94716 [details]
proposed patch

One problem with this interface is that strace getting an error itself
will still pollute the return value of the program.

Is there any better approach? 

Created attachment 96530 [details]
proposed patch

rediffed for strace-4.5.1, without coredump trace feature.

Created attachment 115496 [details]
strace-4.5.12-alt-keep_status.patch

Rediffed for new strace version.

I'd like to support Dmitry's proposal. I run strace to know what files an 
application accesses that I only have as a binary. It works great! 
Unfortunately it does not give me an indication of the program's return value. 
So I have to parse strace's output for that which is error prone. 
 
Roland, its okay if we return failure if either program or strace fail. As the 
caller I can still output a reasonable error message. 
 
 

*** Bug 163613 has been marked as a duplicate of this bug. ***

Created attachment 117548 [details]
strace-4.5.13-alt-keep_status.patch

Rediffed for strace-4.5.13.

Created attachment 123341 [details]
strace-4.5.14-alt-keep_status.patch

Rediffed for strace-4.5.14

Please post on the ml, I think this can go in now.
No reason to conditionalize setting "return_code".

I think I'd like to see all other existing exit calls changed to
exit(failure_code) and then under -k we might set failure_code to 128 or
something.  That way strace having an error is easier to distinguish from the
likely exit codes of a traced process (such as 1 or 2).

Dedicated exit code 128 in "-k" mode is OK for me.

(In reply to comment #10)
> Please post on the ml, I think this can go in now.
> No reason to conditionalize setting "return_code".
> 
> I think I'd like to see all other existing exit calls changed to
> exit(failure_code) and then under -k we might set failure_code to 128 or
> something.  That way strace having an error is easier to distinguish from the
> likely exit codes of a traced process (such as 1 or 2).

Hi Roland,

Should the status of this bug be changed as result of the ML discussion or any
subsequent work?

Thanks,
John

Not to be meant as a criticism, but just a thought: passing back the exit code is a good idea, but sometimes it is not enough. For example, when parent process is normally sending signals to child, it breaks when you run child under strace.

Imagine that parent listens on a socekt and starts children for new connections:

$ parent 1.2.3.4:56 -e child arg1 arg1

If you run it like

$ parent 1.2.3.4:56 -e strace child arg1 arg1

, attempts to send signals between parent and child would not work as intended.

The nice thing to have would be an option for strace to fork, and exec traced child in *parent*, not child. Then child attaches to parent similarly to strace -p PID.

But of course this goes far beyond this bug.

Created attachment 317603 [details]
Patch: exit/kill ourself with straced child's exitcode/signal

Apparently discussion on mailing list died out with no results.

I propose this patch. It just makes strace exit with child's exitcode.
Rationale:

I think in real-world usage people do not check strace usage in scripts. They just use it correctly, so that it doesn't exit(1) with usage info and whatnot.

But know for a fact that when I try to debug something by replacing "cmd [args]" with "strace cmd [args]" the fact that parent does not see exit code of cmd but seels zero, always, sometimes is a problem.

IOW: I do not think that there are users who will be adversely affected by this change in behavior. Therefore I do not think adding a switch to enable this is worth it. It will be just a case of featuritis.

Problems this patch fixes compared to previous patches:

* strace returns exit code of straced process, *never its children*.
* If child died from a signal, strace will (try to) die from the same signal.
* strace -p <pid> is not affected (will exit 0 as before).

(In reply to comment #14)
> Created an attachment (id=317603) [details]
> Patch: exit/kill ourself with straced child's exitcode/signal

I think your idea how to implement this RFE is better than mine.
I tested it and have no compatibility problems so far.
I'm OK to install your patch with minor cleanup.

Created attachment 318019 [details]
strace-4.5.18-exit.patch

Proposed patch (patch by Denys Vlasenko with minor cleanup).

in comment #10 Roland said "changed to exit(failure_code)", so what about using the EXIT_FAILURE as per stdlib.h as opposed to hardcoding it? Minor nit..

strace-4.5.19-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/strace-4.5.19-1.fc10

strace-4.5.19-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/strace-4.5.19-1.fc11

strace-4.5.19-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update strace'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-10733

strace-4.5.19-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update strace'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10843

strace-4.5.19-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

strace-4.5.19-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.