Can't reproduce on i386 both in Unicode and regular modes.

I just updated my cvs working copy and the error has slightly changed but is still there.

The following script causes the trouble:
<?php
$arr = explode(",", "bal,blo,ble");
?>
It's not segm fault anymore but that doesn't  make much of a difference. zend_parse_parameters() just returns bogus.
Here is a gdb session:

steinm@ibook:/tmp$ gdb  /usr/local/php5-cvs/bin/php
GNU gdb 6.4-debian
Copyright 2005 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 "powerpc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) break string.c:1099
Breakpoint 1 at 0x101fada4: file /home/cvs/php/php-src/ext/standard/string.c, line 1099.
(gdb) run -f explode.php
Starting program: /home/local/php5-cvs/bin/php -f explode.php
warning: Lowest section in /usr/lib/libicudata.so.34 is .hash at 00000094
[Thread debugging using libthread_db enabled]
[New Thread 805588960 (LWP 20645)]
[Switching to Thread 805588960 (LWP 20645)]

Breakpoint 1, zif_explode (ht=2, return_value=0x1069ca68,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
    at /home/cvs/php/php-src/ext/standard/string.c:1099
1099            if ( zend_parse_parameters(argc TSRMLS_CC, "TT|l", &delim, &delim_len, &delim_type,
(gdb) next
1104            if ( delim_len == 0 ) {
(gdb) print str
$1 = (void *) 0xb7
(gdb) print delim
$2 = (void *) 0x1040345c
(gdb) print str_len
$3 = 16
(gdb) print delim_len
$4 = 0
(gdb) print (char *) delim
$5 = 0x1040345c "/home/cvs/php/php-src/Zend/zend_vm_execute.h"

If continue the program I get a php error message because the delim string is empty.

  Uwe

Is Linux on PPC the only platform where you're able to reproduce it?

I just did a fresh build of the current cvs on powerpc and i386. The i386 works perfectly

steinm@demo:/software/cvs/php-src$ /usr/local/php5-cvs/bin/php  -r 'print_r(explode(",", "bal,blaj,alsdj"));'
Array
(
    [0] => bal
    [1] => blaj
    [2] => alsdj
)
steinm@demo:/software/cvs/php-src$

The powerpc version still crashes.

I cannot reproduce this on either x86 (BSD) or PPC (OSX).

I did a fresh check out of php-src from cvs and the problem remains. The latest stable version 5.1.2 works fine. I really don't know what else I could do.

steinm@ibook:/home/cvs/php/php-src$ gdb /usr/local/php5-cvs/bin/php
GNU gdb 6.4-debian
Copyright 2005 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 "powerpc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run -r 'explode(",", "bal,blo,ble");'
Starting program: /home/local/php5-cvs/bin/php -r 'explode(",", "bal,blo,ble");'warning: Lowest section in /usr/lib/libicudata.so.34 is .hash at 00000094
[Thread debugging using libthread_db enabled]
[New Thread 805599168 (LWP 2275)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 805599168 (LWP 2275)]
php_explode (delim=0xed4025c "", delim_len=2147213872,
    str=0x10 <Address 0x10 out of bounds>, str_len=248778548, str_type=0 '\0',
    return_value=0x10600d10, limit=-1) at zend_operators.h:215
215             char ne = needle[needle_len-1];
(gdb) bt
#0  php_explode (delim=0xed4025c "", delim_len=2147213872,
    str=0x10 <Address 0x10 out of bounds>, str_len=248778548, str_type=0 '\0',
    return_value=0x10600d10, limit=-1) at zend_operators.h:215
#1  0x1023f440 in zif_explode (ht=2, return_value=0x10600d10,
    return_value_ptr=<value optimized out>, this_ptr=<value optimized out>,
    return_value_used=<value optimized out>)
    at /home/cvs/php/php-src/ext/standard/string.c:1138
#2  0x10320944 in zend_do_fcall_common_helper_SPEC (execute_data=0x7ffbe330)
    at zend_vm_execute.h:209
#3  0x1031fd54 in execute (op_array=0x10600b90) at zend_vm_execute.h:92
#4  0x102da1a4 in zend_u_eval_string (type=<value optimized out>, string=
      {s = 0x0, u = 0x0, v = 0x0}, retval_ptr=0x0,
    string_name=<value optimized out>)
    at /home/cvs/php/php-src/Zend/zend_execute_API.c:1214
#5  0x102da43c in zend_u_eval_string_ex (type=92 '\\', str=
      {s = 0x1023f440 "K???\210\001", u = 0x1023f440, v = 0x1023f440},
    retval_ptr=0x10, string_name=0xed40f34 "", handle_exceptions=0)
    at /home/cvs/php/php-src/Zend/zend_execute_API.c:1252
#6  0x102da4ac in zend_eval_string_ex (str=<value optimized out>,
    retval_ptr=0x10, string_name=0x1023f440 "K???\210\001",
    handle_exceptions=0) at /home/cvs/php/php-src/Zend/zend_execute_API.c:1262
#7  0x103eeb4c in main (argc=3, argv=0x7ffbea94)
    at /home/cvs/php/php-src/sapi/cli/php_cli.c:1122

Please try using this CVS snapshot:

  http://snaps.php.net/php6.0-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php6.0-win32-latest.zip

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".