Description of problem: abrt detects a problem at KDE login e.g. nepomukservicestub segfault. abrt is opened to report the problem and after accepting the prompt to relocate the cache directory, from a non-writable /var location to user's home directory, abrt fails to send the report with a report_uReport exit 1 error. Version-Release number of selected component (if applicable): abrt-2.0.13-1.fc18.i686 How reproducible: Every time with this version. Earlier versions under fc18 did work. Steps to Reproduce: 1. Open abrt when it reports an application error 2. Select Report and confirm request to relocate cache data to home directory 3. Observe report_uReport exit 1 error Actual results: Reporting fails. Expected results: I would expect the reporting to work, althought I've only ever successfully sent one report with abrt out of many attempts. Additional info:
Thank you for filling this report. Please provide the logs Run the following command and report your crash again: $ abrt-gui -vvv
Created attachment 622314 [details] abrt-gui -vvv output for nepomuk-core breakage This file was generated by abrt-gui -vvv for a reported failure in package nepomuk-core at KDE login.
Hi Neil, the problem is that core_backtrace wasn't be generated from a coredump. In order to sort this problem out I need to see that coredump. In your case the coredump should be stored at this path /home/neil/.cache/abrt/spool/ccpp-2012-10-05-16:43:31-2945/coredump Thanks for the cooperation
Created attachment 624027 [details] abrt spool directory for failed nepomukservicestub segfault report I did not have the coredump requested but the failure repeated today and I have attached an archive of the entire abrt spool directory for analysis.
*** Bug 861630 has been marked as a duplicate of this bug. ***
Hi Neil, the problem directory is corrupted. gdb can't read the coredump because the coredump is truncated and lot of other files have length 0.
Hi Jakub, I don't know what to offer here except that I didn't corrupt the files myself so, unless tar and/or gzip were faulty at the time, abrt or its dependent code must have done it. These errors still occur, shall I submit another spool directory archive next time it presents?
I have a similar nepomuk-core report generated by abrt. After a while waiting for "analyze_CCpp" it also complains: "reporting disabled because backtrace is unusable." I'm not sure what to report or how. I'll attach the unusable backtrace because I don't know what else to do. If it's truly unusable, I fear it may be an exercise in futility. But maybe it will help to pinpoint where abrt itself is failing to generate the backtrace in the first place. Hope springs eternal, after all. Nepomuk typically crashes (for me) in this way upon the first login to KDE after a reboot, and then not again until I reboot again. Abrt consistently refuses to report these crashes because the backtraces are consistently unusable.
Created attachment 631669 [details] Another example of an abrt spool on a nepomuk crash.
May be a red herring, BUT: nepomuk doesn't SEEM to crash on me when I update and reboot my computer remotely, via the ssh command line, from home at night, and then not log in to KDE again until the morning. It SEEMS to crash on me when I'm sitting at the console, waiting for the login prompt to appear immediately after a reboot. I say "seems" because my powers of observation first thing in the morning aren't all that finely-honed. But maybe--maybe--it's a true statement...
(In reply to comment #7) > Hi Jakub, > > I don't know what to offer here except that I didn't corrupt the files > myself so, unless tar and/or gzip were faulty at the time, abrt or its > dependent code must have done it. > > These errors still occur, shall I submit another spool directory archive > next time it presents? Another dump directory will be good evidence of fact that abrt creates corrupted dump directories. And please, run the following command on next occurrence and post the output. $ grep -i abrt /var/log/messages
(In reply to comment #9) > Created attachment 631669 [details] > Another example of an abrt spool on a nepomuk crash. Thank you Alan! Your coredump is truncated as well. I've noticed that nepomuk crashes in multiple instances at same time. Thus I guess this bug is dup of bug 759213. As I wrote in comment 11, output of `$ grep -i abrt /var/log/messages` would really help me.
Created attachment 632693 [details] abrt spool directory dump for 2012-10-24 This is today's nepomuk failure. abrt complained with: Cleaning up virtual root Retrace job finished successfully Backtrace parsing failed for . 23:4: Frame header variant not recognized. --- Running collect_Smolt --- Smolt profile successfully saved The relevant /var/log/messages are: Oct 24 12:10:34 aspire abrtd: Directory 'ccpp-2012-10-24-12:10:26-1397' creation detected Oct 24 12:10:34 aspire abrt[2322]: Saved core dump of pid 1397 (/usr/bin/nepomukservicestub) to /var/spool/abrt/ccpp-2012-10-24-12:10:26-1397 (7528448 bytes) Oct 24 12:10:34 aspire abrtd: Lock file '/var/spool/abrt/ccpp-2012-10-16-09:23:40-1892/.lock' is locked by process 2322 Oct 24 12:10:36 aspire abrtd: Generating backtrace Oct 24 12:10:42 aspire abrtd: New problem directory /var/spool/abrt/ccpp-2012-10-24-12:10:26-1397, processing Oct 24 12:13:41 aspire abrtd: New client connected
The result of grep -i abrt /var/log/messages for me is similar to Neil's: Oct 22 11:03:02 aschmidt abrtd: Directory 'ccpp-2012-10-22-11:02:59-16805' creation detected Oct 22 11:03:02 aschmidt abrt[23309]: Saved core dump of pid 16805 (/usr/bin/nepomukservicestub) to /var/spool/abrt/ccpp-2012-10-22-11:02:59-16805 (184320 bytes) Oct 22 11:03:02 aschmidt abrtd: Lock file '/var/spool/abrt/ccpp-2012-10-18-11:18:36-20591/.lock' is locked by process 23309 Oct 22 11:03:04 aschmidt abrtd: Generating backtrace Oct 22 11:03:11 aschmidt abrtd: New problem directory /var/spool/abrt/ccpp-2012-10-22-11:02:59-16805, processing Oct 22 11:07:32 aschmidt abrtd: New client connected
I have a similar problem. trying to report a bug in system-config-services causes abrt to fail. I deleted the contents of /var/spool/abrtd, ~.config/abrt and ~.cache/abrt, reproduced the problem in system-config-services and ran abrt-gui with the -v switch. --- Running report_uReport --- Locked './.lock' Unlocked './.lock' warning: 'uptime' is not an item in problem directory server side error: "Validation failed: error validating 'core_backtrace': missing mandatory element 'buildid'" (exited with 1)
Created attachment 654288 [details] ~/.cache/abrt/spool/pyhook-2012-11-29-14:23:17-9144
if the problem is truncated core dump, could we get a more comprehensible error message? btw, once upon a time, wasn't there a fallback that the backtrace can be analysed locally when server fails? - not that it'd help in this particular case, but I'm missing the option ...
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 'version' of '18'. 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 prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 to Fedora 18's end of life. 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.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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.