Same result if the php sample script is empty:

$ls -la php-test.php
-rwxrwxrwx 1 boris users 0 Nov 21 12:41 php-test.php

$php php-test.php
Segmentation fault

btw it segfaults without mailparse extension too !

Please provide the script so that we can try to reproduce it.

Derick

As I wrote, i'ts segfaulting with an empty file too. Same backtrace output. Doesn't matter which content the php script has.

Playing around with some versions:

Current CVS CLI with mailparse => Segfault
Current CVS CLI w/o mailparse  => Segfault
PHP 4.2.3 w/o mailparse        => OK
PHP 4.2.3 with mailparse       => Segfault

Are you using the absolute latest version of mailparse from CVS?
I fixed some segfault related issues the other day.
Also, we *really* need a backtrace to sort this out.
When you say without mailparse, is mailparse not used in the script, or not actually compiled in?

err, somehow I didn't see the backtrace...

When I said w/o mailparse I meant a fresh compilation of php without mailparse. Only:

                --with-mysql=/usr/local/mysql \
                --with-apxs=/usr/local/apache/bin/apxs \
                --enable-ftp \
                --enable-track-vars \
                --enable-trans-sid \
                --with-gd \
                --with-pdflib \
                --with-jpeg-dir=/usr/lib \
                --with-tiff-dir=/usr/lib \
                --with-png-dir=/usr/lib \
                --with-zlib-dir=/usr/lib \
                --with-gettext \
                --with-imap \
                --enable-sockets

boris, can you strip down your configure line to ./configure 
and also update your sources ? if the segfault is gone, add one one each from you original ./configure line and try again.
trying to narrow down the problem :)

Just compiled a fresh CVS version without any ./configure arguments:

./buildconf
./configure
make
make install

running the script:
<?php
    echo "test\n";
?>

producing:

test
Segmentation fault

running gdb:

GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...
(gdb) run php-test.php
Starting program: /usr/local/bin/php php-test.php
test

Program received signal SIGSEGV, Segmentation fault.
0x080fd985 in _efree (ptr=0x819f7f4) at /tmp/php4/Zend/zend_alloc.c:229
229             REMOVE_POINTER_FROM_LIST(p);

(gdb) bt
#0  0x080fd985 in _efree (ptr=0x819f7f4) at /tmp/php4/Zend/zend_alloc.c:229
#1  0x081096e9 in _zval_dtor (zvalue=0x819f998) at /tmp/php4/Zend/zend_variables.c:44
#2  0x08102409 in free_zend_constant (c=0x819f998) at /tmp/php4/Zend/zend_constants.c:31
#3  0x0810de64 in zend_hash_destroy (ht=0x8167288) at /tmp/php4/Zend/zend_hash.c:543
#4  0x08102728 in zend_shutdown_constants () at /tmp/php4/Zend/zend_constants.c:151
#5  0x0810a11d in zend_shutdown () at /tmp/php4/Zend/zend.c:552
#6  0x080e8042 in php_module_shutdown () at /tmp/php4/main/main.c:1316
#7  0x08120797 in main (argc=2, argv=0xbffffdf4) at /tmp/php4/sapi/cli/php_cli.c:809

(gdb) bt full
#0  0x080fd985 in _efree (ptr=0x819f7f4) at /tmp/php4/Zend/zend_alloc.c:229
        ptr = (void *) 0x819f7f4
        p = (zend_mem_header *) 0x819f7e8
        cache_index = 135912072
#1  0x081096e9 in _zval_dtor (zvalue=0x819f998) at /tmp/php4/Zend/zend_variables.c:44
        zvalue = (zval *) 0x819f998
#2  0x08102409 in free_zend_constant (c=0x819f998) at /tmp/php4/Zend/zend_constants.c:31
        c = (zend_constant *) 0x819f998
#3  0x0810de64 in zend_hash_destroy (ht=0x8167288) at /tmp/php4/Zend/zend_hash.c:543
        ht = (HashTable *) 0x8167288
        p = (Bucket *) 0x81a0568
        q = (Bucket *) 0x819f968
