RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1142338 - satyr cannot parse gdb backtraces containing function names having "." prefix
Summary: satyr cannot parse gdb backtraces containing function names having "." prefix
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: satyr
Version: 7.1
Hardware: ppc64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Martin Milata
QA Contact: Lukáš Zachar
URL:
Whiteboard:
Depends On: 1119072 1119301
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-16 15:25 UTC by Jakub Filak
Modified: 2019-03-06 00:55 UTC (History)
9 users (show)

Fixed In Version: satyr-0.13-5.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1119301
Environment:
Last Closed: 2015-03-05 13:27:33 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0556 0 normal SHIPPED_LIVE abrt, libreport, and satyr bug fix and enhancement update 2015-03-05 16:44:43 UTC

Description Jakub Filak 2014-09-16 15:25:40 UTC 
+++ This bug was initially created as a clone of Bug #1119301 +++

+++ This bug was initially created as a clone of Bug #1119072 +++

Description of problem:
When abrt is triggered on F20 on ppc64, it consistently does not recognize the backtrace.

I am experiencing errors in mate-control-center and kernel (Oops due to ATI X11 driver). 

Version-Release number of selected component (if applicable):
abrt.2.2.1-2.fc20.ppc64

How reproducible:
100% whenever I have exception so far.  kernel Oops happens every boot, and mate-control-center happens when I change display resolution (to fix up after kernel video error 8^( ) 


Steps to Reproduce:
1.
2.
3.

Actual results:
Backtrace processing failed

Expected results:
Backtrace showing failing component, and point of failure


Additional info:

--- Additional comment from Al Dunsmuir on 2014-07-13 20:46:38 CEST ---

--- Running report_uReport ---
Generating core_backtrace
Generating backtrace
Error: Line 12, column 0: Frame header variant not recognized.
('report_uReport' exited with 1)

--- Running report_EmergencyAnalysis ---
Compressing data
Sending /var/tmp/ccpp-2014-07-09-20:19:09-2610.tar.gz to https://retrace.fedoraproject.org/faf/dumpdirs/new/
Successfully sent /var/tmp/ccpp-2014-07-09-20:19:09-2610.tar.gz to https://retrace.fedoraproject.org/faf/dumpdirs/new/

--- Additional comment from Jakub Filak on 2014-07-14 11:04:21 CEST ---

Hello, thank you for the report. Could you please provide the ignored oops text?

--- Additional comment from Jakub Filak on 2014-07-14 11:49:07 CEST ---

Could you also please provide a backtrace generated by your gdb?

$ cd /var/tmp/ccpp-2014-07-09-20:19:09-2610
$ gdb $(cat executable) -c coredump -batch -ex "t a a bt"

--- Additional comment from Al Dunsmuir on 2014-07-14 12:37:34 CEST ---

BUG: soft lockup - CPU #1 stuck for 23s! [gmain:2435] - abrt
--- Running report_uReport ---
Server responded with an error: 'Validation failed: Element 'frames' is invalid: List element is invalid: Element 'function_name' is missing'
reporter-ureport failed with exit code 1
('report_uReport' exited with 1)

--- Running report_EmergencyAnalysis ---
Compressing data
Sending /var/tmp/oops-2014-07-13-11:43:56-1530-0.tar.gz to https://retrace.fedoraproject.org/faf/dumpdirs/new/
Successfully sent /var/tmp/oops-2014-07-13-11:43:56-1530-0.tar.gz to https://retrace.fedoraproject.org/faf/dumpdirs/new/

--- Additional comment from Al Dunsmuir on 2014-07-14 12:59:28 CEST ---

For the gdb backtrace, files are under abrt directory.

$ cd /var/tmp/abrt/ccpp-2014-07-09-20:19:09-2610
$ gdb $(cat executable) -c coredump -batch -ex "t a a bt"

Output uploaded as 2610.txt

I don't see a /var/tmp/abrt/oops-2014-07-13-11:43:56-1530 directory.
- As the kernel oops trees are root/root, is it possible it is deleted for
  security reasons?

There is another abrt tree for a different kernel oops, but that does not have a coredump file.

--- Additional comment from Al Dunsmuir on 2014-07-14 13:00:25 CEST ---



--- Additional comment from Al Dunsmuir on 2014-07-14 13:09:13 CEST ---

I have a new instance this morning.  it is consistent with the mate-control-center error, so I am including it in case this helps:

caja killed by sigtrap
--- Running report_uReport ---
Generating core_backtrace
Generating backtrace
Error: Line 10, column 4: Frame header variant not recognized.
('report_uReport' exited with 1)

--- Running report_EmergencyAnalysis ---
Compressing data
Sending /var/tmp/ccpp-2014-07-14-06:31:50-2271.tar.gz to https://retrace.fedoraproject.org/faf/dumpdirs/new/
Successfully sent /var/tmp/ccpp-2014-07-14-06:31:50-2271.tar.gz to https://retrace.fedoraproject.org/faf/dumpdirs/new/

Uploaded gdb traceback as 2271.txt

--- Additional comment from Al Dunsmuir on 2014-07-14 13:11:05 CEST ---



--- Additional comment from Jakub Filak on 2014-07-14 14:09:16 CEST ---

(In reply to Al Dunsmuir from comment #5)
> I don't see a /var/tmp/abrt/oops-2014-07-13-11:43:56-1530 directory.
> - As the kernel oops trees are root/root, is it possible it is deleted for
>   security reasons?
> 
No, I don't think so. It is more likely that ABRT deleted that directory because of lack of free space.

Thank you very much for the backtraces!

--- Additional comment from Jakub Filak on 2014-07-15 16:32:41 CEST ---

Upstream commit https://github.com/abrt/satyr/commit/501f0155f9140ee5dda52857fcfadfaba18bdf4a fixes this bug.

--- Additional comment from Al Dunsmuir on 2014-07-21 01:09:34 CEST ---

Is that fix in rawhide/F21?

Can you arrange a F20 ppc64 update build please?  I'll test & give karma.

--- Additional comment from Martin Milata on 2014-07-22 12:29:19 CEST ---

The fix that Jakub references is currently only in git.

However, abrt-2.2.2-1 that is currently in F20 and rawhide should work correctly on ppc64 even without this fix.

Any testing and feedback is appreciated!

--- Additional comment from Al Dunsmuir on 2014-07-22 23:57:45 CEST ---



--- Additional comment from Al Dunsmuir on 2014-07-22 23:59:07 CEST ---

abrt-2.2.2-1.fc20.ppc64 *just* became available for download from ppc64 F20 updates-testing.

It appears to move things along, so the symptom changes but is not entirely successful.
- - -
For mate-display-properties, I now get:
--- Running report_uReport ---
Server responded with an error: 'Validation failed: Element 'stacktrace' is invalid: List element is invalid: Element 'frames' is invalid: List element is invalid: Element 'file_name' is missing'
reporter-ureport failed with exit code 1
('report_uReport' exited with 1)

--- Running report_EmergencyAnalysis ---
Compressing data
Sending /var/tmp/ccpp-2014-07-09-20:19:09-2610.tar.gz to https://retrace.fedoraproject.org/faf/dumpdirs/new/
Successfully sent /var/tmp/ccpp-2014-07-09-20:19:09-2610.tar.gz to https://retrace.fedoraproject.org/faf/dumpdirs/new/

- - -
For the caja (mate- SIGSEGV, I got a popup with the following:
  The release 'fedora-20-ppc64' is not supported by the Retrace server.
Is this expected??

I proceeded with local stack trace - nearly 2GB download in 73 packages.
My connection to my ISP is DSL+fibre, with no download limit.   
<wait while Jeopardy music plays>
Created https://bugzilla.redhat.com/show_bug.cgi?id=1122303

Full log is attached.

--- Additional comment from Al Dunsmuir on 2014-07-23 00:00:41 CEST ---

In summary, it looks like 1 still fails (with new symptom) and 1 completed.

--- Additional comment from Al Dunsmuir on 2014-07-23 00:03:56 CEST ---

Made progress on kernel oops as well.

BUG: soft lockup - CPU #1 stuck for 23s! [gmain:2435]

--- Running report_uReport ---
Server responded with an error: 'Validation failed: Element 'frames' is invalid: List element is invalid: Element 'function_name' is missing'
reporter-ureport failed with exit code 1
('report_uReport' exited with 1)

--- Running report_EmergencyAnalysis ---
Compressing data
Sending /var/tmp/oops-2014-07-13-11:43:56-1530-0.tar.gz to https://retrace.fedoraproject.org/faf/dumpdirs/new/
Successfully sent /var/tmp/oops-2014-07-13-11:43:56-1530-0.tar.gz to https://retrace.fedoraproject.org/faf/dumpdirs/new/
Comment 2 Martin Milata 2014-09-17 14:22:10 UTC 
Fixed upstream: 501f0155f9140ee5dda52857fcfadfaba18bdf4a
Comment 5 Jakub Filak 2014-11-14 12:58:25 UTC 
The upstream patch includes a test case:
https://github.com/abrt/satyr/commit/501f0155f9140ee5dda52857fcfadfaba18bdf4a

ABRT tests satyr's ability to parse those oopses in 'oops-processing' integration test[1] ('oops8_ppc64' file [2], 'oops9_ppc64' file [3]).

1: https://github.com/abrt/abrt/tree/master/tests/runtests/oops-processing
2: https://github.com/abrt/abrt/blob/master/examples/oops8_ppc64.test
3: https://github.com/abrt/abrt/blob/master/examples/oops9_ppc64.test
Comment 9 errata-xmlrpc 2015-03-05 13:27:33 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0556.html
Note You need to log in before you can comment on or make changes to this bug.