#22 Segmentation fault when AutoRestart used with configfile

[Anonymous]

Hello, the program exits with a ``Segmentation fault'' when AutoRestart + configfile is used. This happens regardless of whether AutoRestart y is mentioned in the configfile or it in passed as the `-A' switch on the commandline.

That is, as long as a configfile is used, I cannot use the AutoRestart function. (I tried different combinations.)

Opendkim version: 2.0.1, compiled with all default configuration options. Debian 5.0, amd64. Please tell if more information would be useful!

[Murray S. Kucherawy]

I've been using it with a configuration file for quite a long time and have no problems. That's on FreeBSD 6.2 64-bit.

Since there's a segmentation fault, you may have a core dump. Can you provide a stack trace?

(version 2.0.2 is current, by the way)

[Anonymous]

A quick update: same problem with 2.0.2.

However, when 2.0.2 is configured with --enable-debug the problem disappears! (didn't check for 2.0.1)

[Murray S. Kucherawy]

Still, the question remains: Do you have a coredump?

[Murray S. Kucherawy]

Because this bug was opened with an OpenID login rather than a SourceForge login, we're unable to contact you directly to request more information.

Please check your bugs frequently for requests for information from us, or provide direct contact information privately. If we can't get your help to solve the problem, we'll have to close the bug.

[Anonymous]

[Anonymous]

[Anonymous]

[Anonymous]

[Anonymous]

[Anonymous]

Hello, the backtrace for 2.0.2:

Core was generated by `/usr/local/sbin/opendkim -x opendkim.conf'.
Program terminated with signal 11, Segmentation fault.
[New process 578]
#0 0x00007f3d8218c8d0 in strchr () from /lib/libc.so.6
/home/niku/dkim-spf/segfault/opendkim.conf:1: Error in sourced command file:
Undefined command: "AutoRestart". Try "help".
(gdb) bt
#0 0x00007f3d8218c8d0 in strchr () from /lib/libc.so.6
#1 0x0000000000407387 in ?? ()
#2 0x00007f3d821301a6 in __libc_start_main () from /lib/libc.so.6
#3 0x0000000000404059 in ?? ()
#4 0x00007fffffffc0f8 in ?? ()
#5 0x000000000000001c in ?? ()
#6 0x0000000000000003 in ?? ()
#7 0x00007fffffffd99f in ?? ()
#8 0x00007fffffffd9b8 in ?? ()
#9 0x00007fffffffd9bb in ?? ()
#10 0x0000000000000000 in ?? ()

---
The library call trace and system call trace output for the 'good' and 'bad' programs are also attached.
---

[Anonymous]

The core dump is at:
http://sharebee.com/8716f179

I have not yet registered as a user as there is a curious line in the Terms of Use -- "Prohibited ... accessing SourceForge.net by any means other than through interfaces provided by Geeknet, unless otherwise specifically authorized by Geeknet in a separate, prior written agreement." I have recently asked sourceforge.net to explain it, I will wait until they reply.

[Anonymous]

[Murray S. Kucherawy]

Proposed patch #1

[Murray S. Kucherawy]

Try the attached patch.

[Anonymous]

Patch solves the problem.
Thanks.

[Murray S. Kucherawy]

Great, thanks for your traces! They pointed me to the problem spot. Please drop me a note directly if you'd like to receive credit in the release notes for the next release.

[Anonymous]

cm-msk wrote a patch to fix it.

[Murray S. Kucherawy]

Leaving this "open" until there's a release containing the fix.