Red Hat Bugzilla – Bug 139925
segfault in engine_init_default strcmp causes apache server to stop
Last modified: 2007-11-30 17:06:54 EST
When sending a SIGHUP or SIGUSR1 to the apache parent process to restart it
after logrotation has completed the apache parent (and thus all children) will
exit with a Segmentation Fault on the second time that it recieves a SIGHUP or
SIGUSR1, the first HUP/USR1 will work fine, the second though will consistently
fail. This means that everyother day the customer has to manually start apache
back up after two cycles of logrotation has completed. I was able to gather
sysreport, core files with gdb bt output and strace data from both customers and
the system I had that was doing this issue. On reviewing the strace data from
both customers and my test system the apache failed when it was parsing the
/usr/share/ssl/openssl.cnf file and the gdb outputs all indicae that the last
thing that apache was doing was the strcmp function.
[snip, see issue for more info]
I cannot reproduce this here.
Reproducible: Couldn't Reproduce
Steps to Reproduce:
1. Send SIGHUP or SIGUSR1 to the apache parent process
2. Observe that the second time, the process segfaults.
Should reinit apache
This is happening with openssl-engine-0.9.6b. In the CHANGES for the latest
version (openssl-0.9.7e), we find this under the changes from 0.9.6h->0.9.7:
*) Make sure any ENGINE control commands make local copies of string
pointers passed to them whenever necessary. Otherwise it is possible
the caller may have overwritten (or deallocated) the original string
data when a later ENGINE operation tries to use the stored values.
[GÃ¶tz Babin-Ebell <email@example.com>]
Is it possible for us to bring RHEL2.1 up to the version we're using for RHEL3
(openssl-0.9.7a-33.12)? If not then fixing this will involve a non-trivial patch.
> Is it possible for us to bring RHEL2.1 up to the version we're using for RHEL3
This is not possible at all. So only backporting the patch remains. I'll try to
investigate how big the backported patch would be.
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received the feedback we
requested, we will assume the problem was not reproduceable or has been fixed in
a later update for this product.