php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23906 Immediate segfault on startup
Submitted: 2003-05-30 13:50 UTC Modified: 2003-06-26 18:20 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:1 (50.0%)
From: mbrennen at fni dot com Assigned:
Status: No Feedback Package: IMAP related
PHP Version: 4.3.2 OS: MDK 8.2 (Linux 2.4)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mbrennen at fni dot com
New email:
PHP Version: OS:

 

 [2003-05-30 13:50 UTC] mbrennen at fni dot com
The following bug is reproduceable on two different systems.  As soon as the process starts it cores.  A gdb stack trace and the tail of an strace of the bug is below, as is the php configure script options.  The same configuration works fine with 4.3.0.


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 24937)]
0x082c1b9d in nothrow ()
(gdb) 
(gdb) bt
#0  0x082c1b9d in nothrow ()
#1  0x4000b616 in _dl_map_object_deps () at dl-deps.c:498
#2  0x00000007 in ?? ()
Cannot access memory at address 0x8


....
lstat64("/dev/null", {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
open("/dev/null", O_RDONLY)             = 3
fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE, 0xbfffd110) = -1 ENOTTY (Inappropriate ioctl for device)
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000
read(3, "", 1024)                       = 0
close(3)                                = 0
munmap(0x40016000, 4096)                = 0
lstat64("/dev/null", {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
open("/dev/null", O_RDONLY)             = 3
fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE, 0xbfffd120) = -1 ENOTTY (Inappropriate ioctl for device)
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000
read(3, "", 1024)                       = 0
close(3)                                = 0
munmap(0x40016000, 4096)                = 0
brk(0x838a000)                          = 0x838a000
brk(0x838d000)                          = 0x838d000
open("/var/log/httpd/error_log", O_WRONLY|O_APPEND|O_CREAT, 0666) = 3
fcntl64(3, F_DUPFD, 15)                 = 15
close(3)                                = 0
fcntl64(15, F_GETFL)                    = 0x401 (flags O_WRONLY|O_APPEND)
fstat64(15, {st_mode=S_IFREG|0640, st_size=2001079, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000
_llseek(15, 0, [0], SEEK_CUR)           = 0
dup2(15, 2)                             = 2
brk(0x838e000)                          = 0x838e000
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2601, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40021000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2601
brk(0x838f000)                          = 0x838f000
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x40021000, 4096)                = 0
open("/usr/share/locale/en_US/LC_CTYPE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=173408, ...}) = 0
old_mmap(NULL, 173408, PROT_READ, MAP_PRIVATE, 3, 0) = 0x409ce000
close(3)                                = 0
--- SIGSEGV (Segmentation fault) ---



### configuration script

./configure \
 --with-apache=/usr/local/apache_1.3.27 \
 --with-imap \
 --with-imap-ssl \
 --with-gd \
 --with-mysql=/usr \
 --with-solid=/usr/local/solidSDK351 \
 --with-exec-dir=/var/lib/php \
 --with-java=/usr/local/jdk \
 --enable-unified-odbc \
 --enable-safe-mode=yes \
 --enable-track-vars \
 --enable-ftp \
 --with-expat-dir=/usr \
 --with-xml \
 --with-dom=/usr \
 --with-dom-xslt=/usr \
 --with-dom-exslt=/usr \
 --enable-xslt \
 --with-xslt-sablot=/usr \
 --with-sablot-js=/usr \
 --with-zlib \
 --with-ldap \
 --with-openssl \
 --disable-debug \
 --disable-debugger \
 --with-config-file-path=/etc/httpd/conf

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-01 20:46 UTC] sniper@php.net
Try with --enable-debug and generate new GDB backtrace.
(NOT strace)

And try find out what configure option is causing this.
Remove them one by one until it works..


 [2003-06-02 12:48 UTC] mbrennen at fni dot com
With --enable-debug, gdb gives this error:

==========================================================
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 24208)] 0x082c1c1d in nothrow() (gdb) bt
#0  0x082c1c1d in nothrow ()
#1  0x4000b616 in _dl_map_object_deps () at dl-deps.c:498
#2  0x00000007 in ?? ()
Cannot access memory at address 0x8
==========================================================

On a hunch, given the dl*.c file name, I pulled out the two imap options and apache now starts / runs.

 --with-imap \
 --with-imap-ssl \
 [2003-06-02 13:26 UTC] sniper@php.net
What GDB version are you trying with..?
Also, how was the c-client configured ? 
Are you absolutely sure it's using the same openssl library
you're linking PHP with (--with-openssl) ??

 [2003-06-02 14:41 UTC] mbrennen at fni dot com
gdb version: GNU gdb 5.1.1  (via RPM on Mandrake 8.2)

IMAP is imap-2001a via RPM on Mandrake 8.2.  openssl is openssl-0.9.6c, again via RPM on Mandrake 8.2.  There is no other version of openssl on the box.

I have verified that it is the imap_ssl option; with just imap apache starts okay.

PHP 4.3.0 works fine on the same servers.  On the servers that I've done testing on so far IMAP is not actually used, so there isn't a c-client configuration per se that I am aware of.  It isn't that apache dies when using IMAP; it segfaults very quickly during startup.

Thanks, glad to help debug as needed...
 [2003-06-06 06:30 UTC] sniper@php.net
Why do you add --with-imap-ssl if the c-client is not build with SSL support? Not PHP bug.


 [2003-06-06 10:51 UTC] mbrennen at fni dot com
The c-client is built with SSL support.  There are two MDK 8.2 IMAP RPMs installed on the server.

imap-2001a-5.1mdk
imap-devel-2001a-5.1mdk

Running 'strings /usr/lib/libc-client.a' I see references to ssl_open, ssl_aopen, ssl_getline, ssl_getbuffer and other ssl functions.  There is also a libc-client-nossl.a library. It seems safe to assume that the libc-client.a I am linking against was built with SSL support.  Do you disagree?

Why did the --with-imap-ssl configuration work without problem on 4.3.0 on exactly the same server, with the same RPM set?

Is there perhaps an openssl version dependency change between 4.3.0 and 4.3.2?  The following SSL RPMs are installed.  Does 4.3.2 depend on a later version?

libopenssl0-devel-0.9.6i-1.4mdk
openssl-0.9.6i-1.4mdk
libopenssl0-0.9.6i-1.4mdk
 [2003-06-06 18:43 UTC] sniper@php.net
If it works without --with-imap-ssl, what is the problem?

 [2003-06-06 19:12 UTC] mbrennen at fni dot com
As originally stated, 4.3.0 runs with --with-imap-ssl; 4.3.2 segfaults on startup with that option, all other things being equal.  Why is that NOT a bug?

I see no reason why you keep classifying the bug as bogus.  I am very open to hearing why this is not a 4.3.2 bug, but the reason must be valid.  Your claim that IMAP was built without SSL support is not true.
 [2003-06-15 17:49 UTC] sniper@php.net
Can you please try reducing the configure options to only contain the apache and imap related options?

And also try compiling PHP as DSO.
 
 [2003-06-26 18:20 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2003-07-16 06:45 UTC] joho at webbplatsen dot se
I have a problem similar in nature, but it gets caught slightly earlier than at Apache start-up. If I enable --with-imap and/or --with-imap-ssl, the CLI binary of PHP segfaults after "Installing PEAR environment". If I remove --with-imap* from my ./configure command-line, things are hunky dory. This is on a SUSE 8.1 (2.4) machine, with the imap2001a-devel/lib RPMs from the SUSE distribution.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sun Nov 29 05:01:23 2020 UTC