Bug 812350

Summary:	RFE: SIGTRAP bugs are probably not caused by the application itself
Product:	[Fedora] Fedora	Reporter:	Petr Machata <pmachata>
Component:	abrt	Assignee:	abrt <abrt-devel-list>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	abrt-devel-list, dfediuck, dhoward, dvlasenk, iprikryl, jfilak, mmilata, mnewsome, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-04-27 07:25:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	756771

Description Petr Machata 2012-04-13 13:25:34 UTC

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 13:59:35 UTC

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 14:07:55 UTC

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 22:07:23 UTC

(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 13:52:37 UTC

Fixed in git:

commit 56b0baa8126471f0fcb3391035985f1c6db798e5
Author: Denys Vlasenko <vda.linux>
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 10:47:03 UTC

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-06 03:47:35 UTC

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-08 02:25:24 UTC

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 13:38:18 UTC

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 08:42:10 UTC

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