Bug 1119301 - satyr cannot parse gdb backtraces containing function names having "." prefix
Summary: satyr cannot parse gdb backtraces containing function names having "." prefix
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: satyr
Version: 20
Hardware: ppc64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Martin Milata
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1119072
Blocks: 1142338
TreeView+ depends on / blocked
 
Reported: 2014-07-14 13:14 UTC by Jakub Filak
Modified: 2016-12-01 00:47 UTC (History)
9 users (show)

Fixed In Version:
Clone Of: 1119072
: 1142338 (view as bug list)
Environment:
Last Closed: 2015-06-30 01:19:48 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Progressed on caja (22.87 KB, text/plain)
2014-07-22 21:57 UTC, Al Dunsmuir
no flags Details

Description Jakub Filak 2014-07-14 13:14:57 UTC
+++ 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!

Comment 1 Jakub Filak 2014-07-15 14:32:41 UTC
Upstream commit https://github.com/abrt/satyr/commit/501f0155f9140ee5dda52857fcfadfaba18bdf4a fixes this bug.

Comment 2 Al Dunsmuir 2014-07-20 23:09:34 UTC
Is that fix in rawhide/F21?

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

Comment 3 Martin Milata 2014-07-22 10:29:19 UTC
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!

Comment 4 Al Dunsmuir 2014-07-22 21:57:45 UTC
Created attachment 920064 [details]
Progressed on caja

Comment 5 Al Dunsmuir 2014-07-22 21:59:07 UTC
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.

Comment 6 Al Dunsmuir 2014-07-22 22:00:41 UTC
In summary, it looks like 1 still fails (with new symptom) and 1 completed.

Comment 7 Al Dunsmuir 2014-07-22 22:03:56 UTC
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 8 Fedora End Of Life 2015-05-29 12:21:59 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 9 Fedora End Of Life 2015-06-30 01:19:48 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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