Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

This happened for me too when compiling with ./configure --with-apxs --with-mysql --with-imap --with-imap-ssl --with-kerberos (taken from memory, I might have forgot or misspelled something).

It's actual the php cli binary that is segfaulting. A quick glance at the backtrace (sorry, I can't access it right now but you could always try to compile your version with these flags) indicated that the problem was related to the imap ssl in some way. I think there was a ssl initialize related function that died.

With imap compiled as a seperate module php didn't segfault but I never got imap to work, which might be related.


Anyways, it's not pear related rather something inside php and it seems that more than one combination of configure options result in the error, so it might be something common.

This was on a redhat 7.2 x86 machine.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

As this should work now..

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.

$ wget http://snaps.php.net/php4-STABLE-latest.tar.gz
$ tar xzf php4-STABLE-latest.tar.gz
$ cd php4-STABLE-200302261430
$ ./configure --with-apxs --with-mysql --with-imap --with-imap-ssl --with-kerberos
$ make
$ sapi/cli/php
zsh: 22462 segmentation fault  sapi/cli/php

GDB backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x4026db88 in _IO_vfprintf (s=0xbfffec70, format=0x820598f "/%s-%s.pem", ap=0xbfffed60)
    at ../sysdeps/i386/i486/bits/string.h:530
530     ../sysdeps/i386/i486/bits/string.h: No such file or directory.
        in ../sysdeps/i386/i486/bits/string.h
(gdb) bt
#0  0x4026db88 in _IO_vfprintf (s=0xbfffec70, format=0x820598f "/%s-%s.pem", ap=0xbfffed60)
    at ../sysdeps/i386/i486/bits/string.h:530
#1  0x40289e03 in _IO_vsprintf (string=0xbfffedef "/morrdusk.net-???",
    format=0x820598f "/%s-%s.pem", args=0xbfffed58) at iovsprintf.c:46
#2  0x402760b7 in sprintf (s=0xbfffedef "/morrdusk.net-???", format=0x820598f "/%s-%s.pem")
    at sprintf.c:38
#3  0x08164cdd in ssl_onceonlyinit () at osdep.c:295
#4  0x0806c0b3 in zm_startup_imap (type=1, module_number=9)
    at /home/ja/w/src/php/php4-STABLE-200302261430/ext/imap/php_imap.c:432
#5  0x081332db in zend_startup_module (module=0x820c780)
    at /home/ja/w/src/php/php4-STABLE-200302261430/Zend/zend_API.c:1008
#6  0x08109b53 in php_startup_extensions (ptr=0x821af30, count=10)
    at /home/ja/w/src/php/php4-STABLE-200302261430/main/main.c:998
#7  0x0814bdf9 in php_startup_internal_extensions () at main/internal_functions_cli.c:69
#8  0x08109f99 in php_module_startup (sf=0x821aea0, additional_modules=0x0,
    num_additional_modules=0) at /home/ja/w/src/php/php4-STABLE-200302261430/main/main.c:1164
#9  0x0814b111 in main (argc=1, argv=0xbffff504)
    at /home/ja/w/src/php/php4-STABLE-200302261430/sapi/cli/php_cli.c:481
#10 0x40232657 in __libc_start_main (main=0x814afe8 <main>, argc=1, ubp_av=0xbffff504,
    init=0x8069e34 <_init>, fini=0x81a00d0 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
    stack_end=0xbffff4fc) at ../sysdeps/generic/libc-start.c:129
(gdb)


So no, the latest snapshot doesn't seem to fix this problem.

Ok. After having a closer look at the backtrace I noticed that it comes from within the imap code. So I took a closer look at the installed imap packages and I had accidently installed the redhat 7.3 packages instead of the 7.2 packages. After downgrading to the 7.2 packages, the php cli binary isn't segfaulting anymore.

Maybe this is/was the problem for the original bug submitter too.

I am having this problem on RedHat 9, with PHP 4.3.4 and 
a feb 27 04 snapshot of php 4.x  It seems to be the 
pearcmd.php that is causing the segment fault.  Here is 
the work around that works for me.  Install PHP as you 
normally would only --without-pear, my config string:

./configure --with-apxs2=/usr/local/bin/apxs --prefix=/
usr/local --mandir=/usr/local/share/man --enable-dio --
enable-exif --with-mysql --with-zlib --with-openssl=/
usr/local/ssl --with-dom --with-gd=/usr/local --with-
mcrypt=/usr/local/ --with-pfpro=/usr/local/pfpro --
without-pear

Now, you need to install a PEAR safe, CLI only version 
of PHP to run pearcmd.php,  You want the pear dir to be 
where the fist (or live) install would have installed 
it, so for me:

./configure --prefix=/usr/local/PEAR --with-pear=/usr/
local/lib/php --enable-cli --disable-cgi --with-zlib

make and install that, may have to do a make clean 
first.

cp /usr/local/lib/php/pearcmd.php to /usr/local/bin/pear
add this to the first line of /usr/local/bin/pear:
#!/usr/local/PEAR/bin/php
chmod +x /usr/local/bin/pear

Make sure that you have the include_path on your live 
.ini set to /usr/local/lib/php

With this setup everything should work as if PEAR 
installed properly on the first install.