Does it help if you disable abrt-ccpp service $ service abrt-ccpp stop ?

Thank you for the response.  Your suggestion did not appear to help

[root@iem50 ~]# chkconfig abrt-ccpp --list
abrt-ccpp      	0:off	1:off	2:off	3:on	4:off	5:on	6:off
[root@iem50 ~]# service abrt-ccpp stop
[root@iem50 ~]# ps auxw | grep abrt
root      3993  0.0  0.0 103240   804 pts/0    S+   05:43   0:00 grep abrt
root      6116  0.0  0.0 108060   752 ?        Ss   Feb05   0:01 abrt-dump-oops -d /var/spool/abrt -rwx /var/log/messages
root     15077  0.0  0.0 110168   872 ?        Ss   Feb08   0:04 /usr/sbin/abrtd

# tail /var/log/messages
Feb 11 06:12:17 iem50 kernel: mapserv.fcgi[2193]: segfault at 2701e30 ip 00000031d76352e0 sp 00007fffeadd78d0 error 4 in libc-2.12.so[31d7600000+189000]
Feb 11 06:12:23 iem50 httpd[19213]: [error] mod_fcgid: process /mesonet/www/apps/iemwebsite/cgi-bin/mapserv/mapserv.fcgi(2193) exit(lifetime expired), get unexpected signal 11

# ll /var/spool/abrt
total 4
-rw-r--r--. 1 root root  0 Aug 18 08:04 abrt-db
-rw-------. 1 root root 57 Feb 11 05:06 last-ccpp

If you don't have cores even when abrt-ccpp is disabled, then it's not problem in abrt. Is the crashing app suided? If it is then you have to allow dumping of suided applications.

1. check if abrt-ccpp is disabled 
$ cat /proc/sys/kernel/core_pattern should print just "core"
2. In case your app is suided follow this: http://www.linuxinsight.com/proc_sys_fs_suid_dumpable.html to allow dumping suided apps
3. run your app and wait for crash

Thanks again for the response.

