ID: 27011
User updated by: ehicks at binarymagi dot com
Reported By: ehicks at binarymagi dot com
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: Solaris 9
PHP Version: 4CVS-2004-01-23
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2004-01-26 03:56:23] [EMAIL PROTECTED]
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..
------------------------------------------------------------------------
[2004-01-26 03:46:35] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[2004-01-26 02:30:47] ehicks at binarymagi dot com
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.
------------------------------------------------------------------------
[2004-01-24 23:58:56] [EMAIL PROTECTED]
I can not reproduce this crash in Linux.
Try recompiling PHP without setting CFLAGS / LDFLAGs.
------------------------------------------------------------------------
[2004-01-23 15:28:45] ehicks at binarymagi dot com
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?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/27011
--
Edit this bug report at http://bugs.php.net/?id=27011&edit=1
