Description of problem: The abrt GUI tool fails at the reporting step of any bug with the following error: --- Running report_Bugzilla --- Essential file 'duphash' is missing, can't continue.. (exited with 1) Version-Release number of selected component (if applicable): 2.0.3 How reproducible: Just try reporting any bug to bugzilla. Steps to Reproduce: 1. Follow the wizard to report a bug to bugzilla. 2. 3. Actual results: --- Running report_Bugzilla --- Essential file 'duphash' is missing, can't continue.. (exited with 1) Expected results: Report the bug, or find existing bugs. Additional info: I have quite a backlog of crashes which I'll need to report manually, unless this is fixed. ;)
same problem here
*** Bug 737961 has been marked as a duplicate of this bug. ***
Are you using one of Local GNU Debugger/Retrace Server analyzers? This happens to me when skipping the analyzers with Go to reporting step choice and trying to report the bug to bugzilla.
Haven't tried with retrace server yet (Don't even know what it is). I guess local gdb shouldn't give me such problems. Bugzilla definitely gives me this problem.
(In reply to comment #5) > Haven't tried with retrace server yet (Don't even know what it is). Alternative to gdb backtrace generation - you upload you core dump to retrace server and it will install all the required debuginfo to recreate the backtrace (so you don't have to install all the debuginfo on your machine) > I guess local gdb shouldn't give me such problems. > Bugzilla definitely gives me this problem. It's related as bugzilla reporter fails because your report has no backtrace and so no 'duphash' can't be created (backtrace is used in the process). It has to be fixed anyway.
(In reply to comment #6) > Alternative to gdb backtrace generation - you upload you core dump to retrace > server and it will install all the required debuginfo to recreate the backtrace > (so you don't have to install all the debuginfo on your machine) > It's related as bugzilla reporter fails because your report has no backtrace > and so no 'duphash' can't be created (backtrace is used in the process). Okay. Let me try all options and report back.
The problem is, it GUI allows user to skip the analyze step entirely and doesn't check the bt rating anymore - this should be definitely fixed.
Can you please try to re-report it and this time make sure you select either "Local GDB" or "Retrace server" (doesn't work on F16) on "Select analyzer" page.
*** Bug 739210 has been marked as a duplicate of this bug. ***
Created attachment 523958 [details] Abrt hung with missing debuginfo
With retrace server option... --- Running analyze_RetraceServer --- Querying server settings Preparing an archive to upload Uploading 145112 bytes Upload successful Retrace job started Analyzing crash data Analyzing crash data Analyzing crash data Analyzing crash data 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 Initializing virtual root Retrace job finished successfully But what is the result of the retrace job, I don't see. With analyse locally option, as you expected, debuginfo is missing... Attached a screenshot. Window is hung.
(In reply to comment #12) > With retrace server option... > > --- Running analyze_RetraceServer --- > Querying server settings > Preparing an archive to upload > Uploading 145112 bytes > Upload successful > Retrace job started > Analyzing crash data > Analyzing crash data > Analyzing crash data > Analyzing crash data > Initializing virtual root > Retrace job finished successfully > > But what is the result of the retrace job, I don't see. - generated backtrace > > With analyse locally option, as you expected, debuginfo is missing... > Attached a screenshot. Window is hung. - this windows should end up with message "Backtrace was generated", maybe it's just taking too long
Fixing it with these changes: commit c06530497ee3c6a263dcbd4309ecc44c4a8370c2 Author: Denys Vlasenko <dvlasenk> Date: Tue Sep 20 17:35:13 2011 +0200 fix a bug in checking VAR!=VAL condition commit 1dfa30b18b21b8680d22067b7c044e144d1c0263 Author: Denys Vlasenko <dvlasenk> Date: Tue Sep 20 17:37:20 2011 +0200 Allow report_Bugzilla only if duphash is present This way, if user did not perform local or remove backtrace generation, wizard won't allow reporting to Bugzilla. Finally, improving bt generation logging so that user is better informed where it is stuck (if it is stuck): commit d89da065654d988d8eef336bca5d4e2964d9362b Author: Denys Vlasenko <dvlasenk> Date: Tue Sep 20 17:40:40 2011 +0200 Adding log messages to make it more clear what backtrace generation is doing Three new messages: Initializing yum Setting up yum repositories Generating backtrace First two because I observe a longish pause between Coredump references 4 debuginfo files, 2 of them are not installed and Looking for needed packages in repositories and want to know why.
libreport-2.0.5.980-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/libreport-2.0.5.980-1.fc16
abrt-2.0.4.981-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/abrt-2.0.4.981-1.fc16
Package libreport-2.0.5.980-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libreport-2.0.5.980-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/libreport-2.0.5.980-1.fc16 then log in and leave karma (feedback).
libreport-2.0.5.980-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
abrt-2.0.4.981-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Hey, why was this not fixed for Fedora 15? It is still supported, yes? I have exactly this problem with F-15. I didn't say anything because I thought this bug would fix it.
HELP !! Fedora 15 is yet supported but didn't received the fix yet for this bug. My configuration at present time follows: cofee:/home/andrei# uname -a Linux cofee 2.6.42.3-2.fc15.x86_64 #1 SMP Thu Feb 9 01:42:06 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux cofee:/home/andrei# yum list libreport abrt Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit Installed Packages abrt.x86_64 2.0.3-6.fc15 @fedora-local libreport.x86_64 2.0.4-4.fc15 @fedora-local Available Packages libreport.i686 2.0.4-4.fc15 updates cofee:/home/andrei# yum update libreport abrt Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit Setting up Update Process No Packages marked for Update Possible dupe report: https://bugzilla.redhat.com/show_bug.cgi?id=748294
Yup - me too! FC15 x86_64. Can I install the FC16 version somehow, or does it need a specific FC15 copy?
In FC15 error is shown even if backtrace was generated. I generated it locally.