(In reply to comment #4)
> If you don't have cores even when abrt-ccpp is disabled, then it's not
> problem in abrt. Is the crashing app suided? 

I don't believe so.  It is an apache Fast-CGI process. The binary is here:

# ls -l /usr/local/bin/mapserv 
-rwxr-xr-x. 1 root root 40459 Feb 12 09:18 /usr/local/bin/mapserv

>If it is then you have to allow
> dumping of suided applications.
> 
> 1. check if abrt-ccpp is disabled 

(service abrt-ccpp status) returns no output.

> $ cat /proc/sys/kernel/core_pattern should print just "core"

It does.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Apache changes it's uid and gid after start so it qualifies as suided. If you don't get cores even with disabled abrt then the problem is not abrt. Apache is a bit different from other processes so getting a coredump requires an additional work. This guide should work: http://passwd.org/2012/03/apache-httpd-core-dump-instructions

Thanks for the continued help.  I tried those instructions, but it does not appear to help.  I set apache's

CoreDumpDirectory /tmp

and here's the result

Feb 18 11:07:28 iem50 kernel: mapserv.fcgi[4666]: segfault at 514df00 ip 00000031d76352e0 sp 00007fff5f87d210 error 4 in libc-2.12.so[31d7600000+189000]
Feb 18 11:07:28 iem50 abrt[8311]: /mesonet/www/apps/iemwebsite/cgi-bin/mapserv//tmp fd(-1) is not a regular file with link count 1: Is a directory
Feb 18 11:07:30 iem50 abrt[8311]: Saved core dump of pid 4666 (/usr/local/bin/mapserv) to /var/spool/abrt/ccpp-2013-02-18-11:07:28-4666 (61288448 bytes)
Feb 18 11:07:30 iem50 abrtd: Directory 'ccpp-2013-02-18-11:07:28-4666' creation detected
Feb 18 11:07:30 iem50 abrtd: Executable '/usr/local/bin/mapserv' doesn't belong to any package
Feb 18 11:07:30 iem50 abrtd: 'post-create' on '/var/spool/abrt/ccpp-2013-02-18-11:07:28-4666' exited with 1
Feb 18 11:07:30 iem50 abrtd: Corrupted or bad directory /var/spool/abrt/ccpp-2013-02-18-11:07:28-4666, deleting

You have to turn off abrt and then use the hints from the guide. Or if you want to keep abrt on, you can try changing the option: "ProcessUnpackaged = no" in "/etc/abrt/abrt-action-save-package-data.conf" to "ProcessUnpackaged = yes"

Oooooo, setting "ProcessUnpackaged = yes" in /etc/abrt/abrt-action-save-package-data.conf fixed this.  

I reverted the setuid changes and cores are still being dumped correctly. 

Could the error messages logged in this situation be improved to state why abrtd is deleting the directory?

(In reply to comment #8)
> Feb 18 11:07:28 iem50 abrt[8311]:
> /mesonet/www/apps/iemwebsite/cgi-bin/mapserv//tmp fd(-1) is not a regular
> file with link count 1: Is a directory

This message is certainly badly formatted. I'll fix it.

> Feb 18 11:07:30 iem50 abrtd: Executable '/usr/local/bin/mapserv' doesn't belong to any package

I think about this version:

Executable '%s' doesn't belong to any package and ProcessUnpackaged is set to 'no'

Does it look ok?

Not sure if your question is to me, here's my two cents for what the logged message could look like

Feb 18 11:07:28 iem50 kernel: mapserv.fcgi[4666]: segfault at 514df00 ip 00000031d76352e0 sp 00007fff5f87d210 error 4 in libc-2.12.so[31d7600000+189000]
Feb 18 11:07:30 iem50 abrt[8311]: Saved core dump of pid 4666 (/usr/local/bin/mapserv) to /var/spool/abrt/ccpp-2013-02-18-11:07:28-4666 (61288448 bytes)
Feb 18 11:07:30 iem50 abrtd: Directory 'ccpp-2013-02-18-11:07:28-4666' creation detected
Feb 18 11:07:30 iem50 abrtd: Executable '/usr/local/bin/mapserv' doesn't belong to any package 
Feb 18 11:07:30 iem50 abrtd: deleting '/var/spool/abrt/ccpp-2013-02-18-11:07:28-4666' since ProcessUnpackaged is set to 'no'

thanks

Fixed in upstream HEAD:

commit 90002fc0207fb22bcf97bf728ede1dd952237eb9
Author: Denys Vlasenko <dvlasenk>
Date:   Tue Feb 26 16:17:13 2013 +0100

    Improve log messages in cccpp hook and save-package-data. See rhbz#909617

    If core file can't be opened, say so.
    Only for other cases say "it is not a regular file with link count 1".

    Properly format absolute coredump names (don't prepend current dir).

    Explain why "doesn't belong to any package" message is emitted:
    because ProcessUnpackaged isn't set.


And in rhel6 branch: commit 8b1c5e7ec1ae11018992dc347eef753bad72a542

(In reply to comment #12)
> Feb 18 11:07:30 iem50 abrtd: Executable '/usr/local/bin/mapserv' doesn't
> belong to any package 
> Feb 18 11:07:30 iem50 abrtd: deleting
> '/var/spool/abrt/ccpp-2013-02-18-11:07:28-4666' since ProcessUnpackaged is
> set to 'no'

This would be not trivial to implement: these two messages come from two different places.
1st place doesn't know that "doesn't belong to any package" condition will result in the deletion of the problem;
and the 2nd place doesn't know the exact cause why the problem directory was declared "bad and unworthy of existence".

Running

sleep 100 & sleep 1; kill -s SIGSEGV $!

two times leads to (at least seemingly) same behavior. (First time "New problem directory /var/spool/abrt/ccpp-2013-04-05-11:45:38-10529, processing" appears in /var/log/messages) changing ProcessUnpackaged does not help in this case... new crash directory is deleted, count is not updated in old one.

Example:

Apr  5 11:20:17 hostname abrtd: Directory 'ccpp-2013-04-05-11:20:17-9936' creation detected
Apr  5 11:20:17 hostname abrt[9939]: Saved core dump of pid 9936 (/bin/sleep) to /var/spool/abrt/ccpp-2013-04-05-11:20:17-9936 (327680 bytes)
Apr  5 11:20:23 hostname kernel: uhci_hcd 0000:01:00.4: Controller not stopped yet!
Apr  5 11:20:25 hostname abrtd: Sending an email...
Apr  5 11:20:25 hostname abrtd: Email was sent to: root@localhost
Apr  5 11:20:25 hostname abrtd: Duplicate: UUID
Apr  5 11:20:25 hostname abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2013-04-05-11:18:02-9686
Apr  5 11:20:25 hostname abrtd: Corrupted or bad directory '/var/spool/abrt/ccpp-2013-04-05-11:20:17-9936', deleting

Observed on RHEL 6.4, 2.6.32-358.2.1.el6.x86_64 #1 SMP, x86_64 x86_64 x86_64 GNU/Linux

# rpm -qa | grep abrt
abrt-addon-ccpp-2.0.8-15.el6.x86_64
abrt-2.0.8-15.el6.x86_64
abrt-libs-2.0.8-15.el6.x86_64
abrt-cli-2.0.8-15.el6.x86_64
spacewalk-abrt-1.10.3-1.el6.noarch
abrt-tui-2.0.8-15.el6.x86_64
abrt-addon-kerneloops-2.0.8-15.el6.x86_64
abrt-addon-python-2.0.8-15.el6.x86_64

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1586.html