Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.

(And no, we will NOT install IMP to test this)

Alright, I can do that.

<?php preg_match_all('|(\w+)://([^\s"<]*[\w+#?/&=])|', "This is a text string", $matches, PREG_SET_ORDER); ?>

That is straight out of IMP and consistantly crashes my server.  Here is the backtrace that is creates:

Program received signal SIGSEGV, Segmentation fault.
0xffffffff7bad0cf4 in zend_parse_arg_impl (arg=0x10038b528, va=0xffffffff7fffe118, spec=0xffffffff7fffe0e8)
    at /root/build/php4-STABLE-200401230430/Zend/zend_API.c:259
259                                                     *p = Z_LVAL_PP(arg);
(gdb) bt
#0  0xffffffff7bad0cf4 in zend_parse_arg_impl (arg=0x10038b528, va=0xffffffff7fffe118, spec=0xffffffff7fffe0e8)
    at /root/build/php4-STABLE-200401230430/Zend/zend_API.c:259
#1  0xffffffff7bad197c in zend_parse_arg (arg_num=4, arg=0x10038b528, va=0xffffffff7fffe118, 
    spec=0xffffffff7fffe0e8, quiet=0) at /root/build/php4-STABLE-200401230430/Zend/zend_API.c:439
#2  0xffffffff7bad1e68 in zend_parse_va_args (num_args=0, type_spec=0xffffffff7bb6b34c "ll", 
    va=0xffffffff7fffe118, flags=0) at /root/build/php4-STABLE-200401230430/Zend/zend_API.c:524
#3  0xffffffff7bad2254 in zend_parse_parameters (num_args=4, type_spec=0xffffffff7bb6b348 "ssz|ll")
    at /root/build/php4-STABLE-200401230430/Zend/zend_API.c:551
#4  0xffffffff7b94a3e4 in php_pcre_match (ht=4, return_value=0x100398fa0, this_ptr=0x0, return_value_used=0, 
    global=1) at /root/build/php4-STABLE-200401230430/ext/pcre/php_pcre.c:374
#5  0xffffffff7b94b480 in zif_preg_match_all (ht=4, return_value=0x100398fa0, this_ptr=0x0, return_value_used=0)
    at /root/build/php4-STABLE-200401230430/ext/pcre/php_pcre.c:607
#6  0xffffffff7baec798 in execute (op_array=0x100394320)
    at /root/build/php4-STABLE-200401230430/Zend/zend_execute.c:1616
#7  0xffffffff7bacfd4c in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /root/build/php4-STABLE-200401230430/Zend/zend.c:884
#8  0xffffffff7ba6faf8 in php_execute_script (primary_file=0xffffffff7fffef30)
    at /root/build/php4-STABLE-200401230430/main/main.c:1727
#9  0xffffffff7baf581c in php_handler (r=0x1003840f0)
    at /root/build/php4-STABLE-200401230430/sapi/apache2handler/sapi_apache2.c:536
#10 0x00000001000ac8a0 in ap_run_handler ()
#11 0x00000001000ad798 in ap_invoke_handler ()
#12 0x000000010007b6d0 in ap_process_request ()
#13 0x00000001000712e4 in ap_process_http_connection ()
#14 0x00000001000c55b8 in ap_run_process_connection ()
#15 0x00000001000c5c18 in ap_process_connection ()
#16 0x00000001000a8e28 in child_main ()
#17 0x00000001000a9030 in make_child ()
#18 0x00000001000a92a4 in startup_children ()
#19 0x00000001000a9da8 in ap_mpm_run ()
#20 0x00000001000b79d8 in main ()
(gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0xffffffff7bb6b530 "preg_match_all"
(gdb) frame 6
#6  0xffffffff7baec798 in execute (op_array=0x100394320)
    at /root/build/php4-STABLE-200401230430/Zend/zend_execute.c:1616
1616                                                            ((zend_internal_function *) EX(function_state).function)->handler(EX(opline)->extended_value, EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC);

PCRE is v4.5, if that's important.  You need anything else?

I can not reproduce this crash in Linux.
Try recompiling PHP without setting CFLAGS / LDFLAGs.

Solaris does not have an ld.so.conf file so the LDFLAGS are manditory in order for the final module to execute properly.

I did remove the CFLAGS, though, and it compiled and ran just fine.  I also recompiled PCRE without the CFLAGS and it also seems alright.  It's still crashes when I execute the preg_match_all, though.

I have also tried this on a Linux server and it worked just fine so it must be something unique to Solaris or Ultrasparc systems.  If someone would like an account on my server to experiment on I would be happy to give them one.

Solaris has 'LD_LIBRARY_PATH' environment variable (it's actually common to all unix variants?) in which you can put any 'exotic' library paths.

And FYI: with the configure line you provided in this bug report, you're NOT using the external PCRE library, the bundled PCRE 4.5 is used.

I tried with this configure line:

# ./configure --disable-all --enable-debug --with-pcre-regex

# uname -a
SunOS pf-i400 5.6 Generic_105181-33 sun4u sparc SUNW,Ultra-30 Solaris

And I didn't get any crash with your short script..

Well, LD_LIBRARY_PATH creates binaries that depend on it whereas -L/R flags to the linker appear to embed the information directly into the executable.  All a user has to do is break that environment variable and all of a sudden anything compiled depending on it break as well.  I prefer the method that makes it as difficult for my users to screw things up as possible. :)

Even with everything but PCRE stripped out I still get the same seg fault.Only things I can think of are that it could be a problem with gcc (a 64bit-enabled version of 3.3.2) or some change of Sun's between Solaris 2.6 (?) and 9.  Or maybe something to do with the Ultrasparc processors that I have.  I just don't know.

Any other ideas?  I'm fresh out.

Just in case it helps, here's my uname as well.

[root@lurch root]# uname -a
SunOS lurch 5.9 Generic_112233-11 sun4u sparc SUNW,Ultra-250

Regarding the LD_LIBRARY_PATH thing..PHP's configure does add the L/R switches. You don't need to do that. :)

