I have an F19 box with latest abrt and libreport from updates-testing: [adamw@laptop ~]$ rpm -q abrt abrt-2.1.6-3.fc19.x86_64 [adamw@laptop ~]$ rpm -q libreport libreport-2.1.6-2.fc19.x86_64 I just forced a crash of gedit to test crash reporting. abrt responds fine and goes all the way through the crash submission process, but at the end, reports "Processing failed". The text box contains all of this: --- Running report_uReport --- Server responded with an error: 'Validation failed: missing mandatory element 'crash_thread'' --- Running analyze_CCpp --- Ok to upload core dump? (It may contain sensitive data). If your answer is 'No', a stack trace will be generated locally. (It may download a huge amount of data). 'YES' Querying server settings Preparing an archive to upload Uploading 1327568 bytes Upload successful Retrace job started Preparing environment for backtrace generation ........... Generating backtrace Retrace job finished successfully Crash thread not found cat: duphash: No such file or directory reporter-bugzilla: option requires an argument -- 'h' Usage: reporter-bugzilla [-vbf] [-g GROUP-NAME]... [-c CONFFILE]... [-F FMTFILE] [-A FMTFILE2] -d DIR or: reporter-bugzilla [-v] [-c CONFFILE]... [-d DIR] -t[ID] FILE... or: reporter-bugzilla [-v] [-c CONFFILE]... [-d DIR] -t[ID] -w or: reporter-bugzilla [-v] [-c CONFFILE]... -h DUPHASH Reports problem to Bugzilla. The tool reads DIR. Then it logs in to Bugzilla and tries to find a bug with the same abrt_hash:HEXSTRING in 'Whiteboard'. If such bug is not found, then a new bug is created. Elements of DIR are stored in the bug as part of bug description or as attachments, depending on their type and size. Otherwise, if such bug is found and it is marked as CLOSED DUPLICATE, the tool follows the chain of duplicates until it finds a non-DUPLICATE bug. The tool adds a new comment to found bug. The URL to new or modified bug is printed to stdout and recorded in 'reported_to' element. Option -t uploads FILEs to the already created bug on Bugzilla site. The bug ID is retrieved from directory specified by -d DIR. If problem data in DIR was never reported to Bugzilla, upload will fail. Option -tID uploads FILEs to the bug with specified ID on Bugzilla site. -d DIR is ignored. Option -w adds bugzilla user to bug's CC list. If not specified, CONFFILE defaults to /etc/libreport/plugins/bugzilla.conf Its lines should have 'PARAM = VALUE' format. Recognized string parameters: BugzillaURL, Login, Password, OSRelease. Recognized boolean parameter (VALUE should be 1/0, yes/no): SSLVerify. Parameters can be overridden via $Bugzilla_PARAM environment variables. FMTFILE and FMTFILE2 default to /etc/libreport/plugins/bugzilla_format.conf -v, --verbose Be verbose -d DIR Problem directory -c FILE Configuration file (may be given many times) -F FILE Formatting file for initial comment -A FILE Formatting file for duplicates -t, --ticket[ID] Attach FILEs [to bug with this ID] -b When creating bug, attach binary files too -f Force reporting even if this problem is already reported -w Add bugzilla user to CC list [of bug with this ID] -h, --duphash DUPHASH Print BUG_ID which has given DUPHASH -g, --group GROUP Restrict access to this group only -D, --debug[STR] Debug No processing for event 'report_Bugzilla' is defined
satyr should always find crash thread. We had the same problem in btparser but we've fixed it. btparser commit 6a1db1e193db4136f2b170b911a946c30001fd98 Author: Martin Milata <mmilata> Date: Wed Mar 27 10:31:17 2013 +0100 Try harder when looking for crash thread The current algorithm cannot handle backtraces with multiple threads containing the designated crash frame such as [1]. We just pick the first one (from sorted threads) with the risk that our guess might be wrong. Fixes #3. [1] https://bugzilla.redhat.com/attachment.cgi?id=703269 Signed-off-by: Martin Milata <mmilata> Signed-off-by: Jakub Filak <jfilak>
Fixed in upstream git: commit 453531f241d25d34501b2675e0c9d54faa49e783 Author: Martin Milata <mmilata> Date: Mon Aug 12 14:19:28 2013 +0200 Always choose a crash thread If we don't know the crash thread, just choose the first one in order to generate a valid uReport. Closes rhbz#994747. Signed-off-by: Martin Milata <mmilata> Signed-off-by: Jakub Filak <jfilak> commit b9bc44b77aa6922df216565ed2fcd842e9ce5128 Author: Martin Milata <mmilata> Date: Mon Aug 12 14:19:27 2013 +0200 Try harder when looking for crash thread Backported from btparser 6a1db1e193db4136f2b170b911a946c30001fd98: The current algorithm cannot handle backtraces with multiple threads containing the designated crash frame such as [1]. We just pick the first one (from sorted threads) with the risk that our guess might be wrong. Fixes abrt/btparser#3. [1] https://bugzilla.redhat.com/attachment.cgi?id=703269 Related to rhbz#994747. Signed-off-by: Martin Milata <mmilata> Signed-off-by: Jakub Filak <jfilak>
satyr-0.7-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/satyr-0.7-1.fc18
satyr-0.7-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/satyr-0.7-1.fc19
Package satyr-0.7-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing satyr-0.7-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15360/satyr-0.7-1.fc19 then log in and leave karma (feedback).
*** Bug 1001686 has been marked as a duplicate of this bug. ***
satyr-0.7-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
satyr-0.7-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.