Created attachment 1355783 [details] unusable backtrace Description of problem: Trying to report a bug but results in "Reporting disabled because the backtrace is unusable" Version-Release number of selected component (if applicable): abrt-2.10.3-3.fc26.x86_64 How reproducible: For a given problem in Problem Reporting, 100% Steps to Reproduce: Not really applicable. You'd need to first reproduce the exact same crash as I have Actual results: --- Running report_uReport --- ('report_uReport' completed successfully) --- 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). 'NO' Analyzing coredump 'coredump' All debuginfo files are available Generating backtrace Backtrace is generated and saved, 122403 bytes --- Running analyze_BodhiUpdates --- Looking for similar problems in bugzilla Duplicate bugzilla bug '#1514031' was found Searching for updates No updates for this package found Reporting disabled because the backtrace is unusable Expected results: Should report successfully. Additional info: For my own future reference, this is from ccpp-2017-11-12-12:05:43.735956-3724.
Thank you for reporting. Backtrace should be enough, but to be sure please attach whole tar-ed problem directory. You can also open a bug on gtk, where this segmentation fault occurred. The component to which to open a bug, you can find in problem directory in file named component. (Problem directory you can determine also in gnome-abrt tool named "Problem Reporting", after clicking on "Details", find "data_directory /var/spool/abrt/....)
> please attach whole tar-ed problem directory. Anyone who understands what a core file is won't/shouldn't be doing that. The core file could contain sensitive information. Other than the core file, what else in the directory is of interest in debugging this issue? > You can also open a bug on gtk, where this segmentation fault occurred. Is that to say that the bad stack trace is actually a gtk problem, not an abrt problem? Why do I have a number of these across different components around the same time then? What is it that a given application can do to make the core file that the O/S generates when an application crashes such that a meaningful backtrace can't be taken from it? It just seems to me like creating a core file or taking a backtrace from one is outside of the domain of the application that crashed. > in file named component. That says gnome-terminal FWIW.
> Other than the core file, what else in the directory is of interest in debugging this issue? Probably nothing, just to reproduce it on our side, it is sometimes easier to have those files to trigger sending it to abrt server (FAF), which answered you that stack trace is not valid, however it's not necessary, stack trace should be enough. Coredump is not needed. > Is that to say that the bad stack trace is actually a gtk problem, not an abrt problem? Why do I have a number of these across different components around the same time then? ... You are right stack trace itself is fine. The problem with gnome-terminal is that it crashed with segfault. :) Which is independent on abrt ability of parsing its stack trace and is totally different bug, segfaoult just shouldn't occur.
Oh, so yes. I understand. You were just saying, orthogonality, that I should report the actual segfault to the gnome-terminal component. Which is what I was trying to do with abrt. :-) I thought you were saying I should report the invalid backtrace issue to the gnome-terminal component. The interesting point will be why the FAF server thinks the backtrace is invalid, since I have a few bug reports here where it's saying the same thing.
Find out, that it is not a FAF mistake, this is done on abrt client.
I see this on F27. Second time in a row. abrt should definitely give more defails about the error. Otherwise it is frustrating to the user and impossible to file a bug report. `/var/tmp/abrt/` is empty for me.
And I see a lot of these issues closed EOL for older fedora releases. This should definitely be fixed if abrt utility is expected to be useful.
@Brian Your report is duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1514031 I agree that ABRT should print more in case of "Reporting disabled because the backtrace is unusable" and say why exactly is unusable. It is very likely because we were unable to resolve all pointers in traceback. Without the coredump we cannot resolve it. I understand that it may contain sensitive data. So it is up to you if you want to provide it. Without it we cannot solve your specific case, and just leave this BZ open and resolve it with more verbose version of string "BT is unusable".
I don't think issue is dup of bug 1514031. This one is about failure of abrt to report issue and no debug output. So I think this should be resolved my debug output to user + instructions how to report abrt issue. While bug 1514031 can be handled for the specific crash. This is how I read it. In any case, for me it is more interesting to get ABRT working.
(In reply to Miroslav Suchý from comment #8) > @Brian > Your report is duplicate of > https://bugzilla.redhat.com/show_bug.cgi?id=1514031 Not at all. This ticket is not about the actual crash that caused the backtrace that is in attachment #1355783 [details] but rather than abrt is with increasing frequency unable to report crashes because it is unable to create a usable backtrace. Attachment #1355783 [details] is merely an example backtrace that abrt complains is unusable. > Without the coredump we cannot resolve it. But abrt has the coredump. Why is it unable to resolve it? > I understand that it > may contain sensitive data. So it is up to you if you want to provide it. If I can provide it to you to make the backtrace usable why cannot abrt do that here, locally, on it's own given that it has coredump in hand? *That*, if your supposition (very likely because we were unable to resolve all pointers in traceback) is correct, is what this ticket should be about I suppose.
Created attachment 1360429 [details] unusable backtrace Another unusable backtrace
Created attachment 1365365 [details] backtrace Got another one of these. Abrt reported: Generating backtrace Backtrace is generated and saved, 50965 bytes Backtrace parsing failed for . 117:0: Function call in the frame header misses mandatory "at file.c:xy" section Indeed, at line 117 of this attachment you can see: #0 0x00000000000006d0 in () #1 0x00007f3f02ca3d93 in call_init (env=0x7ffce5056b20, argv=0x7ffce5056b08, argc=2, l=<optimized out>) at dl-init.c:72 j = <optimized out> jm = <optimized out> addrs = <optimized out> init_array = <optimized out> env = 0x7ffce5056b20 argv = 0x7ffce5056b08 argc = 2 l = <optimized out> preinit_array = <optimized out> preinit_array_size = <optimized out> i = 27 So what can be done to avoid this and make these backtraces usable?
Also note another report of this issue in bug #1515265.
See also bug #1532004.
*** Bug 1514980 has been marked as a duplicate of this bug. ***
*** Bug 1523523 has been marked as a duplicate of this bug. ***
*** Bug 1532004 has been marked as a duplicate of this bug. ***
*** Bug 1569633 has been marked as a duplicate of this bug. ***
Been seeing this for a few Fedora versions now, Abrt is generating too many "unusable backtrace"s preventing Bugzilla reporting.
> Unusable backtrace is usually caused by damaged coredump, missing debug > information or usage of unsupported coding technique (i.e. JavaScript in > GNOME3). These cause that the generated backtrace has low information value for > developers because function names are replaced with '??' string which is place > holder for unavailable function name. In order to provide valuable crash > reports, ABRT will not let you create a Bugzilla bug for such a backtrace. From https://github.com/abrt/abrt/wiki/FAQ#why-is-my-backtrace-unusable We should change the message to say something more informative to the user. My proposal: << Reporting is disabled because the generated backtrace has low informational value. >> **** warning: the debug information found in "/var/cache/abrt-di/..." does not match "/usr/lib64/..." (CRC mismatch). This is probably the root cause of the problem. The above means that the debuginfo from /var/cache/abrt-di and the system package versions differ. You can try and delete the cached debuginfos from /var/cache/abrt-di and regenerate the backtrace again.
(In reply to Martin Kutlak from comment #20) > > My proposal: > << Reporting is disabled because the generated backtrace has low > informational value. >> How do we know this is actually the case and not just a mis-interpretation of the value of the backtrace? > warning: the debug information found in "/var/cache/abrt-di/..." does not > match "/usr/lib64/..." (CRC mismatch). > > This is probably the root cause of the problem. The above means that the > debuginfo from /var/cache/abrt-di and the system package versions differ. So that's a bug in abrt's management of it's own private debuginfo cache isn't it? Shouldn't that cache always reflect what's installed on the system and anything that is stale pruned from the cache? > You can try and delete the cached debuginfos from /var/cache/abrt-di and > regenerate the backtrace again. But shouldn't abrt be doing this automatically? This is abrt's own debuginfo cache after-all. Not that I understand/stood why abrt needed it's own debuginfo cache TBH. Not sure why not just installing -debuginfo RPMs wasn't sufficient. At least that way they would be kept in sync with the their respective packages being updated.
(In reply to Brian J. Murrell from comment #21) > > How do we know this is actually the case and not just a mis-interpretation > of the value of the backtrace? I think probably what I am getting at here is that abrt's inability to obtain a useful backtrace is in an of itself a problem (perhaps even a bug) and to simply dismiss sending a bug report because of that is sweeping the problem under the rug. In the case where a useful bug report cannot be made, an option to send a bug against abrt about that should be presented so that we can eliminate these issues of inability to report a bug.
> Reporting is disabled because the generated backtrace has low informational value. While it may sound a little better, it doesn't give any more useful information than the original error message. By *useful* I mean some explanation what may have caused the issue and how user can fix it. Also I agree with comment 22.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. 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 EOL if it remains open with a Fedora 'version' of '27'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 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 this bug is closed as described in the policy above. 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.
This still happens in F29. Can we make some progress per comment #22?
PR: https://github.com/abrt/libreport/pull/542 (In reply to Brian J. Murrell from comment #21) > But shouldn't abrt be doing this automatically? This is abrt's own > debuginfo cache after-all. Not that I understand/stood why abrt needed it's > own debuginfo cache TBH. Not sure why not just installing -debuginfo RPMs > wasn't sufficient. At least that way they would be kept in sync with the > their respective packages being updated. ABRT has its own cache so non-privileged users can analyze core dumps and report the obtained backtraces.
libreport-2.9.7-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-67d5c02581
An update associated with this bug has been pushed to stable.
A Fedora update associated with this bug has been pushed to the stable repository.