And about the PCRE prob..try adding -DNO_RECURSE into CFLAGS. (there is no configure option for this..special thingie. :)

grep for NO_RECURSE in the pcre sources to see what it does..

Added -DNO_RECURSE to PCRE's CFLAGS and it's still no-go.  Same segfault, same gdb backtrace.  You did mean to put no_recurse into the PCRE compile and not the PHP compile, right?  Very frusterated, I managed to bypass the feature of IMP that was causing the problem so it's no longer inhibiting my progress.  (It'd still be nice to get it working, though.)

You're missing the point: PHP is NOT using your external build PCRE lib! (given your configure line you added in your report)

Try this for PHP:

# rm config.cache ; CFLAGS=-DNO_RECURSE ./configure --disable-all --disable-cgi --with-pcre-regex && make 

Then try your script with the sapi/cli/php

Actually, it is.  That configure line has been updated since I posted it.  ldd shows that the new module is indeed using the libpcre from /usr/local/lib.

I added the no_recurse to the PCRE build, though, not PHP.  That's why I asked.  I will try it in PHP and see what happens.

Adding -DNO_RECURSE to PHP's compile didn't help either.

Did you try with the configure line I gave?
(don't forget also doing 'make clean' before 'make', I forgot that from it :)

Yeah.

[root@lurch cli]# ./php < crashphp.php 
Bus Error (core dumped)

That's using:

CFLAGS=-DNO_RECURSE ./configure --disable-all --disable-cgi --with-pcre-regex

No idea what it's problem is.  I can run more gdb tests on the core dump if you want.

Is the gdb backtrace same (the first lines..) to the one you already have included here?

No, but that's probably because that configure line doesn't have the --enable-debug in it.  Let me recompile and see.

Yeah, same thing as far as I can tell.  I'll paste it again since it's a different configure and version from the original paste just in case it helps.

[root@lurch cli]# gdb ./php      
GNU gdb 5.3
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 "sparcv9-sun-solaris2"...
(gdb) run < crashphp.php
Starting program: /root/build/php4-STABLE-200401230430/sapi/cli/php < crashphp.php

Program received signal SIGSEGV, Segmentation fault.
0x000000010016e6cc in zend_parse_arg_impl (arg=0x10031aa58, va=0xffffffff7fffead8, spec=0xffffffff7fffeaa8)
    at /root/build/php4-STABLE-200401230430/Zend/zend_API.c:259
259                                                     *p = Z_LVAL_PP(arg);
(gdb) bt
#0  0x000000010016e6cc in zend_parse_arg_impl (arg=0x10031aa58, va=0xffffffff7fffead8, spec=0xffffffff7fffeaa8)
    at /root/build/php4-STABLE-200401230430/Zend/zend_API.c:259
#1  0x000000010016f4f0 in zend_parse_arg (arg_num=4, arg=0x10031aa58, va=0xffffffff7fffead8, 
    spec=0xffffffff7fffeaa8, quiet=0) at /root/build/php4-STABLE-200401230430/Zend/zend_API.c:439
#2  0x000000010016fad8 in zend_parse_va_args (num_args=0, type_spec=0x10019875c "ll", va=0xffffffff7fffead8, 
    flags=0) at /root/build/php4-STABLE-200401230430/Zend/zend_API.c:524
#3  0x000000010016fec4 in zend_parse_parameters (num_args=4, type_spec=0x100198758 "ssz|ll")
    at /root/build/php4-STABLE-200401230430/Zend/zend_API.c:551
#4  0x0000000100038168 in php_pcre_match (ht=4, return_value=0x100326fe0, this_ptr=0x0, return_value_used=0, 
    global=1) at /root/build/php4-STABLE-200401230430/ext/pcre/php_pcre.c:374
#5  0x00000001000392b0 in zif_preg_match_all (ht=4, return_value=0x100326fe0, this_ptr=0x0, return_value_used=0)
    at /root/build/php4-STABLE-200401230430/ext/pcre/php_pcre.c:607
#6  0x000000010018bdd8 in execute (op_array=0x100322570)
    at /root/build/php4-STABLE-200401230430/Zend/zend_execute.c:1616
#7  0x000000010016d518 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /root/build/php4-STABLE-200401230430/Zend/zend.c:884
#8  0x00000001001038d4 in php_execute_script (primary_file=0xffffffff7ffffa40)
    at /root/build/php4-STABLE-200401230430/main/main.c:1727
#9  0x000000010019688c in main (argc=1, argv=0xffffffff7ffffb48)
    at /root/build/php4-STABLE-200401230430/sapi/cli/php_cli.c:820
(gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0x100198940 "preg_match_all"
(gdb) frame 6
#6  0x000000010018bdd8 in execute (op_array=0x100322570)
    at /root/build/php4-STABLE-200401230430/Zend/zend_execute.c:1616
1616                                                            ((zend_internal_function *) EX(function_state).function)->handler(EX(opline)->extended_value, EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC);
(gdb)

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.

Beautiful!  It works perfectly now.  Thanks much!