#4  0x08102728 in zend_shutdown_constants () at /tmp/php4/Zend/zend_constants.c:151
No locals.
#5  0x0810a11d in zend_shutdown () at /tmp/php4/Zend/zend.c:552
No locals.
#6  0x080e8042 in php_module_shutdown () at /tmp/php4/main/main.c:1316
No locals.
#7  0x08120797 in main (argc=2, argv=0xbffffdf4) at /tmp/php4/sapi/cli/php_cli.c:809
        exit_status = 0
        c = 135912072
        file_handle = {type = 2 '\002', filename = 0xbffffede "php-test.php", opened_path = 0x0, handle = {fd = 135867464, fp = 0x8192c48}, free_filename = 0 '\0'}
        behavior = 1
        orig_optind = 1
        orig_optarg = 0x0
        arg_free = 0xbffffd5c ""
        script_file = 0xbffffede "php-test.php"
        global_vars = {head = 0x0, tail = 0x0, size = 4, count = 0, dtor = 0, persistent = 0 '\0', traverse_ptr = 0x816195c}
        interactive = 0
        module_started = 1
        exec_direct = 0x0
        param_error = 0x0
(gdb)

Did you compile the last test from CLEAN sources?
ie. do us all a favour and grab the latest snapshot
from snaps.php.net and try again.

If it still fails, I suspect there's something very broken
in your system. (what gcc version are you using..? )

> Did you compile the last test from CLEAN sources?

Yes, every time a new fresh CVS download. And btw. removing the download directory from the test before.

> ie. do us all a favour and grab the latest snapshot
> from snaps.php.net and try again.

I'll that today evening.

> If it still fails, I suspect there's something very broken
> in your system. (what gcc version are you using..? )

gcc version 2.95.4 (latest debian release, i guess)

It might be my system, sure - but I cannot locate a single error that points to that problem. If I'm wrong, please gimme a hint.

Today I tried snap php4-STABLE-200211261030.tar.gz. It produces the same segfault like reported above.

This can be anything from broken hardware to some file errors..but surely it's not bug in PHP since you're the only one reporting it.

he is probably not, see #20604

If it's broken hard- or software. Why the php4 apache module works perfect? The same script called by web is running w/o any error.

Well, broken sofware may cause the fault - but which software is needed by CLI SAPI and NOT by the apache module. This would help me to find a possible broken piece of software.

Because the segfault is produced neither in the apache module nor CGI and only in CLI, imho it's bug in php. Perhaps in assembly to other software packages, right.

But - "It's not PHPs fault" Isn't a good solution for me. Guess what? Shall I reinstall the complete server? I can't.

I will be very appreciated for any hints that solve my problem apart from reinstalling all the software I'm running.

Recently I set up a second linux box and repeated all. It works - but why. I updated bcc, bison, etc to the newest version on both machines. The new one is okay, the old one segfaults. Any Ideas how I can check the differences which can cause the fault ?

After a very long night I solved the problem. Don't hurt me ! The standard php make install doesn't create the php-cli.ini and if this file is missing my php-cli segfaults. If it's present - all is fine.

Is the backtrace still the same?
And do you have any other php-*.ini files anywhere in your system? If you do have, please make a diff between it and
the php.ini-dist

If I remove the php-cli.ini from my /usr/local/lib directory the backtrace is the same. And no - I do not have multiple php-*.ini files. One php.ini and a php-cli.ini ( since today morning ).

I copied the original php.ini-dist to /usr/local/lib/php-cli.ini and everything is fine. ( I will customize the file later )

Is that php.ini loaded by php then when this crash happens?

I can't tell. Is php.ini loaded if php-cli.ini doesn't exists by default ?

This crash happens when php.ini (or php-cli.ini :) contains 'session.auto_start = 1' AND 'magic_quotes_gpc = On'

Date: Thu, 28 Nov 2002 19:38:38 +0100 (CET)
From: Sascha Schumann <sascha@schumann.cx>
To: Edin Kadribasic <edink@proventum.net>
Cc: php-dev@lists.php.net
Subject: Re: [PHP-DEV] Patch for bug #20539

On Thu, 28 Nov 2002, Edin Kadribasic wrote:

> Forget the patch, its not working well. The problem is that with
> session autostart SID constant gets defined in rinit and gets
> destroyed twice.

    Yes, that's why I don't like to rely on internals of
    something which should be a black box.  The constants
    API needs an interface for deleting entries.

    - Sascha

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

The patch was reverted. Reopening until a better fix is devised.

The patch was recommitted, so the problem should be gone.
Closing...