Created attachment 1759211 [details] Screnshot of the desktop to evidence the long time before of the failed Description of problem: when abrt generate a backtrace its fail every time after 40 minutes Version-Release number of selected component (if applicable):abrt-2.14.5-1.fc33.x86_64 How reproducible: Every time to generate a report Steps to Reproduce: 1. Apllication crashed 2. Automatically start abrt analitycs 3. Attend 40 minutes to Retrace failed Actual results: Retrace failed Expected results: Report a bug on Bugzilla Additional info:
So, after bug 1902312 (and bug 1885154) have been closed, I guess this is the new "retrace failed" bug for abrt. =========================================== $ abrt report 0a31090 Reporting problem 0a31090 no actions matching this problem found for event 'collect_GConf' no actions matching this problem found for event 'collect_vimrc_system' no actions matching this problem found for event 'collect_vimrc_user' ('report_uReport' completed successfully) No /home/christian/.cache/gdm/session.log 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). [y/N/f/e] y Querying server settings Preparing an archive to upload Uploading 3.6 MiB Upload successful Retrace job started Generating backtrace . Retrace job failed Retrace failed. Try again later and if the problem persists report this issue please. [2021-03-06 22:15:49] [I] Analyzing crash data Do you want to generate a stack trace locally? (It may download a huge amount of data but reporting can't continue without stack trace). [y/N/f] =========================================== This keeps happening, over and over again, and I don't know the last time abrt would be able to successfully complete the retrace job anymore. And I don't mean to complain, but I asked this question a couple of times now: isn't this a huge problem when people are no longer able to report bugs to Fedora? I could imagine getting bug reports along with backtraces must be the best (most useful) bugs a software company could receive, so it's really puzzling to me why the retrace server isn't working correctly for some time now :-\
And again: $ abrt report 05750bd Reporting problem 05750bd no actions matching this problem found for event 'collect_GConf' no actions matching this problem found for event 'collect_vimrc_system' no actions matching this problem found for event 'collect_vimrc_user' ('report_uReport' completed successfully) No /home/christian/.cache/gdm/session.log 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). [y/N/f/e] y Querying server settings Preparing an archive to upload Uploading 2.0 MiB Upload successful Retrace job started Analyzing crash data ....... Retrace job failed Retrace failed. Try again later and if the problem persists report this issue please. [2021-03-25 15:55:12] [I] Analyzing crash data Do you want to generate a stack trace locally? (It may download a huge amount of data but reporting can't continue without stack trace). [y/N/f] ('analyze_CCpp' exited with 1)
Tok! Tok! Is there anyone?
Yes! Matej is focusing on this issue and he made a huge progress already. Ths fix should land shortly. Sorry for the inconvenience.
$ abrt report fc505cb Reporting problem fc505cb no actions matching this problem found for event 'collect_GConf' no actions matching this problem found for event 'collect_vimrc_system' no actions matching this problem found for event 'collect_vimrc_user' no actions matching this problem found for event 'collect_xsession_errors' ('report_uReport' completed successfully) 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). [y/N/f/e] y Querying server settings Preparing an archive to upload You are going to upload 15.0 MiB. Continue? [y/N] y Uploading 15.0 MiB Upload successful Retrace job started Analyzing crash data ................................................................................ ................. Retrace job failed Retrace failed. Try again later and if the problem persists report this issue please. [2021-04-25 16:34:50] [I] Analyzing crash data Do you want to generate a stack trace locally? (It may download a huge amount of data but reporting can't continue without stack trace). [y/N/f] n ('analyze_CCpp' exited with 1)
$ ksh & [1] 284475 $ kill -6 $! [1]+ Stopped ksh $ fg ksh Aborted (core dumped) $ abrt f7f50e5 1x ksh 2021-05-02 16:05:25 $ abrt report f7f50e5 Reporting problem f7f50e5 no actions matching this problem found for event 'collect_GConf' no actions matching this problem found for event 'collect_vimrc_system' no actions matching this problem found for event 'collect_vimrc_user' no actions matching this problem found for event 'collect_xsession_errors' ('report_uReport' completed successfully) 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). [y/N/f/e] y Querying server settings Preparing an archive to upload Uploading 31.9 KiB Upload successful Retrace job started Retrace job failed Retrace failed. Try again later and if the problem persists report this issue please. [2021-05-02 14:08:11] [I] Analyzing crash data Do you want to generate a stack trace locally? (It may download a huge amount of data but reporting can't continue without stack trace). [y/N/f] n ('analyze_CCpp' exited with 1)
We have deployed an upgrade for Retrace Server yesterday which should fix most of these problems. At the moment, retracing Fedora 33 and 34 on x86-64 should should proceed with little problems. (Note that very big coredumps might still take some time and perhaps fail anyway. We'll be looking into that as a separate problem.)