Re: can't read SMFIC_BODY reply packet header: Success

From: Rolf E. Sonneveld <R.E.Sonneveld_at_sonnection.nl>
Date: Tue, 29 Nov 2011 15:21:14 +0100

Hi, Todd, Murray,

today I had a chance to execute the recipe you gave me for debugging the
opendkim core problem. Before troubleshooting I upgraded Postfix to the
most recent stable version (2.8.7). See below, inline:

On 11/25/11 4:03 PM, Todd Lyons wrote:
> On Fri, Nov 25, 2011 at 1:53 AM, Murray S. Kucherawy<msk_at_blackops.org> wrote:
>>> No, as far as I can see it didn't. I assume the name of the core would
>>> just be 'core'?
>> Linux is picky about under which conditions it will leave a core; see
>> http://linux.die.net/man/5/core. That page also tells you how it will be
>> named. The EnableCoreDumps config file item sets PR_SET_DUMPABLE with
>> prctl(), which you'll see referenced at that page in the case that you're
>> using UserID (which you are) to run as a different user.
> By default, most linux distros won't leave cores laying around. I'll
> describe how it works on a CentOS box, it should basically be the same
> for The easiest way to get a core is to:
> 1. Make sure opendkim is running. Start it temporarily if it's not.
> 2. 'ps auxww | grep [o]pendkim' and look for the full commandline that
> opendkim is being run with.
> 3. Optional: Start screen (it will just look like a bash shell unless
> you have changed the .screenrc to show some kind of status line)
> 4. Stop the opendkim daemon.
> 5. 'ulimit -c 1000000' , which will configure your shell (and only
> this shell, won't affect other apps on this box) to leave a core if
> there is a segfault.
> 6. If your opendkim runs as a user that is not root, you need to be in
> a directory that this user has write access. A good bet is to 'cd
> /tmp'

OK, changed directory to /tmp.

> 7. Run the command you saw in #2, but add -f to the commandline. That
> will tell it not to daemonize and stay in the foreground.
> 8. When it segfaults, it will say "Segfault (core dumped)" instead of
> just "Segfault".

In the 'screen' display I got neither a 'Segfault' nor a 'Segfault (core
dumped)'. Instead, all I saw was:

opendkim: dkim.c:6482: dkim_body: Assertion `dkim != ((void *)0)' failed.

But in /tmp there was a core.PID file created (great!).

> 9. The core file will be named core.XXXXX where XXXXX is the PID of
> the app that segfaulted.
> 10. 'gdb /usr/local/sbin/opendkim /tmp/core.XXXXX' is how I get into
> the debugger with that core; adjust for the location of your opendkim
> binary. Follow Murray's instructions of what to run and what output
> he wants to see when this happens.

I used gdb from within another window on the same system. Not sure
whether this makes any difference from using it from within the screen
display? Anyway, this is what I got from gdb:

# gdb /usr/local/sbin/opendkim /tmp/core.8654
GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6_0.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/sbin/opendkim...done.
[New Thread 8662]
[New Thread 8654]
[New Thread 8655]
[New Thread 8656]
Missing separate debuginfo for /usr/local/lib/libopendkim.so.5
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install
/usr/lib/debug/.build-id/ed/96134cb66417a46919ed525307f2ea35f16c59
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install
/usr/lib/debug/.build-id/e3/288ac29ed63015d8781dcf763cafadd212d6c9
Reading symbols from /usr/local/lib/libopendkim.so.5...done.
Loaded symbols for /usr/local/lib/libopendkim.so.5
Reading symbols from /lib64/libresolv.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /usr/lib64/libmilter.so.1.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libmilter.so.1.0
Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libssl.so.10
Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libcrypto.so.10
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libgssapi_krb5.so.2
Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libkrb5.so.3
Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libk5crypto.so.3
Reading symbols from /lib64/libdl.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libz.so.1
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libkrb5support.so.0
Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libkeyutils.so.1
Reading symbols from /lib64/libselinux.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libselinux.so.1
Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libnss_files.so.2
Core was generated by `/usr/local/sbin/opendkim -x /etc/opendkim.conf -P
/home/dkim/dkim.pid -f'.
Program terminated with signal 6, Aborted.
#0 0x00000030bbc329a5 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.7.el6_0.5.x86_64 keyutils-libs-1.4-1.el6.x86_64
krb5-libs-1.8.2-3.el6_0.7.x86_64 libcom_err-1.41.12-3.el6.x86_64
libselinux-2.0.94-2.el6.x86_64 openssl-1.0.0-4.el6_0.2.x86_64
sendmail-milter-8.14.4-8.el6.x86_64 zlib-1.2.3-25.el6.x86_64
(gdb) where
#0 0x00000030bbc329a5 in raise () from /lib64/libc.so.6
#1 0x00000030bbc34185 in abort () from /lib64/libc.so.6
#2 0x00000030bbc2b935 in __assert_fail () from /lib64/libc.so.6
#3 0x00007f3d31d82cdf in dkim_body (dkim=<value optimized out>,
buf=<value optimized out>, buflen=<value optimized out>) at dkim.c:6482
#4 0x0000000000409b8c in dkimf_msr_body (ctx=0x17332f0,
bodyp=0x7f3d28002840 "test\r\n", bodylen=6) at opendkim.c:4954
#5 mlfi_body (ctx=0x17332f0, bodyp=0x7f3d28002840 "test\r\n",
bodylen=6) at opendkim.c:12660
#6 0x000000395f2058c2 in mi_engine () from /usr/lib64/libmilter.so.1.0
#7 0x000000395f207818 in mi_handle_session () from
/usr/lib64/libmilter.so.1.0
#8 0x000000395f206369 in ?? () from /usr/lib64/libmilter.so.1.0
#9 0x00000030bc4077e1 in start_thread () from /lib64/libpthread.so.0
#10 0x00000030bbce18ed in clone () from /lib64/libc.so.6

Does this reveal a possible cause of the problem?

O, BTW, Selinux is enabled in permissive mode:

# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: disabled
Policy version: 24
Policy from config file: targeted

/rolf
Received on Tue Nov 29 2011 - 14:16:30 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:20:21 PST