Description of problem: I have a completely updated Fedora 12 system. As I have reported in a separate bug, whenever I click on "Use Previous Settings" in desktop-effects applet, abrt detects a segfault in compiz and prompts me. When I click on report, it says that reporting is disabled because the backtrace is not usable. I manually did "debuginfo-install compiz" as abrt suggested, yet after clicking 'refresh' the backtrace was not created. I rebooted my system and reproduced the segfault again, and yet no backtrace is generated. I updated my abrt to the version from updates-testing, yet, the same problem occurs. Backtrace of compiz is not being generated even though the debug packages are installed. The bug against compiz is reported at - https://bugzilla.redhat.com/show_bug.cgi?id=547024 Version-Release number of selected component (if applicable): abrt-1.0.1-1.fc12.x86_64 (Installed from updates-testing) How reproducible: Always Steps to Reproduce: 1. Cause a segfault as reported in the compiz bug 2. Click on "Report". Install the debug packages 3. Reboot, cause segfault again, and try to report the bug Actual results: The reporting option is disabled because the backtrace is not usable. Expected results: abrt should generate a backtrace and allow me to report it.
Can you please try to press the "refresh" button again and send me abrt log from /var/log/messages? Thanks, Jirka
Created attachment 377972 [details] Output of grep abrtd /var/log/messages
I have attached the output. The session starting from 16:27.. is my current session.
(In reply to comment #0) > Description of problem: > I have a completely updated Fedora 12 system. As I have reported in a separate > bug, whenever I click on "Use Previous Settings" in desktop-effects applet, > abrt detects a segfault in compiz and prompts me. When I click on report, it > says that reporting is disabled because the backtrace is not usable. I manually > did "debuginfo-install compiz" as abrt suggested, yet after clicking 'refresh' > the backtrace was not created. I rebooted my system and reproduced the segfault > again, and yet no backtrace is generated. Can you show this "bad" backtrace? > I updated my abrt to the version from updates-testing, yet, the same problem > occurs. Which version is it? 1.0.1? It had an important fix exactly in that area. In case it's not 1.0.1 but earlier one, you can get 1.0.1 here: http://koji.fedoraproject.org/koji/buildinfo?buildID=146344 If you do use 1.0.1, then please do the following in an xterm window: killall abrtd abrtd -dvvv then reproduce this segfault again. In xterm, "abrtd -dvvv" will dump a lot of debug logs. Invoke abrt-gui as usual, press [Report] and then in report window, [Refresh] to force regeneration of backtrace. "abrtd -dvvv" will spew even more log. Post the entire resulting log of "abrtd -dvvv". Indicaqte the part which was printed after you pressed [Refresh].
Yes, I have version 1.0.1 installed. I am attaching a screenshot the "bad" backtrace, but there is no way I can "Report" or copy/paste from it, because that option is greyed out. I have also generated the log file as per your instructions. It's quite long - 364 lines. I have commented inline that at what point what action was taken. You can search for string "---" within the abrtd.log, or specifically look at lines 95, 108, 142, and 290.
Created attachment 378231 [details] Log of abrtd -dvvv
Created attachment 378233 [details] Screenshot of "bad" backtrace
Seems like you don't have glib2-debuginfo installed or the crash happened some time ago and the required debuginfo is no longer available in repository. Btw, the backtrace can be copy/pasted, just doubleclick on it, and then you can copy it. Jirka
I am surprised why glib2-debuginfo was not automatically installed. I installed it manually by enabling the repo updates-debuginfo. However, even after doing that, the result is the same. I am attaching the bad backtrace as text, following the method you told, Jiri.
Created attachment 378243 [details] The "bad" backtrace
The key line in the logs is: abrtd: Executing: abrt-debuginfo-install /var/cache/abrt/ccpp-1260800907-2694/coredump /var/run/abrt/tmp-3680-1260801883 /var/cache/abrt-di It is the part which installs debuginfos. In your case it is rather short: abrtd: Update(':1.73'): Downloading and installing debug-info packages... abrtd: DBus message sent abrtd: Getting list of build IDs abrtd: Update(':1.73'): Getting list of build IDs abrtd: DBus message sent abrtd: Update(':1.73'): Getting backtrace... abrtd: DBus message sent "Getting list of build IDs" is the only line of output abrt-debuginfo-install produced. This means that either it found that all debuginfos are installed, or that we have a problem in it and it exits with error. I'm going to add logging for both these cases. Meanwhile, replace debug=false with debug=true in /usr/bin/abrt-debuginfo-install and run as root: abrt-debuginfo-install /var/cache/abrt/ccpp-1260800907-2694/coredump /var/run/abrt/tmp-3680-1260801883 /var/cache/abrt-di; echo $? Post the output in this bz.
Since I rebooted, those directories no longer exist. I instead did, # abrt-debuginfo-install /var/cache/abrt/ccpp-1260803925-2473/coredump /var/run/abrt/tmp-2454-1259780143/ /var/cache/abrt-di ; echo $? 2 Should I re-create the crash again and run the command, or is the above return code expected?
No, the exit code > 1 means there is a "serious" problem. Please replace /usr/bin/abrt-debuginfo-install with attached updated script. It should not just exit with exitcode 2, it should talk much more in this case.
Created attachment 378320 [details] updated abrt-debuginfo-install
Created attachment 378324 [details] updated abrt-debuginfo-install
I think I am doing something wrong here. Here is the output after replacing the script with your attachment: # abrt-debuginfo-install /var/cache/abrt/ccpp-1260803925-2473/coredump /var/run/abrt/tmp-2454-1259780143 /var/cache/abrt-di ; echo $? tempdir exists: '/var/run/abrt/tmp-2454-1259780143' 2 As you can see, the return value remains the same.
A small note - your updated executable had debug=false. Even after setting it to true, the output remains the same.
OK, I tried something different here. What I did was, use my coredump with your tmpfile specified in comment#11 Here is the output - I hope it's more useful. # abrt-debuginfo-install /var/cache/abrt/ccpp-1260803925-2473/coredump /var/run/abrt/tmp-3680-1260801883 /var/cache/abrt-di; echo $? Installing rpms to /var/run/abrt/tmp-3680-1260801883 Getting list of build IDs build_ids:0afdfc236fadadc174323855991e9afa63360400 0ec6ba2acef3a67e48fc894f18d4a7913125a50d 12883088ff5c2dfaa04ee42435f515560bdeecaf 145c712e218ab327cdd16ff523056c8ab2c68294 1f31f561b10e68203283a35e0f1f8bf0ad46c84e 2b03aa03331551a7e2d7fd2470b99af863e7c9e1 38bd75b0d94bdf736e935e3f0b6d4ed18bcef7c1 3ff78f236176ecfa488a4df0112f3ff1478a124f 4c4b1ca2393197e6658f351112ec2ea2f32f9ced 58eb8a7b1c74f7facf01ffd3e9b3a10fafdf05ce 5c195153e2b3aeace0c72d8eea203eaa9e74c63d 620d35288a3137687ca0a2ef1917ef543d6b5869 83afecd9a0aa5d42ea2bb275b48c6385d9cc97b8 88b05b8bb32e8fc5e1d0c58f165c33a192215685 8a4949b0eb39d033b62514f61dace4c70c71bbf3 8ae7bb8df77cf7fa71cbcd68cf6abca1b1bd37d4 8b6cd4c9e19f88ca8d4e0fd1ea4f49cf7e8a6fd7 8f54a62dcf8753e5265b588d32ebdd2cf96c61cc 9b1838e94352154046ccb8e95f396253514a11fb 9bd79480b45c87c4d4af2ddf46d10405cd140ab2 9c0151c28122eb604d54603468179c1080ff7228 adf0f56d7d44f97dacab8f2a7e220ec0ec237207 b76103f4198b5c1180100aa6392db35ab1b2f65a c8bfafb14c6e1c4b21a16765e601d3e7e08f823b ced98f19673e83ee5e2eae7b2c7d517f010ce796 d49914dcecd08774947bb70d0604cbedfae6e5a1 d5b08da904eee20fe0ead010f2686e384eb0f53e d6198e1764fa3832b5c6a435c07c3a118d2542e8 d73925edb8c03810592e2704d5678ea564291b6f dd3d97d610928e4d2686d50c31585b0275faa38d dd5f3280ba24f55fb1e194b962e59647fab8c8b2 e133dc5a57e3e3342052c450fd5e0d373a2bd8ef e15e600f23a806cb24b3480cda6ae61a04ff5ec3 e1fa559bb294c88aba88704ea01f926c942a15e5 e4fb87cca758190ded58a404bc93dd1cd673ac6b e730a39d2da43532d75847cb319accb49fcf298c efb64e46743a445b4aea6e4f82ba1f91ed6f4cea f50d186ad7c8fd53c38d7da419dc209a64a63c4f f7933750da80f555321576e72b375caf7a3cc075 missing_debuginfo_files: missing_build_ids: Removing /var/run/abrt/tmp-3680-1260801883 All needed debuginfos are present 0
Ok, this shows that build IDs are extracted correctly, and all debuginfos are present. From attachment in comment #10, this message: Backtrace stopped: previous frame inner to this frame (corrupt stack?) says that either gdb got confused by the coredump, or coredump is genuinely broken. Do you have such "bad" coredump saved? How big is it (compressed)? Is it small enough to be attached to this bz? We may have our gdb guru to take a look at it. Maybe it's a gdb problem.
Denys, I don't know where the "bad" coredump is produced or saved. Judging by the command above, if the coredump is "/var/cache/abrt/ccpp-1260803925-2473/coredump", then I do have it saved. It's ~16mb uncompressed, and ~1.4mb when compressed. I am attaching it to this bz. Please tell me if it is the correct/required coredump.
Created attachment 378513 [details] The "bad" coredump
I am able to run "bt full" gdb command on this backtrace without getting Backtrace stopped: previous frame inner to this frame (corrupt stack?) # gdb --version GNU gdb (GDB) Fedora (7.0-3.fc12) Closing the bug.