Description of problem: The program virtuoso-t crashes when I log in, and there is an entry in abrt. When I try to submit the bug, I get the message "Reporting disabled because the backtrace is unusable". Version-Release number of selected component (if applicable): Abrt 2.0.12 How reproducible: It has failed twice and never succeeded Steps to Reproduce: 1. Open Abrt and choose to submit bug 2. Agree to send sensitive data 3. One of the two below: 3a. I get the above message. Log is attached below. 3b. If I open a bug from "Submitted reports", nothing happens. At the top it says "Processing finished" with a spinning circular widget next to it, "Show log" is empty and at the bottom it says "Reporting disabled because the backtrace is unusable" Actual results: Fails to report Expected results: Succeeds, or offers to do a local backtrace Additional info: I can't get the log from "Show log" now, need to log out/in to get another backtrace, will update bug
Here is the log: --- Running report_uReport --- (exited with 0) --- Running analyze_RetraceServer --- Querying server settings Preparing an archive to upload Uploading 226388 bytes Upload successful Retrace job started Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Retrace job finished successfully Backtrace parsing failed for . 1:0: No frame and no thread found.
Seems like a retrace-server bug. What application did you try to retrace?
Package: virtuoso-opensource Problem: Process /usr/bin/virtuoso-t was killed by signal 11 (SIGSEGV) I believe it's a file indexer for KDE
I tried to report a new instance of the crash, and I got this message: --- Running report_uReport --- This problem has already been reported. https://retrace.fedoraproject.org/faf/reports/614/ https://bugzilla.redhat.com/show_bug.cgi?id=713530
The bug has been caused by a wrong dependency resolution on the server side. A new version, using a different algorithm (not yum) for matching debuginfos has been deployed recently. I believe this is fixed.