Is abrt broken?

dd_wizard · #1 7th June 2010, 02:32 AM

Is it just me, or is abrt on vacation? I'm getting several crashes a day while testing gnome-shell, but I've yet to have one trapped by abrt.

Just curious,
dd_wizard

---------- Post added at 06:32 PM CDT ---------- Previous post was at 06:30 PM CDT ----------

It's not just gnome-shell. While evince was seg faulting because of dconf, I didn't get any abrt messages either.

dd_wizard

dd_wizard · #2 8th June 2010, 02:24 AM

I've never had to do this before, but enabling core dumps fixed abrt. Now it catches crashes.

dd_wizard

#3 8th June 2010, 06:33 AM

abrt is garbage...

do yourself a favor and

Code:

# yum remove abrt*

It did not work in F12 and I don't want to bother in F13

RahulSundaram · #4 8th June 2010, 04:31 PM

Quote:

Originally Posted by dd_wizard

I've never had to do this before, but enabling core dumps fixed abrt. Now it catches crashes.

dd_wizard

File a bug report with more details.

RahulSundaram · #5 8th June 2010, 04:32 PM

Quote:

Originally Posted by mh3rn4nd3z3

abrt is garbage...

do yourself a favor and

Code:

# yum remove abrt*

It did not work in F12 and I don't want to bother in F13

I don't think calling Free software someone has volunteered to do garbage is the right approach. If you have problems, provide your feedback constructively. It will get better over time as a result.

dd_wizard · #6 8th June 2010, 09:08 PM

Bug 601888 filed, Rahul. I was almost certain abrt worked with ulimit -c 0 prior to F14, thanks for the input.

dd_wizard

R3353 · #7 8th June 2010, 11:15 PM

Quote:

Originally Posted by mh3rn4nd3z3

abrt is garbage...

do yourself a favor and

Code:

# yum remove abrt*

It did not work in F12 and I don't want to bother in F13

then don't, but don't bother complaining in the wrong forum either. Some of us actually want to improve future releases, which involves reporting bugs.

GoinEasy9 · #8 9th June 2010, 04:04 AM

@dd_wizard
Your correct, adding ulimit -c unlimited brought back abrt. I haven't spent much time on rawhide the past few days and didn't notice it was gone, with all the SELinux errors coming up.

---------- Post added at 11:04 PM CDT ---------- Previous post was at 10:49 PM CDT ----------

gedit stopped working, BZ filed https://bugzilla.redhat.com/show_bug.cgi?id=602039

dd_wizard · #9 9th June 2010, 07:49 PM

I beat you, GE9... Bug 602028 has a new attachment today. Yesterday, gedit seg faulted on startup. Today, it seg faults on exit!

dd_wizard

GoinEasy9 · #10 9th June 2010, 10:29 PM

Damn...and Geez, can't wait to do today's updates. I put cross comments into the 2 bugzilla's in case someone decides to look at them.

---------- Post added at 04:30 PM CDT ---------- Previous post was at 03:22 PM CDT ----------

@dd_wizard
I got a comment added that said debuginfo's were missing from my BZ 602039. I just checked and they are missing from your BZ 602028 also. Filed a new BZ about gedit closing and it didn't find a duplicate, so :
https://bugzilla.redhat.com/show_bug.cgi?id=602429 is the new one, I pointed it back to 602039 & 602028.

Any ideas how to get debuginfo's installed again? Is it because we set ulimit -c to unlimited?

Gonna play around with it and see if I come up with a fix.

---------- Post added at 04:35 PM CDT ---------- Previous post was at 04:30 PM CDT ----------

It's telling me it's loading the debuginfo files, but it looks like it completes in about 15-20 seconds, so it's not loading them.

---------- Post added at 04:41 PM CDT ---------- Previous post was at 04:35 PM CDT ----------

Wonders if debuginfo has moved to a different repo?

---------- Post added at 04:50 PM CDT ---------- Previous post was at 04:41 PM CDT ----------

rawhide-debuginfo was disabled, enabling it was not successful, so I am using debuginfo-install gedit to see if that helps.

