Bug 812350 - RFE: SIGTRAP bugs are probably not caused by the application itself
RFE: SIGTRAP bugs are probably not caused by the application itself
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: abrt (Show other bugs)
rawhide
Unspecified Unspecified
medium Severity unspecified
: ---
: ---
Assigned To: abrt
Fedora Extras Quality Assurance
:
Depends On:
Blocks: ABRTF18
  Show dependency treegraph
 
Reported: 2012-04-13 09:25 EDT by Petr Machata
Modified: 2015-05-04 21:36 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-04-27 03:25:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Petr Machata 2012-04-13 09:25:34 EDT
Description of problem:
Bug 735546 was filed against component "evince", because that's the binary of the failed process.  However it died of SIGTRAP, its parent was ltrace, and "ltrace" was even initial part of the command line.  These hints all point towards ltrace as the original cause of that failure.

Debuggers can cause wider variety of bugs.  On my current system, it's trivial to make gedit die of SIGSEGV during the early start-up, because ltrace as shipped on ppc64 badly screws something.

I'm not sure how practical or possible it is to glean the above information in abrt.  If it's possible to figure out who the parent was, then that could be compared against some sort of white list, I presume.  SIGTRAP, I believe, is almost always caused by a debugger meddling (and ltrace in particular, as other debuggers are not as utterly broken).

Version-Release number of selected component (if applicable):
2.0.3 in the report linked above
2.0.7-2.fc16 on my machine
Presumably relevant in latest greatest as well, hence filed against Rawhide

How reproducible:
Consistently.

Steps to Reproduce:
1. ltrace gedit
2. wait for it

Actual results:
3. abrt pops up informing me that gedit failed

Expected results:
3. abrt pops up informing me that ltrace made gedit fail

Additional info:
I'm not sure how practical that all is.  Consider this half RFE and half question of the curious.
Comment 1 Petr Machata 2012-04-13 09:59:35 EDT
Hm, though that SIGSEGV that I mention is captured by ltrace and doesn't trigger abrt.  Yet in abrt-gui I see a highly suspicious SIGSEGVs in echo and obviously a whole bunch of SIGTRAPs.
Comment 2 Petr Machata 2012-04-13 10:07:55 EDT
It just occurred to me that /proc/pid/status contains a TracerPid field.  But I don't know whether you can read that at the time of crash.
Comment 3 Jiri Moskovcak 2012-08-09 18:07:23 EDT
(In reply to comment #2)
> It just occurred to me that /proc/pid/status contains a TracerPid field. 
> But I don't know whether you can read that at the time of crash.

Yes, ABRT has access to it, so  guess we can read it and if it's set then we can do some whitelist magic to find the proper component to blame or to decide to ignore crashes in traced programs.
Comment 4 Denys Vlasenko 2012-09-26 09:52:37 EDT
Fixed in git:

commit 56b0baa8126471f0fcb3391035985f1c6db798e5
Author: Denys Vlasenko <vda.linux@googlemail.com>
Date:   Wed Sep 26 15:51:19 2012 +0200

    ccpp_event.conf: ignore crashes with nonzero TracerPid


 EVENT=post-create analyzer=CCpp
-        # try generating backtrace, if it fails we can still use
+        if grep '^TracerPid:[[:space:]]*[123456789]' proc_pid_status >/dev/null 2>&1; then
+            # We see 'TracerPid: <nonzero>" in /proc/PID/status
+            # Process is ptraced (gdb, strace, ltrace)
+            # Debuggers have wide variety of bugs where they leak SIGTRAP
+            # to traced process and nuke it. Ignore this crash.
+            echo "The crashed process was ptraced - not saving the crash"
+            exit 1  # abrt will remove the problem directory
+        fi
+        # Try generating backtrace, ...
Comment 5 Fedora Update System 2012-10-05 06:47:03 EDT
abrt-2.0.14-1.fc17,libreport-2.0.15-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/abrt-2.0.14-1.fc17,libreport-2.0.15-1.fc17
Comment 6 Fedora Update System 2012-10-05 23:47:35 EDT
Package abrt-2.0.14-1.fc17, libreport-2.0.15-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing abrt-2.0.14-1.fc17 libreport-2.0.15-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-15498/abrt-2.0.14-1.fc17,libreport-2.0.15-1.fc17
then log in and leave karma (feedback).
Comment 7 Fedora Update System 2012-10-07 22:25:24 EDT
Package libreport-2.0.15-1.fc17, abrt-2.0.14-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libreport-2.0.15-1.fc17 abrt-2.0.14-2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-15498/abrt-2.0.14-2.fc17,libreport-2.0.15-1.fc17
then log in and leave karma (feedback).
Comment 8 Fedora Update System 2013-02-05 08:38:18 EST
abrt-2.1.0-1.fc17,libreport-2.1.0-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/abrt-2.1.0-1.fc17,libreport-2.1.0-2.fc17
Comment 9 Fedora Update System 2013-03-20 04:42:10 EDT
abrt-2.1.2-1.fc17,libreport-2.1.2-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/abrt-2.1.2-1.fc17,libreport-2.1.2-1.fc17

Note You need to log in before you can comment on or make changes to this bug.