Bug 994747 - Crash report failed with latest abrt/libreport
Crash report failed with latest abrt/libreport
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: satyr (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Martin Milata
Fedora Extras Quality Assurance
:
: 1001686 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-07 19:59 EDT by Adam Williamson
Modified: 2013-09-11 21:58 EDT (History)
10 users (show)

See Also:
Fixed In Version: satyr-0.7-1.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-11 21:50:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2013-08-07 19:59:32 EDT
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
Comment 1 Jakub Filak 2013-08-08 03:33:06 EDT
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@redhat.com>
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@redhat.com>
    Signed-off-by: Jakub Filak <jfilak@redhat.com>
Comment 2 Jakub Filak 2013-08-13 06:49:48 EDT
Fixed in upstream git:

commit 453531f241d25d34501b2675e0c9d54faa49e783
Author: Martin Milata <mmilata@redhat.com>
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@redhat.com>
    Signed-off-by: Jakub Filak <jfilak@redhat.com>

commit b9bc44b77aa6922df216565ed2fcd842e9ce5128
Author: Martin Milata <mmilata@redhat.com>
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@redhat.com>
    Signed-off-by: Jakub Filak <jfilak@redhat.com>
Comment 3 Fedora Update System 2013-08-26 12:18:18 EDT
satyr-0.7-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/satyr-0.7-1.fc18
Comment 4 Fedora Update System 2013-08-26 12:18:38 EDT
satyr-0.7-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/satyr-0.7-1.fc19
Comment 5 Fedora Update System 2013-08-27 19:25:19 EDT
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).
Comment 6 Martin Milata 2013-08-28 04:53:49 EDT
*** Bug 1001686 has been marked as a duplicate of this bug. ***
Comment 7 Fedora Update System 2013-09-11 21:50:56 EDT
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.
Comment 8 Fedora Update System 2013-09-11 21:58:41 EDT
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.

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