Bug 715456

I already have a patch for that, but some work needs to be done before I will apply patch.

Patches which brings Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf' were reverted and it won't be shown in next release.

any ETA for the fix?  I can't get core dumps

abrt frequently causes me more problems than it solves and I'm close to uninstalling it and dealing with crashes the good old fashioned way

(In reply to comment #3)
> any ETA for the fix?  I can't get core dumps
...

This bug doesn't seem to prevent core dumps from being reported and generated:
abrt-2.0.3-1.fc15.x86_64

Do you get an alert and core dump with this test?
$ sleep 1000 &
$ kill -6 `pgrep sleep`

yes, I get an abrt notification for that, but I don't really care about getting coredumps for contrived tests like that, I want core dumps when my programs crash, and for this:


$ gcc -x c - <<< 'int main() { __builtin_abort(); }'
$ ./a.out
Aborted (core dumped)

I get this in /var/log/messages


Jul 20 18:36:49 moria abrt[24770]: Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'
Jul 20 18:36:49 moria abrtd: Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'
Jul 20 18:36:49 moria abrt[24770]: saved core dump of pid 24769 (/dev/shm/a.out) to /var/spool/abrt/ccpp-2011-07-20-18:36:49-24769.new/coredump (237568 bytes)
Jul 20 18:36:49 moria abrtd: Directory 'ccpp-2011-07-20-18:36:49-24769' creation detected
Jul 20 18:36:49 moria abrtd: Corrupted or bad dump /var/spool/abrt/ccpp-2011-07-20-18:36:49-24769 (res:2), deleting

(In reply to comment #5)
> yes, I get an abrt notification for that, but I don't really care about getting
> coredumps for contrived tests like that, I want core dumps when my programs
> crash, and for this:
> 
> 
> $ gcc -x c - <<< 'int main() { __builtin_abort(); }'
> $ ./a.out
> Aborted (core dumped)
> 
> I get this in /var/log/messages
> 
> 
> Jul 20 18:36:49 moria abrt[24770]: Unrecognized variable 'DumpLocation' in
> '/etc/abrt/abrt.conf'
> Jul 20 18:36:49 moria abrtd: Unrecognized variable 'DumpLocation' in
> '/etc/abrt/abrt.conf'
> Jul 20 18:36:49 moria abrt[24770]: saved core dump of pid 24769
> (/dev/shm/a.out) to /var/spool/abrt/ccpp-2011-07-20-18:36:49-24769.new/coredump
> (237568 bytes)
> Jul 20 18:36:49 moria abrtd: Directory 'ccpp-2011-07-20-18:36:49-24769'
> creation detected
> Jul 20 18:36:49 moria abrtd: Corrupted or bad dump
> /var/spool/abrt/ccpp-2011-07-20-18:36:49-24769 (res:2), deleting

OK, thanks.
You may need to disable the GPG check.

$ cat /etc/abrt/abrt.conf
...
OpenGPGCheck = no
...

This is a related bug:
Bug 699152 - not logged: "Package 'shotwell' isn't signed with proper key\n"

(In reply to comment #6)
...
> OK, thanks.
> You may need to disable the GPG check.
> 
> $ cat /etc/abrt/abrt.conf
> ...
> OpenGPGCheck = no
> ...
...

That didn't work.

For the test case:
> $ gcc -x c - <<< 'int main() { __builtin_abort(); }'
> $ ./a.out

ProcessUnpackaged needs to be enabled in /etc/abrt/abrt.conf:

-ProcessUnpackaged = no
+ProcessUnpackaged = yes

I encountered the same issue when Android's adb crashed. No dump was created, and /var/log/messages included "Corrupted or bad dump <>, deleting".

Changing BOTH:

-OpenGPGCheck = yes
+OpenGPGCheck = no

-ProcessUnpackaged = no
+ProcessUnpackaged = yes

solved the test case using gcc to produce a dump. Just waiting for adb to crash again to confirm a live test.

The man page for abrt.conf says that ProcessUnpackaged=no means abrt will only catch crashes in Fedora packages. I would think that means it would not touch core dumps from my packages, and not try to analyse them and not delete them either.  With ProcessUnpackaged=yes my coredumps are put somewhere under /var/spool and abrt tries to make me report them, which obviously makes no sense for my own software. This is pretty annoying for a software developer.

How do I make abrt just leave my cores the hell alone, and put them somewhere convenient like /var/core/$(id -u) -- do I have to disable abrt completely to do that?

Surely there's some way to have abrt handle Fedora packages, but not handle cores in unknown programs, *and* *not* *delete* *them* either.

(In reply to comment #9)
> 
> Surely there's some way to have abrt handle Fedora packages, but not handle
> cores in unknown programs, *and* *not* *delete* *them* either.

If I want to get coredump from a crashing program, I usually do:

$ ulimit -c unlimited

then I get core.<PID> of the crashing program in the cwd even with abrt enabled. What is your usual way to get the coredumps?

(In reply to comment #10)
> (In reply to comment #9)
> > 
> > Surely there's some way to have abrt handle Fedora packages, but not handle
> > cores in unknown programs, *and* *not* *delete* *them* either.
> 
> If I want to get coredump from a crashing program, I usually do:
> 
> $ ulimit -c unlimited
> 
> then I get core.<PID> of the crashing program in the cwd even with abrt
> enabled. What is your usual way to get the coredumps?

I always have no limit on corefile size, and get ./core.PID after editing abrt.conf as described above, but even then abrt still notifies me of a crash (i.e. it is processing non-Fedora packages)

Can we get some packages for F-15 built that fix this?

I'm going to roll an update

(In reply to comment #13)
> I'm going to roll an update

Thank you.

abrt-2.0.3-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/abrt-2.0.3-2.fc15

Just FYI, still getting this with the update:

$ rpm -qf -V /var/spool/abrt
.....UGM.    /var/run/abrt

Not sure why...

(In reply to comment #16)
> Just FYI, still getting this with the update:
> 
> $ rpm -qf -V /var/spool/abrt
> .....UGM.    /var/run/abrt
> 
> Not sure why...

I see this too even though the permissions and attributes are the same as in the spec file, maybe bug in rpm -> will check it with rpm devels.

(In reply to comment #16)
> Just FYI, still getting this with the update:
> 
> $ rpm -qf -V /var/spool/abrt
> .....UGM.    /var/run/abrt
> 
> Not sure why...

Me neither, but I'm going to investigate more deeply.

/var/run/abrt should be /run/abrt/ because of systemd

Package abrt-2.0.3-2.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing abrt-2.0.3-2.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/abrt-2.0.3-2.fc15
then log in and leave karma (feedback).

abrt-2.0.3-3.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/abrt-2.0.3-3.fc15

abrt-2.0.3-4.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/abrt-2.0.3-4.fc15

abrt-2.0.3-4.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.