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!