Description of problem: ABRT is generating unusable backtraces for several WebKit and Epiphany bugs. I'm going to attach the entire crash folder for one of these. Version-Release number of selected component (if applicable): abrt-2.1.10-1.fc20 gnome-abrt-0.3.4-1.fc20 libreport-2.1.10-1.fc20 satyr-0.12-1.fc20 How reproducible: Sometimes (many WebKit crashes are reportable) Additional information: I notice that if I open the coredump with gdb, some debuginfo had not been installed. Not sure if that matters, since ABRT was generating the backtrace remotely. warning: core file may not match specified executable file. Reading symbols from /usr/libexec/WebKitWebProcess...Reading symbols from /usr/lib/debug/usr/libexec/WebKitWebProcess.debug...done. done. Missing separate debuginfo for /lib64/libgraphite2.so.3 Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/90/82e46860379c3dff9004eb8c9834e50afbb528 Missing separate debuginfo for Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/34/1e833ad17a340e8d289939e7d98e5837728626 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Missing separate debuginfo for /lib64/libgraphite2.so.3 Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/90/82e46860379c3dff9004eb8c9834e50afbb528.debug Core was generated by `/usr/libexec/WebKitWebProcess 17'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 0x00007ff816726b2a in ?? ()
Created attachment 843874 [details] crash folder from /var/tmp/abrt I had to leave out the core dump due to Bugzilla's attachment size limit.
(In reply to Michael Catanzaro from comment #0) > I notice that if I open the coredump with gdb, some debuginfo had not been > installed. Not sure if that matters, since ABRT was generating the backtrace > remotely. I'd say that it matters, because the retrace server generates the backtraces via gdb, so the retrace server also needs all the debuginfos. However, we see many unusable backtraces with unresolved frames (??) which we consider as JavaScript function calls, but I cannot understand why those frames cannot be resolved (this works fine for Python). A few coredumps may help us in further investigation.
What would be the best way to get you this core dump -- is email OK? It is 23 MB compressed.
Thank you! Yes, email is OK. I hope that we have no size limits for emails :)
I think it sent OK, but it took a while to upload so I'm posting this just to make sure.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening because this bug is still valid.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. 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 '29'. 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 29 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 bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
I believe that this has been resolved. We previously did not install all debuginfos. Some transitive deps were missing. This is resolved in upstream. Should be validated once Fedora Datacenter migration is over.
There are still issues with retracing Epiphany crashes. I'm currently looking into what the culprit is.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. 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 '32'. 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 32 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.
We have deployed an upgrade for Retrace Server yesterday which should fix this bug. I have also been able to successfully retrace a synthetic Epiphany crash. Can you please verify it works for you as well now?
Hi, unfortunately this is QA fail. I tested today by opening Epiphany and manually crashing it: $ killall -ILL epiphany For some reason, I had to do this twice before it actually crashed. That's weird. Anyway, here is my log: --- Running report_uReport --- ('report_uReport' completed successfully) --- Skipping collect_GConf --- No matching actions found for this event. --- Skipping collect_vimrc_system --- No matching actions found for this event. --- Skipping collect_vimrc_user --- No matching actions found for this event. --- Skipping collect_xsession_errors --- No matching actions found for this event. --- 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 4.7 MiB Upload successful Retrace job #327919292 started Analyzing crash data ................................................................................ ............................ Generating backtrace ....... Saving crash statistics --- Running analyze_BodhiUpdates --- Looking for similar problems in bugzilla Note that is 108 periods under "analyzing crash data." Each period prints every 10 seconds, so that means it took 1080 seconds, 18 minutes, in order to finish analyzing. IMO most reasonable users would give up after about two minutes, so that's no good. Then "generating backtrace" took just over one minute, so that's good. Then it failed, though the error is not displayed in the log. ABRT says "reporting is disabled because the generated backtrace has low informational value." However, I can generate the backtrace manually, after installing required debuginfo in two steps as recommended by gdb: $ coredumpctl gdb (gdb) bt full #0 0x00007f7a9da655bf in poll () at /lib64/libc.so.6 #1 0x00007f7a9dd7347c in g_main_context_poll (priority=<optimized out>, n_fds=5, fds=0x55d3fd8956e0, timeout=<optimized out>, context=0x55d3fcb1d9f0) at ../glib/gmain.c:4434 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f7a9dd24c90 <g_poll> max_priority = 2147483647 timeout = 3239 some_ready = <optimized out> nfds = 5 allocated_nfds = 5 fds = 0x55d3fd8956e0 begin_time_nsec = 34738796549422 #2 g_main_context_iterate.constprop.0 (context=context@entry=0x55d3fcb1d9f0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4126 max_priority = 2147483647 timeout = 3239 some_ready = <optimized out> nfds = 5 allocated_nfds = 5 fds = 0x55d3fd8956e0 begin_time_nsec = 34738796549422 #3 0x00007f7a9dd1cc03 in g_main_context_iteration (context=context@entry=0x55d3fcb1d9f0, may_block=may_block@entry=1) at ../glib/gmain.c:4196 retval = <optimized out> #4 0x00007f7a9df3b95d in g_application_run (application=0x55d3fcb126a0 [EphyShell], argc=-1516685164, argv=<optimized out>) at ../gio/gapplication.c:2560 arguments = 0x55d3fcc6a370 status = 0 context = 0x55d3fcb1d9f0 acquired_context = <optimized out> __func__ = "g_application_run" #5 0x000055d3fafb407b in main (argc=<optimized out>, argv=<optimized out>) at ../src/ephy-main.c:431 option_context = <optimized out> option_group = <optimized out> error = 0x0 user_time = 0 arbitrary_url = <optimized out> ctx = <optimized out> mode = <optimized out> status = <optimized out> flags = <optimized out> desktop_info = <optimized out> Although seeing a backtrace end in poll() isn't amazing, there's nothing wrong with it, and no reason ABRT should not be able to report it.
Ah, you're right, sorry. I've mistaken this bug for one of the Retrace Server issues. This is indeed an abrt problem. Could you please upload the backtrace that was generated by Retrace Server? (It should be the 'backtrace' file in the corresponding problem directory.)
Weird, I could report my crash just fine: bug 1975211.
(In reply to Matej Grabovsky from comment #16) > Could you please upload the backtrace that was generated by Retrace Server? > (It should be the 'backtrace' file in the corresponding problem directory.) Sigh, OK, but this is annoying because ABRT has of course already deleted the original problem directory, so I'll have to start over....
(In reply to Michael Catanzaro from comment #18) > Sigh, OK, but this is annoying because ABRT has of course already deleted > the original problem directory, so I'll have to start over.... OK, I made it crash again, and waited until ABRT had finished processing it. It failed again, same error as yesterday. Unfortunately, between the time that ABRT finished processing the backtrace and the time that I finally noticed and returned to this task, ABRT had already deleted the problem directory. I will try one last time, but my patience is thinning.
Created attachment 1793493 [details] Backtrace from retrace server OK, I managed to get it. The backtrace is indeed pretty bad. It looks like the retrace server failed to install any debuginfo packages.
Michael, if you have any similar crashes handy at the moment, could you please try to retrace them at retrace-stg.aws.fedoraproject.org? We have deployed an experimental version of Retrace Server with debuginfod integration there which should solve all of the debuginfo-related issues.
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
I found Preferences -> Events -> Retrace Server -> Configure -> Retrace server URI and changed the setting to https://retrace-stg.aws.fedoraproject.org. Testing now....
(In reply to Matej Grabovsky from comment #21) > Michael, if you have any similar crashes handy at the moment, could you > please try > to retrace them at retrace-stg.aws.fedoraproject.org? We have deployed an > experimental > version of Retrace Server with debuginfod integration there which should > solve all > of the debuginfo-related issues. It worked fine for me. And it's a lot faster than the current server, too.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. 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 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.