---------- Post added at 05:19 PM CDT ---------- Previous post was at 04:50 PM CDT ----------

It reduced the number of missing debuginfo's from 80 to 39, but I can't figure out what other ones it's looking for. It was nice when abrt was working and it did the work for me. Do the .core files in my home directory have any useful information? I'm not having success opening them up.

---------- Post added at 05:29 PM CDT ---------- Previous post was at 05:19 PM CDT ----------

After dinner considering a new BZ about abrt not loading up debuginfo packages.

dd_wizard · #11 10th June 2010, 12:32 AM

abrt sticks a core file in /var, so you may as well delete the ones in your home directory. Also, I discovered that you don't need to set ulimit -c to unlimited. I've got mine set at 1024, and I get truncated core files in ~, but full sized ones in /var/spool/abrt. That saves space in ~.

abrt usually requests running debuginfo-install if it needs the debug packages. That must be broken too, because I've only seen it once. I did the install for that bug, but I didn't realize I'm still missing debuginfo files.

dd_wizard

GoinEasy9 · #12 11th June 2010, 04:51 AM

I had an avc denial with amarok tonight and tried to use the bugs,kde bugzilla. The KDE crash handler would not load the debuginfo's automatically either. I was able to do it manually, but at least the kde handler gave me a list of which debuginfo's were missing. If I had the free time, I would go down the list of packages that the abrt backtrace lists and try to install each one, but, I don't have that much free time, and the last bug I reported had 80 debuginfo's missing. I hate to be filing bugs that are useless to the maintainers. <sigh>

GoinEasy9 · #13 12th June 2010, 11:43 PM

I seems like whatever was preventing the debuginfo's from loading into abrt has been resolved. I was able to file the amarok avc denial bug, and unlike the other day, it found all the debuginfos.
The only problem now seems to be the rpmfusion-free-debuginfo repo:

[root@Fedora14dw32 GoinEasy9]# yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/f1/66264453bae72aa20e54f20c93ef0fa66a2960 /var/cache/abrt-di/usr/lib/debug/.build-id/f1/66264453bae72aa20e54f20c93ef0fa66a2960
Loaded plugins: auto-update-debuginfo, fastestmirror, presto, refresh-packagekit
Found 29 installed debuginfo package(s)
Loading mirror speeds from cached hostfile
fedora-debuginfo/metalink | 7.6 kB 00:00
Cannot find a valid baseurl for repo: rpmfusion-free-debuginfo

Can the debuginfo's for gedit be in an rpmfusion repo? I thought I saw a repo in fedora-rawhide called rawhide-debuginfo that I would have thought would contain these. At least info for obtaining the missing debuginfo's is coming up:

Missing separate debuginfo for /usr/lib/libgtk-x11-2.0.so.0
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/f1/66264453bae72aa20e54f20c93ef0fa66a2960 /var/cache/abrt-di/usr/lib/debug/.build-id/f1/66264453bae72aa20e54f20c93ef0fa66a2960

Will try again tomorrow and see if the rpmfusion repos are working again.

dd_wizard · #14 13th June 2010, 12:19 AM

I did a "debuginfo-install gedit" yesterday and picked up some of the missing packages. "yum whatprovides /usr/lib/libgtk-x11-2.0.so" says it's on fedora rawhide, not RPMFusion. I fired off a new abrt bug for the gedit crash on exit, hopefully the backtrace is useful this time around.

dd_wizard

GoinEasy9 · #15 13th June 2010, 12:37 AM

Well, maybe the fact that it's enabling all the debuginfo repos, and, the problems with the rpmfusion repos that's stopping abrt from collecting everything. I filed a second gedit comment after manually installing the debuginfo for gedit. It reduced the missing files from 80 to 39, hopefully, that'll be enough for them to work on.
I haven't used KDE in a while, and was pretty impressed with the KDE crash handler. When it couldn't find the information it needed, it actually told you which files were missing, and, considering that it finds the debuginfo in the same place as does abrt, it was actually able to retrieve the files today, when abrt couldn't.