#34724 [Fbk->Opn]: Unexpected output
ID: 34724 User updated by: tv at net4you dot bg Reported By: tv at net4you dot bg -Status: Feedback +Status: Open Bug Type: Strings related Operating System: Windows XP/Apache 2.0.54 PHP Version: 5.1.0RC1 New Comment: Using the latest snapshot (PHP/5.1.0RC2-dev Server) did not solve my problem. The result remain unchanged. Previous Comments: [2005-10-04 08:28:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-10-04 08:22:51] tv at net4you dot bg Description: i have problem with converting cyrillic string to lower. Sorry you need to set page encoding to Windows-1251 to see the strings. Here is a screenshot if you can`t see the screen: http://www.net4you.bg/temp/tempimg.jpg Reproduce code: --- "; //Convert the string to lower print "Result: ".(strtolower($string)).""; //Should produce "àáâãäåæçèéêëìíîïðñòóôõö÷øùüúþÿ" //Actual output "àáâãäåæçèéêëìíîïðñòóôõö×øùüúþß" print 'Expected: àáâãäåæçèéêëìíîïðñòóôõö÷øùüúþÿ'; ?> Expected result: àáâãäåæçèéêëìíîïðñòóôõö÷øùüúþÿ Actual result: -- àáâãäåæçèéêëìíîïðñòóôõö×øùüúþß -- Edit this bug report at http://bugs.php.net/?id=34724&edit=1
#34712 [Fbk->Opn]: zend.ze1_compatibility_mode = on segfault
ID: 34712
User updated by: jason at jasonjustman dot com
Reported By: jason at jasonjustman dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
-Operating System: solars 10
+Operating System: solaris 10
PHP Version: 5CVS-2005-10-03 (snap)
Assigned To: dmitry
New Comment:
http://www.jasonjustman.com/crash.phps
line 114 is what causes the segfault:
$this->_transform_actions = new
base_object_meta_transform_actions($this);
its not clean nor tight, but an example of the pattern that causes it
to crash
Previous Comments:
[2005-10-03 22:23:13] [EMAIL PROTECTED]
We really need a reproducing script. Please try come up with one.
[2005-10-03 18:02:29] jason at jasonjustman dot com
Like i said before, i can't track down the exact sequence (stacktrace
of the .php script code shows its in the 12-14th depth), and for full
debug - only after parsing about 15kloc of code.
When adding in debugging php source code in the new call (
$this->_helper = new helper($this);), it prevents the crash but in one
case a print_r($this) in the aggrevator:: scope resulted in an empty
object.
This testcase is more pseudocode of the segfault pattern than actual
instance. If you'd like I can privately attach the application source
- but again, its not an application problem - as turning off ze1_compat
doesn't cause a segfault , but is required for implicit clone.
This happens in the same spot for the 5.0.5, 5.0.6-dev and 5.0.6-latest
- even after building in seperate directories with no caching enabled.
[2005-10-03 12:13:48] [EMAIL PROTECTED]
This test case must not work at all.
$ php -d "zend.ze1_compatibility_mode=1" bug34712.php
Fatal error: Cannot use 'parent' as class name as it is reserved in
/home/dmitry/php/test/bug34712.php on line 20
Without "parent" it works fine on Linux/i386.
Try to make full rebuild.
[2005-10-03 10:29:43] jason at jasonjustman dot com
last two lines of sample code should be:
$c = new child;
$a = new aggrevator($c);
[2005-10-03 10:05:08] jason at jasonjustman dot com
Description:
segfault in solaris 10, using php-5.0.6-dev - php5-STABLE-200510030637
Program received signal SIGSEGV, Segmentation fault.
0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
181 new_obj_val = zend_objects_new(&new_object,
old_object->ce TSRMLS_CC);
(gdb) backtrace
#0 0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
#1 0xff019970 in zval_add_ref_or_clone (p=0x0) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:127
Reproduce code:
---
can't exactly pin down reproduceable code, but it seems to be something
similar to the following:
class aggrevator {
function aggrevator(&$obj) {
$this->obj = &$obj;
$this->_call();
}
function _call()
{
$this->obj->callback();
}
}
class helper {
function helper(&$obj)
{
$this->obj_ref = &$obj;
}
}
class parent { }
class child extends parent {
function callback() {
$this->_helper = new helper($this);
}
}
$c = new child;
$h = new helper($c);
Expected result:
not to crash...
Actual result:
--
f'd in the a, segfault
--
Edit this bug report at http://bugs.php.net/?id=34712&edit=1
#34725 [Opn->Fbk]: CLI segmentation faults during cleanup
ID: 34725 Updated by: [EMAIL PROTECTED] Reported By: david at tulloh dot id dot au -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Debian Linux PHP Version: 5CVS-2005-10-04 (CVS) New Comment: What was the configure line you used? Previous Comments: [2005-10-04 08:38:14] david at tulloh dot id dot au Description: Using the 5.1 branch. PHP segmentation faults at the end of running the simplest code. Reproduce code: --- (CLI) Actual result: -- hello world is printed perfectly, after the PHP program completes the segmentation fault occurs: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211463456 (LWP 25258)] 0xb7a88840 in ?? () (gdb) bt #0 0xb7a88840 in ?? () #1 0x08131730 in tsrm_shutdown () at php-cvs-5.1/TSRM/TSRM.c:180 #2 0x081f425d in main (argc=2, argv=0xbb94) at php-cvs-5.1/sapi/cli/php_cli.c:1152 -- Edit this bug report at http://bugs.php.net/?id=34725&edit=1
#34725 [NEW]: CLI segmentation faults during cleanup
From: david at tulloh dot id dot au Operating system: Debian Linux PHP version: 5CVS-2005-10-04 (CVS) PHP Bug Type: Scripting Engine problem Bug description: CLI segmentation faults during cleanup Description: Using the 5.1 branch. PHP segmentation faults at the end of running the simplest code. Reproduce code: --- (CLI) Actual result: -- hello world is printed perfectly, after the PHP program completes the segmentation fault occurs: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211463456 (LWP 25258)] 0xb7a88840 in ?? () (gdb) bt #0 0xb7a88840 in ?? () #1 0x08131730 in tsrm_shutdown () at php-cvs-5.1/TSRM/TSRM.c:180 #2 0x081f425d in main (argc=2, argv=0xbb94) at php-cvs-5.1/sapi/cli/php_cli.c:1152 -- Edit bug report at http://bugs.php.net/?id=34725&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34725&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34725&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34725&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34725&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34725&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34725&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34725&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34725&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34725&r=support Expected behavior: http://bugs.php.net/fix.php?id=34725&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34725&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34725&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34725&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34725&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34725&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34725&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34725&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34725&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34725&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34725&r=mysqlcfg
#34712 [Opn->Fbk]: zend.ze1_compatibility_mode = on segfault
ID: 34712
Updated by: [EMAIL PROTECTED]
Reported By: jason at jasonjustman dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: solars 10
PHP Version: 5CVS-2005-10-03 (snap)
Assigned To: dmitry
New Comment:
The backtraces are quite useless as long as there is no script to
reproduce them.
Previous Comments:
[2005-10-04 08:03:37] jason at jasonjustman dot com
still working on finding sample code that breaks it, but heres a
backtrace from the cli build:
#0 zend_hash_copy (target=0x11fd780, source=0x433980,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:760
#1 0x00204298 in zend_objects_clone_members (new_object=0x1646410,
new_obj_val={handle = 16395, handlers = 0x35dc08},
old_object=0x4346c0,
handle=21) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#2 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#3 0x0020423c in zval_add_ref_or_clone (p=0x11fd73c)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#4 0x001f7504 in zend_hash_copy (target=0x11fd4c8, source=0xdbad88,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:765
#5 0x00204298 in zend_objects_clone_members (new_object=0x16463c0,
new_obj_val={handle = 16394, handlers = 0x35dc08},
old_object=0x424fd8,
handle=1) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#6 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#7 0x0020423c in zval_add_ref_or_clone (p=0x11fd48c)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#8 0x001f7504 in zend_hash_copy (target=0x11fd408, source=0x433980,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:765
#9 0x00204298 in zend_objects_clone_members (new_object=0x1646370,
new_obj_val={handle = 16393, handlers = 0x35dc08},
old_object=0x4346c0,
handle=21) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#10 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#11 0x0020423c in zval_add_ref_or_clone (p=0x11fd3c4)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#12 0x001f7504 in zend_hash_copy (target=0x11fd150, source=0xdbad88,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:765
#13 0x00204298 in zend_objects_clone_members (new_object=0x1646320,
new_obj_val={handle = 16392, handlers = 0x35dc08},
old_object=0x424fd8,
handle=1) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#14 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#15 0x0020423c in zval_add_ref_or_clone (p=0x11fd114)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#16 0x001f7504 in zend_hash_copy (target=0x11fd090, source=0x433980,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:765
#17 0x00204298 in zend_objects_clone_members (new_object=0x16462d0,
new_obj_val={handle = 16391, handlers = 0x35dc08},
old_object=0x4346c0,
handle=21) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#18 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#19 0x0020423c in zval_add_ref_or_clone (p=0x11fd04c)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#20 0x001f7504 in zend_hash_copy (target=0x11fcdd8, source=0xdbad88,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:765
#21 0x00204298 in zend_objects_clone_members (new_object=0x1646280,
new_obj_val={handle = 16390, handlers = 0x35dc08},
old_object=0x424fd8,
handle=1) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#22 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#23 0x0020423c in zval_add_ref_or_clone (p=0x11fcd9c)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#24 0x001f7504 in zend_hash_copy (target=0x11fcd18, source=0x433980,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:765
#25 0x00204298 in zend_objects_clone_members (new_object=0x1646230,
new_obj_val={handle = 16389, handlers = 0x35dc08},
old_object=0x4346c0,
handle=21) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#26 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#27 0x0020423c in zval_add_ref_or_clone (p=0
#34724 [Opn->Fbk]: Unexpected output
ID: 34724 Updated by: [EMAIL PROTECTED] Reported By: tv at net4you dot bg -Status: Open +Status: Feedback Bug Type: Strings related Operating System: Windows XP/Apache 2.0.54 PHP Version: 5.1.0RC1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-10-04 08:22:51] tv at net4you dot bg Description: i have problem with converting cyrillic string to lower. Sorry you need to set page encoding to Windows-1251 to see the strings. Here is a screenshot if you can`t see the screen: http://www.net4you.bg/temp/tempimg.jpg Reproduce code: --- "; //Convert the string to lower print "Result: ".(strtolower($string)).""; //Should produce "àáâãäåæçèéêëìíîïðñòóôõö÷øùüúþÿ" //Actual output "àáâãäåæçèéêëìíîïðñòóôõö×øùüúþß" print 'Expected: àáâãäåæçèéêëìíîïðñòóôõö÷øùüúþÿ'; ?> Expected result: àáâãäåæçèéêëìíîïðñòóôõö÷øùüúþÿ Actual result: -- àáâãäåæçèéêëìíîïðñòóôõö×øùüúþß -- Edit this bug report at http://bugs.php.net/?id=34724&edit=1
#34722 [Opn->Bgs]: configure is confused by 64bit x86_64 on Fedora
ID: 34722 Updated by: [EMAIL PROTECTED] Reported By: voidvoidpointer at yahoo dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: Fedora Core 2 x86_64 PHP Version: 5.0.5 New Comment: Latest CVS (php5.1) works fine for me. You're doing something wrong. (propably not passing --with-libdir=lib64 to configure) Previous Comments: [2005-10-04 02:16:47] voidvoidpointer at yahoo dot com I brought down the snapshot and tried to run configure. The configure script failed and did not generate a Makefile. For details of exactly how it failed, please refer to my initial post. Did you tell me to try the snapshot because you knew that a change was made to the GD extension's configuration files? [2005-10-03 23:57:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-10-03 23:09:57] voidvoidpointer at yahoo dot com Description: Symptom: "configure --with-gd" fails on dual AMD Opteron x86_64 systems with Fedora Core 2 for php-4.3.11, php-4.4.0, and php-5.0.5 although it is possible to produce a working 64-bit php _without_ the GD extension. Related Bugs: Please refer to bug reports 31610, 33745, 32300. Unfortunately, those reports have been classified as "bogus" and the reports closed. Nevertheless, there is a persistent problem described in this report. The reason those reports were closed is that there wasn't enough information about the problem, but that is addressed by this report as well a possible solution. Notes: To gather data more easily, configure's first line was changed from "#! /bin/sh" to "#! /bin/sh -x", and every trial of configure was tried on a "clean slate" by running both "make clean" and "rm -f confdefs.h config.log config.nice config.cache config.status" after each trial. Facts: Directory /usr/lib64 is where libgd.so, libjpeg.so, libjpeg.a, libpng.so, and libpng.a reside, and directory /usr/include is where the header files are located. Exhibit A (constant results for php-4.3.11, php-4.4.0, and php-5.0.5): ++ echo floorf ++ tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ + ac_tr_func=HAVE_FLOORF + cat + test no = no + PHP_PNG_DIR=yes + test no = yes + test no = yes + test no '!=' no + echo 'If configure fails try --with-jpeg-dir=' If configure fails try --with-jpeg-dir= + test yes '!=' no + test -f yes/lib/libpng.so -o -f yes/lib/libpng.a + test -f /usr/local/lib/libpng.so -o -f /usr/local/lib/ libpng.a + test -f /usr/lib/libpng.so -o -f /usr/lib/libpng.a + test -z '' + echo 'configure: error: libpng.(a|so) not found.' configure: error: libpng.(a|so) not found. + exit 1 The message "error: libpng.(a|so) not found." appears in two places in the configure script. The failure seen above is at the first location. Exhibit B (results are equivalent for php-4.3.11, php -4.4.0, and php-5.0.5): ++ echo floorf ++ tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ + ac_tr_func=HAVE_FLOORF + cat + test no = no + PHP_PNG_DIR=yes + test no = yes + test no = yes + test /usr/lib64 '!=' no + test -f /usr/lib64/lib/libjpeg.so -o -f /usr/lib64/ lib/libjpeg.a + test -f /usr/local/lib/libjpeg.so -o -f /usr/local/ lib/libjpeg.a + test -f /usr/lib/libjpeg.so -o -f /usr/lib/libjpeg.a + test -z '' + echo 'configure: error: libjpeg.(a|so) not found.' configure: error: libjpeg.(a|so) not found. + exit 1 The message "error: libjpeg.(a|so) not found." appears in three places in the configure script. The failure seen above is at the second location. Analysis of failures: >From Exhibit A, the lines + PHP_PNG_DIR=yes + test yes '!=' no ensure that the test below which appears inside a for loop will always fail + test -f yes/lib/libpng.so -o -f yes/lib/libpng.a That for loop is: for i in $PHP_PNG_DIR /usr/local /usr; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a && GD_PNG_DIR=$i && break done Pathname "yes/lib/*" does not exist and is derived incorrectly. There is one other similar for loop which also incorrectly appends the suffix "lib" to "yes". >From Exhibit B, the line + test /usr/lib64 '!=' no implies that $PHP_JPEG_DIR was set to /usr/lib64, and appending the suffix "lib" to "/usr/lib64" ensures that test below which appears inside a for loop will always fail because "/usr/lib64/lib" does not exist + test -f /usr/lib64/lib/libjpeg.so -o -f /usr/lib64/ lib/libjpeg.a That for loop is: for i in $PHP_JPEG_DIR /usr/local /usr; do test -f $i/lib/libjpeg.$SHLIB_SUFFIX_NAME -o -f $i/lib/libjpeg.a && GD_JPEG_DIR=$i && break done There are two other for loops
#34724 [NEW]: Unexpected output
From: tv at net4you dot bg Operating system: Windows XP/Apache 2.0.54 PHP version: 5.1.0RC1 PHP Bug Type: Strings related Bug description: Unexpected output Description: i have problem with converting cyrillic string to lower. Sorry you need to set page encoding to Windows-1251 to see the strings. Here is a screenshot if you can`t see the screen: http://www.net4you.bg/temp/tempimg.jpg Reproduce code: --- "; //Convert the string to lower print "Result: ".(strtolower($string)).""; //Should produce "àáâãäåæçèéêëìíîïðñòóôõö÷øùüúþÿ" //Actual output "àáâãäåæçèéêëìíîïðñòóôõö×øùüúþß" print 'Expected: àáâãäåæçèéêëìíîïðñòóôõö÷øùüúþÿ'; ?> Expected result: àáâãäåæçèéêëìíîïðñòóôõö÷øùüúþÿ Actual result: -- àáâãäåæçèéêëìíîïðñòóôõö×øùüúþß -- Edit bug report at http://bugs.php.net/?id=34724&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34724&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34724&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34724&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34724&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34724&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34724&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34724&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34724&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34724&r=support Expected behavior: http://bugs.php.net/fix.php?id=34724&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34724&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34724&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34724&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34724&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34724&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34724&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34724&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34724&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34724&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34724&r=mysqlcfg
#34712 [Fbk->Opn]: zend.ze1_compatibility_mode = on segfault
ID: 34712
User updated by: jason at jasonjustman dot com
Reported By: jason at jasonjustman dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: solars 10
PHP Version: 5CVS-2005-10-03 (snap)
Assigned To: dmitry
New Comment:
still working on finding sample code that breaks it, but heres a
backtrace from the cli build:
#0 zend_hash_copy (target=0x11fd780, source=0x433980,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:760
#1 0x00204298 in zend_objects_clone_members (new_object=0x1646410,
new_obj_val={handle = 16395, handlers = 0x35dc08},
old_object=0x4346c0,
handle=21) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#2 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#3 0x0020423c in zval_add_ref_or_clone (p=0x11fd73c)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#4 0x001f7504 in zend_hash_copy (target=0x11fd4c8, source=0xdbad88,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:765
#5 0x00204298 in zend_objects_clone_members (new_object=0x16463c0,
new_obj_val={handle = 16394, handlers = 0x35dc08},
old_object=0x424fd8,
handle=1) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#6 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#7 0x0020423c in zval_add_ref_or_clone (p=0x11fd48c)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#8 0x001f7504 in zend_hash_copy (target=0x11fd408, source=0x433980,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:765
#9 0x00204298 in zend_objects_clone_members (new_object=0x1646370,
new_obj_val={handle = 16393, handlers = 0x35dc08},
old_object=0x4346c0,
handle=21) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#10 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#11 0x0020423c in zval_add_ref_or_clone (p=0x11fd3c4)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#12 0x001f7504 in zend_hash_copy (target=0x11fd150, source=0xdbad88,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:765
#13 0x00204298 in zend_objects_clone_members (new_object=0x1646320,
new_obj_val={handle = 16392, handlers = 0x35dc08},
old_object=0x424fd8,
handle=1) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#14 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#15 0x0020423c in zval_add_ref_or_clone (p=0x11fd114)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#16 0x001f7504 in zend_hash_copy (target=0x11fd090, source=0x433980,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:765
#17 0x00204298 in zend_objects_clone_members (new_object=0x16462d0,
new_obj_val={handle = 16391, handlers = 0x35dc08},
old_object=0x4346c0,
handle=21) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#18 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#19 0x0020423c in zval_add_ref_or_clone (p=0x11fd04c)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#20 0x001f7504 in zend_hash_copy (target=0x11fcdd8, source=0xdbad88,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:765
#21 0x00204298 in zend_objects_clone_members (new_object=0x1646280,
new_obj_val={handle = 16390, handlers = 0x35dc08},
old_object=0x424fd8,
handle=1) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#22 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#23 0x0020423c in zval_add_ref_or_clone (p=0x11fcd9c)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#24 0x001f7504 in zend_hash_copy (target=0x11fcd18, source=0x433980,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-200510030630/Zend/zend_hash.c:765
#25 0x00204298 in zend_objects_clone_members (new_object=0x1646230,
new_obj_val={handle = 16389, handlers = 0x35dc08},
old_object=0x4346c0,
handle=21) at
/export/apache/php5-200510030630/Zend/zend_objects.c:141
#26 0x002043e8 in zend_objects_clone_obj (zobject=0x8)
at /export/apache/php5-200510030630/Zend/zend_objects.c:172
#27 0x0020423c in zval_add_ref_or_clone (p=0x11fccd4)
at /export/apache/php5-200510030630/Zend/zend_objects.c:129
#28 0x001f7504 in zend_hash_copy (target=0x11fca60, source=0xdbad88,
pCopyConstructor=0x204180 , tmp=0x0,
size=4)
at /export/apache/php5-
#34358 [Asn]: Fatal error: Cannot re-assign $this
ID: 34358
User updated by: pacha dot shevaev at gmail dot com
Reported By: pacha dot shevaev at gmail dot com
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.*
Assigned To: dmitry
New Comment:
Guys your notes about possible misuse($ref =& $this;$ref = 'foo') are
totally valid but is soo much difficult to spot this situation
_when_it_actually_happens_?
I'm by no means going to use this ref improperly but simply want BC
with PHP4...
Previous Comments:
[2005-10-03 12:42:48] [EMAIL PROTECTED]
I'm reopening this so that we can discuss it. I don't think we should
be silently ignoring references as that's something vague. See mail to
internals@ in a bit.
[2005-10-03 12:14:59] [EMAIL PROTECTED]
So for the curious who are wondering what "fixed" means. The & is
simply ignored in this case now.
[2005-10-03 10:22:47] [EMAIL PROTECTED]
Fixed in CVS HEAD and PHP_5_1.
[2005-10-03 09:40:14] [EMAIL PROTECTED]
It has everything to do with the new object model. Take this code:
$x = &$this;
$x = 'foo';
For performance reasons we need to catch such references when they
happen in order to prevent the object being overwritten inside itself.
It would be a bit less confusing if the error happened on the actual
assignment, but in this new object model there $x = &$this; is just as
wrong as $this = &$x since the only purpose one could have for making a
reference to $this itself is if you wanted to change it directly. In
all valid cases this should be $x = $this.
I suppose an option would be to ignore the reference in this case and
continue on. That seems to be happening with that last indirect case
you posted, but it would cost us a lookup.
[2005-09-15 15:32:13] pacha dot shevaev at gmail dot com
And why does the following code work then???
ref =& $this;
$this->ref->test();
}
function test() {
echo 'test';
}
}
$foo = new Foo();
?>
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/34358
--
Edit this bug report at http://bugs.php.net/?id=34358&edit=1
#33850 [Asn]: [PATCH]: Support LDAP connection timeouts
ID: 33850 User updated by: simon dot kissane at mq dot edu dot au -Summary: [PATCH]: Support LDAP_X_OPT_CONNECT_TIMEOUT -Reported By: skissane at gmail dot com +Reported By: simon dot kissane at mq dot edu dot au Status: Assigned Bug Type: Feature/Change Request Operating System: * PHP Version: 5CVS, 4CVS (2005-07-27) Assigned To: sniper New Comment: I have written a new version of this patch. This supports, as well of Netscape's LDAP_X_OPT_CONNECT_TIMEOUT, OpenLDAP's LDAP_OPT_TIMEOUT & LDAP_OPT_NETWORK_TIMEOUT. Note that these take a struct timeval, whereas Netscape takes an integer. I have chosen to represent struct timeval as an object with two properties (tv_sec & tv_usec, corresponding to the struct timeval fields of the same name.) New version of patch (against 5.0.5) is available here: http://www.mq.edu.au/~skissane/ldap-timeout-5.0.5.patch Previous Comments: [2005-07-25 08:55:10] simon dot kissane at mq dot edu dot au Description: I have written a patch to support LDAP_X_OPT_CONNECT_TIMEOUT (which is defined by the Netscape LDAP C SDK). This required also changing ldap_connect to call ldap_init instead of ldap_open (but only if LDAP_X_OPT_CONNECT_TIMEOUT is defined), which is necessary if LDAP_X_OPT_CONNECT_TIMEOUT is to do anything. In any case, ldap_open is deprecated, so PHP shouldn't be calling it unless necessary. Reproduce code: --- http://www.mq.edu.au/~skissane/ldap-nsldap-timeout.patch Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/?id=33850&edit=1
#34723 [NEW]: array_count_values() strips leading zeroes
From: gimmelol at netcourrier dot com
Operating system: WinXP
PHP version: 5.1.0RC1
PHP Bug Type: Arrays related
Bug description: array_count_values() strips leading zeroes
Description:
This bug has already been reported and marked bogus here:
http://bugs.php.net/bug.php?id=33279
but it is still reproducible in 5.1RC1 and recent snapshots
Reproduce code:
---
Expected result:
array(1) {
["012345"]=>
int(1)
}
Actual result:
--
array(1) {
[12345]=>
int(1)
}
--
Edit bug report at http://bugs.php.net/?id=34723&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34723&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34723&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34723&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34723&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34723&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34723&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34723&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34723&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34723&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34723&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34723&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34723&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34723&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34723&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34723&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34723&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34723&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34723&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34723&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34723&r=mysqlcfg
#34722 [Fbk->Opn]: configure is confused by 64bit x86_64 on Fedora
ID: 34722 User updated by: voidvoidpointer at yahoo dot com Reported By: voidvoidpointer at yahoo dot com -Status: Feedback +Status: Open Bug Type: GD related Operating System: Fedora Core 2 x86_64 PHP Version: 5.0.5 New Comment: I brought down the snapshot and tried to run configure. The configure script failed and did not generate a Makefile. For details of exactly how it failed, please refer to my initial post. Did you tell me to try the snapshot because you knew that a change was made to the GD extension's configuration files? Previous Comments: [2005-10-03 23:57:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-10-03 23:09:57] voidvoidpointer at yahoo dot com Description: Symptom: "configure --with-gd" fails on dual AMD Opteron x86_64 systems with Fedora Core 2 for php-4.3.11, php-4.4.0, and php-5.0.5 although it is possible to produce a working 64-bit php _without_ the GD extension. Related Bugs: Please refer to bug reports 31610, 33745, 32300. Unfortunately, those reports have been classified as "bogus" and the reports closed. Nevertheless, there is a persistent problem described in this report. The reason those reports were closed is that there wasn't enough information about the problem, but that is addressed by this report as well a possible solution. Notes: To gather data more easily, configure's first line was changed from "#! /bin/sh" to "#! /bin/sh -x", and every trial of configure was tried on a "clean slate" by running both "make clean" and "rm -f confdefs.h config.log config.nice config.cache config.status" after each trial. Facts: Directory /usr/lib64 is where libgd.so, libjpeg.so, libjpeg.a, libpng.so, and libpng.a reside, and directory /usr/include is where the header files are located. Exhibit A (constant results for php-4.3.11, php-4.4.0, and php-5.0.5): ++ echo floorf ++ tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ + ac_tr_func=HAVE_FLOORF + cat + test no = no + PHP_PNG_DIR=yes + test no = yes + test no = yes + test no '!=' no + echo 'If configure fails try --with-jpeg-dir=' If configure fails try --with-jpeg-dir= + test yes '!=' no + test -f yes/lib/libpng.so -o -f yes/lib/libpng.a + test -f /usr/local/lib/libpng.so -o -f /usr/local/lib/ libpng.a + test -f /usr/lib/libpng.so -o -f /usr/lib/libpng.a + test -z '' + echo 'configure: error: libpng.(a|so) not found.' configure: error: libpng.(a|so) not found. + exit 1 The message "error: libpng.(a|so) not found." appears in two places in the configure script. The failure seen above is at the first location. Exhibit B (results are equivalent for php-4.3.11, php -4.4.0, and php-5.0.5): ++ echo floorf ++ tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ + ac_tr_func=HAVE_FLOORF + cat + test no = no + PHP_PNG_DIR=yes + test no = yes + test no = yes + test /usr/lib64 '!=' no + test -f /usr/lib64/lib/libjpeg.so -o -f /usr/lib64/ lib/libjpeg.a + test -f /usr/local/lib/libjpeg.so -o -f /usr/local/ lib/libjpeg.a + test -f /usr/lib/libjpeg.so -o -f /usr/lib/libjpeg.a + test -z '' + echo 'configure: error: libjpeg.(a|so) not found.' configure: error: libjpeg.(a|so) not found. + exit 1 The message "error: libjpeg.(a|so) not found." appears in three places in the configure script. The failure seen above is at the second location. Analysis of failures: >From Exhibit A, the lines + PHP_PNG_DIR=yes + test yes '!=' no ensure that the test below which appears inside a for loop will always fail + test -f yes/lib/libpng.so -o -f yes/lib/libpng.a That for loop is: for i in $PHP_PNG_DIR /usr/local /usr; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a && GD_PNG_DIR=$i && break done Pathname "yes/lib/*" does not exist and is derived incorrectly. There is one other similar for loop which also incorrectly appends the suffix "lib" to "yes". >From Exhibit B, the line + test /usr/lib64 '!=' no implies that $PHP_JPEG_DIR was set to /usr/lib64, and appending the suffix "lib" to "/usr/lib64" ensures that test below which appears inside a for loop will always fail because "/usr/lib64/lib" does not exist + test -f /usr/lib64/lib/libjpeg.so -o -f /usr/lib64/ lib/libjpeg.a That for loop is: for i in $PHP_JPEG_DIR /usr/local /usr; do test -f $i/lib/libjpeg.$SHLIB_SUFFIX_NAME -o -f $i/lib/libjpeg.a && GD_JPEG_DIR=$i && break done There are two other for loops which also incorrectly append the suffix "lib" to "/usr/lib64". Of course, the line + PHP_PNG_DIR=yes implies that the option --with-png-dir should be appended to those that were used to run Exhibit B, but when that is done, configure
#34722 [Opn->Fbk]: configure is confused by 64bit x86_64 on Fedora
ID: 34722 Updated by: [EMAIL PROTECTED] Reported By: voidvoidpointer at yahoo dot com -Status: Open +Status: Feedback Bug Type: GD related Operating System: Fedora Core 2 x86_64 PHP Version: 5.0.5 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-10-03 23:09:57] voidvoidpointer at yahoo dot com Description: Symptom: "configure --with-gd" fails on dual AMD Opteron x86_64 systems with Fedora Core 2 for php-4.3.11, php-4.4.0, and php-5.0.5 although it is possible to produce a working 64-bit php _without_ the GD extension. Related Bugs: Please refer to bug reports 31610, 33745, 32300. Unfortunately, those reports have been classified as "bogus" and the reports closed. Nevertheless, there is a persistent problem described in this report. The reason those reports were closed is that there wasn't enough information about the problem, but that is addressed by this report as well a possible solution. Notes: To gather data more easily, configure's first line was changed from "#! /bin/sh" to "#! /bin/sh -x", and every trial of configure was tried on a "clean slate" by running both "make clean" and "rm -f confdefs.h config.log config.nice config.cache config.status" after each trial. Facts: Directory /usr/lib64 is where libgd.so, libjpeg.so, libjpeg.a, libpng.so, and libpng.a reside, and directory /usr/include is where the header files are located. Exhibit A (constant results for php-4.3.11, php-4.4.0, and php-5.0.5): ++ echo floorf ++ tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ + ac_tr_func=HAVE_FLOORF + cat + test no = no + PHP_PNG_DIR=yes + test no = yes + test no = yes + test no '!=' no + echo 'If configure fails try --with-jpeg-dir=' If configure fails try --with-jpeg-dir= + test yes '!=' no + test -f yes/lib/libpng.so -o -f yes/lib/libpng.a + test -f /usr/local/lib/libpng.so -o -f /usr/local/lib/ libpng.a + test -f /usr/lib/libpng.so -o -f /usr/lib/libpng.a + test -z '' + echo 'configure: error: libpng.(a|so) not found.' configure: error: libpng.(a|so) not found. + exit 1 The message "error: libpng.(a|so) not found." appears in two places in the configure script. The failure seen above is at the first location. Exhibit B (results are equivalent for php-4.3.11, php -4.4.0, and php-5.0.5): ++ echo floorf ++ tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ + ac_tr_func=HAVE_FLOORF + cat + test no = no + PHP_PNG_DIR=yes + test no = yes + test no = yes + test /usr/lib64 '!=' no + test -f /usr/lib64/lib/libjpeg.so -o -f /usr/lib64/ lib/libjpeg.a + test -f /usr/local/lib/libjpeg.so -o -f /usr/local/ lib/libjpeg.a + test -f /usr/lib/libjpeg.so -o -f /usr/lib/libjpeg.a + test -z '' + echo 'configure: error: libjpeg.(a|so) not found.' configure: error: libjpeg.(a|so) not found. + exit 1 The message "error: libjpeg.(a|so) not found." appears in three places in the configure script. The failure seen above is at the second location. Analysis of failures: >From Exhibit A, the lines + PHP_PNG_DIR=yes + test yes '!=' no ensure that the test below which appears inside a for loop will always fail + test -f yes/lib/libpng.so -o -f yes/lib/libpng.a That for loop is: for i in $PHP_PNG_DIR /usr/local /usr; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a && GD_PNG_DIR=$i && break done Pathname "yes/lib/*" does not exist and is derived incorrectly. There is one other similar for loop which also incorrectly appends the suffix "lib" to "yes". >From Exhibit B, the line + test /usr/lib64 '!=' no implies that $PHP_JPEG_DIR was set to /usr/lib64, and appending the suffix "lib" to "/usr/lib64" ensures that test below which appears inside a for loop will always fail because "/usr/lib64/lib" does not exist + test -f /usr/lib64/lib/libjpeg.so -o -f /usr/lib64/ lib/libjpeg.a That for loop is: for i in $PHP_JPEG_DIR /usr/local /usr; do test -f $i/lib/libjpeg.$SHLIB_SUFFIX_NAME -o -f $i/lib/libjpeg.a && GD_JPEG_DIR=$i && break done There are two other for loops which also incorrectly append the suffix "lib" to "/usr/lib64". Of course, the line + PHP_PNG_DIR=yes implies that the option --with-png-dir should be appended to those that were used to run Exhibit B, but when that is done, configure still fails, and the outputs are equivalent. Exhibit C (a possible solution to the problem): After removing those "lib" suffixes from configure, a few more iterations: ./configure --libdir=/usr/lib64 --with-gd --with-jpeg- dir=/usr/lib64 --with-png-dir=/usr/lib64 yields the following + LDFLAGS= -Wl,-rpath,/usr/lib64/lib + LDFLAGS= -Wl,-rpath,/usr/lib64/lib -L/usr/lib64/lib + PHP_RPATHS= /usr/lib64/lib + LIBS=-ljpeg -lresolv -lm -ldl
#34720 [Bgs]: Problem when a parenthesised sub exp matches >= 4999996 chars
ID: 34720
User updated by: nuitari at nuitari dot net
Reported By: nuitari at nuitari dot net
Status: Bogus
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5.0.5
New Comment:
Would it be possible to document this in the pcre functions manual ?
Previous Comments:
[2005-10-03 22:10:21] [EMAIL PROTECTED]
This is a PCRE limitation,
See bug #34695 for detailed explanation.
[2005-10-03 21:39:09] nuitari at nuitari dot net
Description:
If a paranthesised sub expression matches more then ~496 chars, no
data will be inserted into the &matches array.
Reducing by 1 the number in str_repeat will cause the script to work.
I have tested this with PHP 4.4.0-gentoo-amd64, 5.0.4-FC4, and
5.0.5-gentoo and all exhebit the same problems.
The configure line is different on all platforms. php.ini is the
default. On the FC4 test there is a 512Mb memory limit.
Reproduce code:
---
';
$xml_clean .= str_repeat('a',496);
$xml_clean .= '';
$ret = preg_match("/(<([\w]+)[^>]*>)(.*?)(<\/\\2>)/s", $xml_clean,
$match);
print_r($match);
?>
Expected result:
Array
(
[0] => aaa(...)aaa
[1] =>
[2] => data
[3] => aaa(...)aaa
[4] =>
)
Actual result:
--
Array
(
)
--
Edit this bug report at http://bugs.php.net/?id=34720&edit=1
#34722 [NEW]: configure is confused by 64bit x86_64 on Fedora
From: voidvoidpointer at yahoo dot com Operating system: Fedora Core 2 x86_64 PHP version: 5.0.5 PHP Bug Type: GD related Bug description: configure is confused by 64bit x86_64 on Fedora Description: Symptom: "configure --with-gd" fails on dual AMD Opteron x86_64 systems with Fedora Core 2 for php-4.3.11, php-4.4.0, and php-5.0.5 although it is possible to produce a working 64-bit php _without_ the GD extension. Related Bugs: Please refer to bug reports 31610, 33745, 32300. Unfortunately, those reports have been classified as "bogus" and the reports closed. Nevertheless, there is a persistent problem described in this report. The reason those reports were closed is that there wasn't enough information about the problem, but that is addressed by this report as well a possible solution. Notes: To gather data more easily, configure's first line was changed from "#! /bin/sh" to "#! /bin/sh -x", and every trial of configure was tried on a "clean slate" by running both "make clean" and "rm -f confdefs.h config.log config.nice config.cache config.status" after each trial. Facts: Directory /usr/lib64 is where libgd.so, libjpeg.so, libjpeg.a, libpng.so, and libpng.a reside, and directory /usr/include is where the header files are located. Exhibit A (constant results for php-4.3.11, php-4.4.0, and php-5.0.5): ++ echo floorf ++ tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ + ac_tr_func=HAVE_FLOORF + cat + test no = no + PHP_PNG_DIR=yes + test no = yes + test no = yes + test no '!=' no + echo 'If configure fails try --with-jpeg-dir=' If configure fails try --with-jpeg-dir= + test yes '!=' no + test -f yes/lib/libpng.so -o -f yes/lib/libpng.a + test -f /usr/local/lib/libpng.so -o -f /usr/local/lib/ libpng.a + test -f /usr/lib/libpng.so -o -f /usr/lib/libpng.a + test -z '' + echo 'configure: error: libpng.(a|so) not found.' configure: error: libpng.(a|so) not found. + exit 1 The message "error: libpng.(a|so) not found." appears in two places in the configure script. The failure seen above is at the first location. Exhibit B (results are equivalent for php-4.3.11, php -4.4.0, and php-5.0.5): ++ echo floorf ++ tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ + ac_tr_func=HAVE_FLOORF + cat + test no = no + PHP_PNG_DIR=yes + test no = yes + test no = yes + test /usr/lib64 '!=' no + test -f /usr/lib64/lib/libjpeg.so -o -f /usr/lib64/ lib/libjpeg.a + test -f /usr/local/lib/libjpeg.so -o -f /usr/local/ lib/libjpeg.a + test -f /usr/lib/libjpeg.so -o -f /usr/lib/libjpeg.a + test -z '' + echo 'configure: error: libjpeg.(a|so) not found.' configure: error: libjpeg.(a|so) not found. + exit 1 The message "error: libjpeg.(a|so) not found." appears in three places in the configure script. The failure seen above is at the second location. Analysis of failures: >From Exhibit A, the lines + PHP_PNG_DIR=yes + test yes '!=' no ensure that the test below which appears inside a for loop will always fail + test -f yes/lib/libpng.so -o -f yes/lib/libpng.a That for loop is: for i in $PHP_PNG_DIR /usr/local /usr; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a && GD_PNG_DIR=$i && break done Pathname "yes/lib/*" does not exist and is derived incorrectly. There is one other similar for loop which also incorrectly appends the suffix "lib" to "yes". >From Exhibit B, the line + test /usr/lib64 '!=' no implies that $PHP_JPEG_DIR was set to /usr/lib64, and appending the suffix "lib" to "/usr/lib64" ensures that test below which appears inside a for loop will always fail because "/usr/lib64/lib" does not exist + test -f /usr/lib64/lib/libjpeg.so -o -f /usr/lib64/ lib/libjpeg.a That for loop is: for i in $PHP_JPEG_DIR /usr/local /usr; do test -f $i/lib/libjpeg.$SHLIB_SUFFIX_NAME -o -f $i/lib/libjpeg.a && GD_JPEG_DIR=$i && break done There are two other for loops which also incorrectly append the suffix "lib" to "/usr/lib64". Of course, the line + PHP_PNG_DIR=yes implies that the option --with-png-dir should be appended to those that were used to run Exhibit B, but when that is done, configure still fails, and the outputs are equivalent. Exhibit C (a possible solution to the problem): After removing those "lib" suffixes from configure, a few more iterations: ./configure --libdir=/usr/lib64 --with-gd --with-jpeg- dir=/usr/lib64 --with-png-dir=/usr/lib64 yields the following + LDFLAGS= -Wl,-rpath,/usr/lib64/lib + LDFLAGS= -Wl,-rpath,/usr/lib64/lib -L/usr/lib64/lib + PHP_RPATHS= /usr/lib64/lib + LIBS=-ljpeg -lresolv -lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm + test /usr/lib64 '!=' no + test -f /usr/lib64/libpng.so -o -f /usr/lib64/libpng.a + GD_PNG_DIR=/usr/lib64 + break + test -z /usr/lib64 + test no = no + echo 'configure: error: PNG support requires ZLIB. Use --with-zlib-dir=' configure: error: PNG support requires ZLIB. Use --with- zlib-dir= + exit 1 and ./configure --libdi
#34712 [Opn->Fbk]: zend.ze1_compatibility_mode = on segfault
ID: 34712 Updated by: [EMAIL PROTECTED] Reported By: jason at jasonjustman dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: solars 10 PHP Version: 5CVS-2005-10-03 (snap) Assigned To: dmitry New Comment: We really need a reproducing script. Please try come up with one. Previous Comments: [2005-10-03 18:02:29] jason at jasonjustman dot com Like i said before, i can't track down the exact sequence (stacktrace of the .php script code shows its in the 12-14th depth), and for full debug - only after parsing about 15kloc of code. When adding in debugging php source code in the new call ( $this->_helper = new helper($this);), it prevents the crash but in one case a print_r($this) in the aggrevator:: scope resulted in an empty object. This testcase is more pseudocode of the segfault pattern than actual instance. If you'd like I can privately attach the application source - but again, its not an application problem - as turning off ze1_compat doesn't cause a segfault , but is required for implicit clone. This happens in the same spot for the 5.0.5, 5.0.6-dev and 5.0.6-latest - even after building in seperate directories with no caching enabled. [2005-10-03 12:13:48] [EMAIL PROTECTED] This test case must not work at all. $ php -d "zend.ze1_compatibility_mode=1" bug34712.php Fatal error: Cannot use 'parent' as class name as it is reserved in /home/dmitry/php/test/bug34712.php on line 20 Without "parent" it works fine on Linux/i386. Try to make full rebuild. [2005-10-03 11:24:37] [EMAIL PROTECTED] Dmitry, you did something related to this lately? [2005-10-03 10:29:43] jason at jasonjustman dot com last two lines of sample code should be: $c = new child; $a = new aggrevator($c); [2005-10-03 10:26:29] jason at jasonjustman dot com still present: (gdb) n Single stepping until exit from function child_main, which has no line number information. Program received signal SIGSEGV, Segmentation fault. 0xfef36f20 in zend_objects_clone_obj (zobject=0xff3fffc8) at /export/apache/php5-200510030630/Zend/zend_objects.c:167 167 new_obj_val = zend_objects_new(&new_object, old_object->ce TSRMLS_CC); (gdb) backtrace #0 0xfef36f20 in zend_objects_clone_obj (zobject=0xff3fffc8) at /export/apache/php5-200510030630/Zend/zend_objects.c:167 #1 0xfef36de0 in zval_add_ref_or_clone (p=0x0) at /export/apache/php5-200510030630/Zend/zend_objects.c:129 sniped 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/34712 -- Edit this bug report at http://bugs.php.net/?id=34712&edit=1
#34721 [Opn->Fbk]: fpassthru() or readfile() returns invalid data
ID: 34721 Updated by: [EMAIL PROTECTED] Reported By: cpriest at warpmail dot net -Status: Open +Status: Feedback Bug Type: Output Control Operating System: Redhat Enterprise 4 PHP Version: 5.0.5 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Previous Comments: [2005-10-03 22:04:15] cpriest at warpmail dot net Description: Calling fpassthru() or readfile() on a file returns a truncated file, using: echo file_get_contents(); and it works fine. I'm assuming its a binary issue, I know it has problems with pdf documents. Reproduce code: --- readfile($filepath); // Returns unreadable pdf file Expected result: Uncorrupted file returned to browser Actual result: -- Corrupted file returned to browser -- Edit this bug report at http://bugs.php.net/?id=34721&edit=1
#34720 [Opn->Bgs]: Problem when a parenthesised sub exp matches >= 4999996 chars
ID: 34720
Updated by: [EMAIL PROTECTED]
Reported By: nuitari at nuitari dot net
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5.0.5
New Comment:
This is a PCRE limitation,
See bug #34695 for detailed explanation.
Previous Comments:
[2005-10-03 21:39:09] nuitari at nuitari dot net
Description:
If a paranthesised sub expression matches more then ~496 chars, no
data will be inserted into the &matches array.
Reducing by 1 the number in str_repeat will cause the script to work.
I have tested this with PHP 4.4.0-gentoo-amd64, 5.0.4-FC4, and
5.0.5-gentoo and all exhebit the same problems.
The configure line is different on all platforms. php.ini is the
default. On the FC4 test there is a 512Mb memory limit.
Reproduce code:
---
';
$xml_clean .= str_repeat('a',496);
$xml_clean .= '';
$ret = preg_match("/(<([\w]+)[^>]*>)(.*?)(<\/\\2>)/s", $xml_clean,
$match);
print_r($match);
?>
Expected result:
Array
(
[0] => aaa(...)aaa
[1] =>
[2] => data
[3] => aaa(...)aaa
[4] =>
)
Actual result:
--
Array
(
)
--
Edit this bug report at http://bugs.php.net/?id=34720&edit=1
#34721 [NEW]: fpassthru() or readfile() returns invalid data
From: cpriest at warpmail dot net Operating system: Redhat Enterprise 4 PHP version: 5.0.5 PHP Bug Type: Output Control Bug description: fpassthru() or readfile() returns invalid data Description: Calling fpassthru() or readfile() on a file returns a truncated file, using: echo file_get_contents(); and it works fine. I'm assuming its a binary issue, I know it has problems with pdf documents. Reproduce code: --- readfile($filepath); // Returns unreadable pdf file Expected result: Uncorrupted file returned to browser Actual result: -- Corrupted file returned to browser -- Edit bug report at http://bugs.php.net/?id=34721&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34721&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34721&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34721&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34721&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34721&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34721&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34721&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34721&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34721&r=support Expected behavior: http://bugs.php.net/fix.php?id=34721&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34721&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34721&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34721&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34721&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34721&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34721&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34721&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34721&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34721&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34721&r=mysqlcfg
#34720 [NEW]: Problem when a parenthesised sub exp matches >= 4999996 chars
From: nuitari at nuitari dot net
Operating system: Linux
PHP version: 5.0.5
PHP Bug Type: PCRE related
Bug description: Problem when a parenthesised sub exp matches >= 496 chars
Description:
If a paranthesised sub expression matches more then ~496 chars, no
data will be inserted into the &matches array.
Reducing by 1 the number in str_repeat will cause the script to work.
I have tested this with PHP 4.4.0-gentoo-amd64, 5.0.4-FC4, and
5.0.5-gentoo and all exhebit the same problems.
The configure line is different on all platforms. php.ini is the default.
On the FC4 test there is a 512Mb memory limit.
Reproduce code:
---
';
$xml_clean .= str_repeat('a',496);
$xml_clean .= '';
$ret = preg_match("/(<([\w]+)[^>]*>)(.*?)(<\/\\2>)/s", $xml_clean,
$match);
print_r($match);
?>
Expected result:
Array
(
[0] => aaa(...)aaa
[1] =>
[2] => data
[3] => aaa(...)aaa
[4] =>
)
Actual result:
--
Array
(
)
--
Edit bug report at http://bugs.php.net/?id=34720&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34720&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34720&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34720&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34720&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34720&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34720&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34720&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34720&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34720&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34720&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34720&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34720&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34720&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34720&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34720&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34720&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34720&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34720&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34720&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34720&r=mysqlcfg
#34705 [Asn]: udm_clear_search_limits() causes seg.fault.
ID: 34705 Updated by: [EMAIL PROTECTED] Reported By: tomasare at gmail dot com Status: Assigned Bug Type: mnoGoSearch related Operating System: Ubuntu GNU/Linux PHP Version: 4CVS-2005-10-02 (snap) Assigned To: gluke New Comment: gluke at php.net: For PECL - maybe it'd be the best way. But removing/disabling functions in PHP4 and others doesn't seem to be the best option. I'd suggest to make a wrapper to emulate the old syntax using new functions (not sure if it's possible, though). Previous Comments: [2005-10-03 21:03:22] tomasare at gmail dot com This bug report was produced using mnogosearch-3.2.34 and php-4.4.0. [2005-10-03 18:49:48] [EMAIL PROTECTED] It is the function call used in old versions of mnogosearch. It seems to me that the best and the most safe way is to disable this function if php compiled with mnogosearch-3.2+ [2005-10-03 16:01:15] [EMAIL PROTECTED] Assigned to the maintainer. [2005-10-02 13:11:11] tomasare at gmail dot com Description: If you add some search limits (udm_add_search_limit()) and maybe some params (udm_set_agent_param()), and then clear the search limits with udm_clear_search_limits(), some of the params also gets cleared (i.e. they "disappear"). In addition all search limits may not actually be cleared and in the end the script seg.faults when executing udm_find(). Reproduce code: --- udm_set_agent_param($agent, UDM_PARAM_QUERY, "foo"); udm_set_agent_param($agent, UDM_PARAM_WEIGHT_FACTOR, 11); udm_add_search_limit($agent, UDM_LIMIT_TAG, "%"); udm_clear_search_limits($agent); udm_find($agent,""); Expected result: The script seg.faults when calling udm_find(). Actual result: -- As far as I can see, the code for udm_clear_search_limits contains to errors: 1. Agent->Conf->Vars.nvars gets decreased inside the loop. This causes the loop to iterate fewer times than expected. That means that some of the search limits may not be cleared. 2. After the loop is done, it contains some NULL-values (from the cleared limits). Since the Agent->Conf->Vars.nvars is reduced, some params after these NULL-values may not be visible. These NULL-bytes may cause a seg.fault at line 1998 in searchtool.c (from the mnogosearch source). I made a "quick and dirty" solution that's available here: http://www.storsalen.no/php_mnogo.c.patch It modifies the Agent->Conf->Vars.nvars only after the loop, and after first sorting the array to remove any "holes" caused by the NULL-values. This is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1082341088 (LWP 20149)] 0x40776e09 in strcasecmp () from /lib/tls/libc.so.6 (gdb) bt #0 0x40776e09 in strcasecmp () from /lib/tls/libc.so.6 #1 0x4068ab5e in UdmConvert (Conf=0x84c93d0, Res=0x83e0010, lcs=0x845ca7c, bcs=0x406f6160) at searchtool.c:2011 #2 0x40696baf in UdmFind (A=0x84cd4e0) at db.c:946 #3 0x080e4491 in zif_udm_find (ht=1082341068, return_value=0x83e013c, this_ptr=0x0, return_value_used=1) at /usr/local/src/php-4.4.0/ext/mnogosearch/php_mnogo.c:2030 #4 0x081ab45d in execute (op_array=0x83d895c) at /usr/local/src/php-4.4.0/Zend/zend_execute.c:1672 #5 0x0819cc79 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php-4.4.0/Zend/zend.c:938 #6 0x0817340d in php_execute_script (primary_file=0xba30) at /usr/local/src/php-4.4.0/main/main.c:1751 #7 0x081afd17 in main (argc=2, argv=0xbaf4) at /usr/local/src/php-4.4.0/sapi/cli/php_cli.c:828 (gdb) -- Edit this bug report at http://bugs.php.net/?id=34705&edit=1
#34705 [Asn]: udm_clear_search_limits() causes seg.fault.
ID: 34705 User updated by: tomasare at gmail dot com Reported By: tomasare at gmail dot com Status: Assigned Bug Type: mnoGoSearch related Operating System: Ubuntu GNU/Linux PHP Version: 4CVS-2005-10-02 (snap) Assigned To: gluke New Comment: This bug report was produced using mnogosearch-3.2.34 and php-4.4.0. Previous Comments: [2005-10-03 18:49:48] [EMAIL PROTECTED] It is the function call used in old versions of mnogosearch. It seems to me that the best and the most safe way is to disable this function if php compiled with mnogosearch-3.2+ [2005-10-03 16:01:15] [EMAIL PROTECTED] Assigned to the maintainer. [2005-10-02 13:11:11] tomasare at gmail dot com Description: If you add some search limits (udm_add_search_limit()) and maybe some params (udm_set_agent_param()), and then clear the search limits with udm_clear_search_limits(), some of the params also gets cleared (i.e. they "disappear"). In addition all search limits may not actually be cleared and in the end the script seg.faults when executing udm_find(). Reproduce code: --- udm_set_agent_param($agent, UDM_PARAM_QUERY, "foo"); udm_set_agent_param($agent, UDM_PARAM_WEIGHT_FACTOR, 11); udm_add_search_limit($agent, UDM_LIMIT_TAG, "%"); udm_clear_search_limits($agent); udm_find($agent,""); Expected result: The script seg.faults when calling udm_find(). Actual result: -- As far as I can see, the code for udm_clear_search_limits contains to errors: 1. Agent->Conf->Vars.nvars gets decreased inside the loop. This causes the loop to iterate fewer times than expected. That means that some of the search limits may not be cleared. 2. After the loop is done, it contains some NULL-values (from the cleared limits). Since the Agent->Conf->Vars.nvars is reduced, some params after these NULL-values may not be visible. These NULL-bytes may cause a seg.fault at line 1998 in searchtool.c (from the mnogosearch source). I made a "quick and dirty" solution that's available here: http://www.storsalen.no/php_mnogo.c.patch It modifies the Agent->Conf->Vars.nvars only after the loop, and after first sorting the array to remove any "holes" caused by the NULL-values. This is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1082341088 (LWP 20149)] 0x40776e09 in strcasecmp () from /lib/tls/libc.so.6 (gdb) bt #0 0x40776e09 in strcasecmp () from /lib/tls/libc.so.6 #1 0x4068ab5e in UdmConvert (Conf=0x84c93d0, Res=0x83e0010, lcs=0x845ca7c, bcs=0x406f6160) at searchtool.c:2011 #2 0x40696baf in UdmFind (A=0x84cd4e0) at db.c:946 #3 0x080e4491 in zif_udm_find (ht=1082341068, return_value=0x83e013c, this_ptr=0x0, return_value_used=1) at /usr/local/src/php-4.4.0/ext/mnogosearch/php_mnogo.c:2030 #4 0x081ab45d in execute (op_array=0x83d895c) at /usr/local/src/php-4.4.0/Zend/zend_execute.c:1672 #5 0x0819cc79 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php-4.4.0/Zend/zend.c:938 #6 0x0817340d in php_execute_script (primary_file=0xba30) at /usr/local/src/php-4.4.0/main/main.c:1751 #7 0x081afd17 in main (argc=2, argv=0xbaf4) at /usr/local/src/php-4.4.0/sapi/cli/php_cli.c:828 (gdb) -- Edit this bug report at http://bugs.php.net/?id=34705&edit=1
#34705 [Asn]: udm_clear_search_limits() causes seg.fault.
ID: 34705 Updated by: [EMAIL PROTECTED] Reported By: tomasare at gmail dot com Status: Assigned Bug Type: mnoGoSearch related Operating System: Ubuntu GNU/Linux PHP Version: 4CVS-2005-10-02 (snap) Assigned To: gluke New Comment: It is the function call used in old versions of mnogosearch. It seems to me that the best and the most safe way is to disable this function if php compiled with mnogosearch-3.2+ Previous Comments: [2005-10-03 16:01:15] [EMAIL PROTECTED] Assigned to the maintainer. [2005-10-02 13:11:11] tomasare at gmail dot com Description: If you add some search limits (udm_add_search_limit()) and maybe some params (udm_set_agent_param()), and then clear the search limits with udm_clear_search_limits(), some of the params also gets cleared (i.e. they "disappear"). In addition all search limits may not actually be cleared and in the end the script seg.faults when executing udm_find(). Reproduce code: --- udm_set_agent_param($agent, UDM_PARAM_QUERY, "foo"); udm_set_agent_param($agent, UDM_PARAM_WEIGHT_FACTOR, 11); udm_add_search_limit($agent, UDM_LIMIT_TAG, "%"); udm_clear_search_limits($agent); udm_find($agent,""); Expected result: The script seg.faults when calling udm_find(). Actual result: -- As far as I can see, the code for udm_clear_search_limits contains to errors: 1. Agent->Conf->Vars.nvars gets decreased inside the loop. This causes the loop to iterate fewer times than expected. That means that some of the search limits may not be cleared. 2. After the loop is done, it contains some NULL-values (from the cleared limits). Since the Agent->Conf->Vars.nvars is reduced, some params after these NULL-values may not be visible. These NULL-bytes may cause a seg.fault at line 1998 in searchtool.c (from the mnogosearch source). I made a "quick and dirty" solution that's available here: http://www.storsalen.no/php_mnogo.c.patch It modifies the Agent->Conf->Vars.nvars only after the loop, and after first sorting the array to remove any "holes" caused by the NULL-values. This is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1082341088 (LWP 20149)] 0x40776e09 in strcasecmp () from /lib/tls/libc.so.6 (gdb) bt #0 0x40776e09 in strcasecmp () from /lib/tls/libc.so.6 #1 0x4068ab5e in UdmConvert (Conf=0x84c93d0, Res=0x83e0010, lcs=0x845ca7c, bcs=0x406f6160) at searchtool.c:2011 #2 0x40696baf in UdmFind (A=0x84cd4e0) at db.c:946 #3 0x080e4491 in zif_udm_find (ht=1082341068, return_value=0x83e013c, this_ptr=0x0, return_value_used=1) at /usr/local/src/php-4.4.0/ext/mnogosearch/php_mnogo.c:2030 #4 0x081ab45d in execute (op_array=0x83d895c) at /usr/local/src/php-4.4.0/Zend/zend_execute.c:1672 #5 0x0819cc79 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php-4.4.0/Zend/zend.c:938 #6 0x0817340d in php_execute_script (primary_file=0xba30) at /usr/local/src/php-4.4.0/main/main.c:1751 #7 0x081afd17 in main (argc=2, argv=0xbaf4) at /usr/local/src/php-4.4.0/sapi/cli/php_cli.c:828 (gdb) -- Edit this bug report at http://bugs.php.net/?id=34705&edit=1
#34712 [Fbk->Opn]: zend.ze1_compatibility_mode = on segfault
ID: 34712 User updated by: jason at jasonjustman dot com Reported By: jason at jasonjustman dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: solars 10 PHP Version: 5CVS-2005-10-03 (snap) Assigned To: dmitry New Comment: Like i said before, i can't track down the exact sequence (stacktrace of the .php script code shows its in the 12-14th depth), and for full debug - only after parsing about 15kloc of code. When adding in debugging php source code in the new call ( $this->_helper = new helper($this);), it prevents the crash but in one case a print_r($this) in the aggrevator:: scope resulted in an empty object. This testcase is more pseudocode of the segfault pattern than actual instance. If you'd like I can privately attach the application source - but again, its not an application problem - as turning off ze1_compat doesn't cause a segfault , but is required for implicit clone. This happens in the same spot for the 5.0.5, 5.0.6-dev and 5.0.6-latest - even after building in seperate directories with no caching enabled. Previous Comments: [2005-10-03 12:13:48] [EMAIL PROTECTED] This test case must not work at all. $ php -d "zend.ze1_compatibility_mode=1" bug34712.php Fatal error: Cannot use 'parent' as class name as it is reserved in /home/dmitry/php/test/bug34712.php on line 20 Without "parent" it works fine on Linux/i386. Try to make full rebuild. [2005-10-03 11:24:37] [EMAIL PROTECTED] Dmitry, you did something related to this lately? [2005-10-03 10:29:43] jason at jasonjustman dot com last two lines of sample code should be: $c = new child; $a = new aggrevator($c); [2005-10-03 10:26:29] jason at jasonjustman dot com still present: (gdb) n Single stepping until exit from function child_main, which has no line number information. Program received signal SIGSEGV, Segmentation fault. 0xfef36f20 in zend_objects_clone_obj (zobject=0xff3fffc8) at /export/apache/php5-200510030630/Zend/zend_objects.c:167 167 new_obj_val = zend_objects_new(&new_object, old_object->ce TSRMLS_CC); (gdb) backtrace #0 0xfef36f20 in zend_objects_clone_obj (zobject=0xff3fffc8) at /export/apache/php5-200510030630/Zend/zend_objects.c:167 #1 0xfef36de0 in zval_add_ref_or_clone (p=0x0) at /export/apache/php5-200510030630/Zend/zend_objects.c:129 sniped [2005-10-03 10:06:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip 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/34712 -- Edit this bug report at http://bugs.php.net/?id=34712&edit=1
#34718 [Bgs]: cannot compile PHP as an Apache2 module
ID: 34718
User updated by: ionut dot aivanesei at amdocs dot com
Reported By: ionut dot aivanesei at amdocs dot com
Status: Bogus
Bug Type: Apache2 related
Operating System: HP-UX B.11.11
PHP Version: 5.0.5
New Comment:
One more thing to mention is that the make and make install are
successful if I run configure without --with-apxs2, and it works ok in
CGI mode (with mysql also).
Previous Comments:
[2005-10-03 15:58:26] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
[2005-10-03 15:53:34] ionut dot aivanesei at amdocs dot com
Description:
Hi,
I am trying to compile PHP 5.0.5 on HP-UX B.11.11 and I am not
succeeding.
I have already compiled httpd-2.0.54 with --enable-so
--enable-rewrite.
I have MySQL binaries mysql-standard-4.1.14-hp-hpux11.11-hppa2.0w.
I am using the following: ./configure --prefix=${BUILD_DIR}/php
--with-apxs2=${BUILD_DIR}/httpd/bin/apxs
--with-mysql=${BUILD_DIR}/mysql
./configure is finished OK.
make is finished OK, but with the following warnings:
--
*** Warning: linker path does not have real file for library
-lmysqlclient.
*** I have the capability to make that library automatically link in
when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libmysqlclient and none of the candidates passed a file format
test
*** using a file magic. Last file checked:
/elsuser11.p802a/els/crm/ionuta/web/mysql/lib/libmysqlclient.a
*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module libphp5. Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.
--
Then, when I run make install I have the following error:
--
Installing PHP SAPI module: apache2handler
/elsuser11.p802a/els/crm/ionuta/web/httpd/build/instdso.sh
SH_LIBTOOL='/elsuser11.p802a/els/crm/ionuta/web/httpd/build/libtool'
libphp5.la /elsuser11.p802a/els/crm/ionuta/web/httpd/modules
/elsuser11.p802a/els/crm/ionuta/web/httpd/build/libtool --mode=install
cp libphp5.la /elsuser11.p802a/els/crm/ionuta/web/httpd/modules/
cp .libs/libphp5.lai
/elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.la
cp .libs/libphp5.a
/elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.a
ranlib /elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.a
chmod 644 /elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.a
libtool: install: warning: remember to run `libtool --finish
/elsuser11.p802a/els/crm/ionuta/web/_sources/php/php-5.0.5/libs'
Warning! dlname not found in
/elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.la.
Assuming installing a .so rather than a libtool archive.
chmod 755 /elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.so
chmod: can't access
/elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.so
apxs:Error: Command failed with rc=65536
.
*** Error exit code 1
Stop.
--
I get this only when compiling with mysql support. Otherwise everything
is ok.
Thank you,
Ionut
Reproduce code:
---
n/a
Expected result:
n/a
Actual result:
--
n/a
--
Edit this bug report at http://bugs.php.net/?id=34718&edit=1
#34705 [Opn->Asn]: udm_clear_search_limits() causes seg.fault.
ID: 34705 Updated by: [EMAIL PROTECTED] Reported By: tomasare at gmail dot com -Status: Open +Status: Assigned Bug Type: mnoGoSearch related Operating System: Ubuntu GNU/Linux PHP Version: 4CVS-2005-10-02 (snap) -Assigned To: +Assigned To: gluke New Comment: Assigned to the maintainer. Previous Comments: [2005-10-02 13:11:11] tomasare at gmail dot com Description: If you add some search limits (udm_add_search_limit()) and maybe some params (udm_set_agent_param()), and then clear the search limits with udm_clear_search_limits(), some of the params also gets cleared (i.e. they "disappear"). In addition all search limits may not actually be cleared and in the end the script seg.faults when executing udm_find(). Reproduce code: --- udm_set_agent_param($agent, UDM_PARAM_QUERY, "foo"); udm_set_agent_param($agent, UDM_PARAM_WEIGHT_FACTOR, 11); udm_add_search_limit($agent, UDM_LIMIT_TAG, "%"); udm_clear_search_limits($agent); udm_find($agent,""); Expected result: The script seg.faults when calling udm_find(). Actual result: -- As far as I can see, the code for udm_clear_search_limits contains to errors: 1. Agent->Conf->Vars.nvars gets decreased inside the loop. This causes the loop to iterate fewer times than expected. That means that some of the search limits may not be cleared. 2. After the loop is done, it contains some NULL-values (from the cleared limits). Since the Agent->Conf->Vars.nvars is reduced, some params after these NULL-values may not be visible. These NULL-bytes may cause a seg.fault at line 1998 in searchtool.c (from the mnogosearch source). I made a "quick and dirty" solution that's available here: http://www.storsalen.no/php_mnogo.c.patch It modifies the Agent->Conf->Vars.nvars only after the loop, and after first sorting the array to remove any "holes" caused by the NULL-values. This is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1082341088 (LWP 20149)] 0x40776e09 in strcasecmp () from /lib/tls/libc.so.6 (gdb) bt #0 0x40776e09 in strcasecmp () from /lib/tls/libc.so.6 #1 0x4068ab5e in UdmConvert (Conf=0x84c93d0, Res=0x83e0010, lcs=0x845ca7c, bcs=0x406f6160) at searchtool.c:2011 #2 0x40696baf in UdmFind (A=0x84cd4e0) at db.c:946 #3 0x080e4491 in zif_udm_find (ht=1082341068, return_value=0x83e013c, this_ptr=0x0, return_value_used=1) at /usr/local/src/php-4.4.0/ext/mnogosearch/php_mnogo.c:2030 #4 0x081ab45d in execute (op_array=0x83d895c) at /usr/local/src/php-4.4.0/Zend/zend_execute.c:1672 #5 0x0819cc79 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php-4.4.0/Zend/zend.c:938 #6 0x0817340d in php_execute_script (primary_file=0xba30) at /usr/local/src/php-4.4.0/main/main.c:1751 #7 0x081afd17 in main (argc=2, argv=0xbaf4) at /usr/local/src/php-4.4.0/sapi/cli/php_cli.c:828 (gdb) -- Edit this bug report at http://bugs.php.net/?id=34705&edit=1
#34718 [Opn->Bgs]: cannot compile PHP as an Apache2 module
ID: 34718
Updated by: [EMAIL PROTECTED]
Reported By: ionut dot aivanesei at amdocs dot com
-Status: Open
+Status: Bogus
Bug Type: Apache2 related
Operating System: HP-UX B.11.11
PHP Version: 5.0.5
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Previous Comments:
[2005-10-03 15:53:34] ionut dot aivanesei at amdocs dot com
Description:
Hi,
I am trying to compile PHP 5.0.5 on HP-UX B.11.11 and I am not
succeeding.
I have already compiled httpd-2.0.54 with --enable-so
--enable-rewrite.
I have MySQL binaries mysql-standard-4.1.14-hp-hpux11.11-hppa2.0w.
I am using the following: ./configure --prefix=${BUILD_DIR}/php
--with-apxs2=${BUILD_DIR}/httpd/bin/apxs
--with-mysql=${BUILD_DIR}/mysql
./configure is finished OK.
make is finished OK, but with the following warnings:
--
*** Warning: linker path does not have real file for library
-lmysqlclient.
*** I have the capability to make that library automatically link in
when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libmysqlclient and none of the candidates passed a file format
test
*** using a file magic. Last file checked:
/elsuser11.p802a/els/crm/ionuta/web/mysql/lib/libmysqlclient.a
*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module libphp5. Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.
--
Then, when I run make install I have the following error:
--
Installing PHP SAPI module: apache2handler
/elsuser11.p802a/els/crm/ionuta/web/httpd/build/instdso.sh
SH_LIBTOOL='/elsuser11.p802a/els/crm/ionuta/web/httpd/build/libtool'
libphp5.la /elsuser11.p802a/els/crm/ionuta/web/httpd/modules
/elsuser11.p802a/els/crm/ionuta/web/httpd/build/libtool --mode=install
cp libphp5.la /elsuser11.p802a/els/crm/ionuta/web/httpd/modules/
cp .libs/libphp5.lai
/elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.la
cp .libs/libphp5.a
/elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.a
ranlib /elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.a
chmod 644 /elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.a
libtool: install: warning: remember to run `libtool --finish
/elsuser11.p802a/els/crm/ionuta/web/_sources/php/php-5.0.5/libs'
Warning! dlname not found in
/elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.la.
Assuming installing a .so rather than a libtool archive.
chmod 755 /elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.so
chmod: can't access
/elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.so
apxs:Error: Command failed with rc=65536
.
*** Error exit code 1
Stop.
--
I get this only when compiling with mysql support. Otherwise everything
is ok.
Thank you,
Ionut
Reproduce code:
---
n/a
Expected result:
n/a
Actual result:
--
n/a
--
Edit this bug report at http://bugs.php.net/?id=34718&edit=1
#34717 [Asn->Bgs]: PHP 5.0.5 ships with wrong php_gd2.dll
ID: 34717 Updated by: [EMAIL PROTECTED] Reported By: webmaster at hackquest dot de -Status: Assigned +Status: Bogus Bug Type: GD related Operating System: Windows 2003 PHP Version: 5.0.5 Assigned To: edink New Comment: php_gd2.dll works fine. You must have mixed up dlls, php.ini's extension_dir directive or something else. Previous Comments: [2005-10-03 14:33:47] webmaster at hackquest dot de Correction: 5.1.0 works fine, crashes came due to me trying out stuff with the 5.0.5 version. Namely, I copied over 5.0.5 DLL files into the Apache directory. After I deleted all php DLL files from all places, 5.1.0 works fine. 5.0.5 still does not like the GD2 DLL, though. [2005-10-03 14:29:21] [EMAIL PROTECTED] Will look into it. [2005-10-03 14:25:19] webmaster at hackquest dot de Description: Problem: I tried to update my old PHP5 with the new version. Installing 5.0.5 over 5.0.4 breaks the GD functionality, because it cannot find the procedure entry into the DLL. Looks like the supplied php_gd2.dll file is too old/new/different than supposed to. The new 5.1.0 RC has the correct DLL coming with it, however I can't use it because the RC crashes in php5ts.dll every few minutes. Fix: Installing either 5.0.4 or 5.1.0 fixes the problem. (However, 5.1.0 does not work on Windows 2003/Apache2, due to above mentioned crashes) -- Edit this bug report at http://bugs.php.net/?id=34717&edit=1
#34718 [NEW]: cannot compile PHP as an Apache2 module
From: ionut dot aivanesei at amdocs dot com
Operating system: HP-UX B.11.11
PHP version: 5.0.5
PHP Bug Type: Apache2 related
Bug description: cannot compile PHP as an Apache2 module
Description:
Hi,
I am trying to compile PHP 5.0.5 on HP-UX B.11.11 and I am not
succeeding.
I have already compiled httpd-2.0.54 with --enable-so --enable-rewrite.
I have MySQL binaries mysql-standard-4.1.14-hp-hpux11.11-hppa2.0w.
I am using the following: ./configure --prefix=${BUILD_DIR}/php
--with-apxs2=${BUILD_DIR}/httpd/bin/apxs --with-mysql=${BUILD_DIR}/mysql
./configure is finished OK.
make is finished OK, but with the following warnings:
--
*** Warning: linker path does not have real file for library
-lmysqlclient.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libmysqlclient and none of the candidates passed a file format
test
*** using a file magic. Last file checked:
/elsuser11.p802a/els/crm/ionuta/web/mysql/lib/libmysqlclient.a
*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module libphp5. Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.
--
Then, when I run make install I have the following error:
--
Installing PHP SAPI module: apache2handler
/elsuser11.p802a/els/crm/ionuta/web/httpd/build/instdso.sh
SH_LIBTOOL='/elsuser11.p802a/els/crm/ionuta/web/httpd/build/libtool'
libphp5.la /elsuser11.p802a/els/crm/ionuta/web/httpd/modules
/elsuser11.p802a/els/crm/ionuta/web/httpd/build/libtool --mode=install cp
libphp5.la /elsuser11.p802a/els/crm/ionuta/web/httpd/modules/
cp .libs/libphp5.lai
/elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.la
cp .libs/libphp5.a
/elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.a
ranlib /elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.a
chmod 644 /elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.a
libtool: install: warning: remember to run `libtool --finish
/elsuser11.p802a/els/crm/ionuta/web/_sources/php/php-5.0.5/libs'
Warning! dlname not found in
/elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.la.
Assuming installing a .so rather than a libtool archive.
chmod 755 /elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.so
chmod: can't access
/elsuser11.p802a/els/crm/ionuta/web/httpd/modules/libphp5.so
apxs:Error: Command failed with rc=65536
.
*** Error exit code 1
Stop.
--
I get this only when compiling with mysql support. Otherwise everything is
ok.
Thank you,
Ionut
Reproduce code:
---
n/a
Expected result:
n/a
Actual result:
--
n/a
--
Edit bug report at http://bugs.php.net/?id=34718&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34718&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34718&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34718&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34718&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34718&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34718&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34718&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34718&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34718&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34718&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34718&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34718&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34718&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34718&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34718&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34718&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34718&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34718&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34718&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34718&r=mysqlcfg
#34681 [Asn->Bgs]: MySQL double type loses trailing zeroes with mysqli prepared statements
ID: 34681
Updated by: [EMAIL PROTECTED]
Reported By: adrian at fuzzee dot co dot uk
-Status: Assigned
+Status: Bogus
Bug Type: MySQLi related
Operating System: *
PHP Version: 5CVS-2005-09-29 (cvs)
Assigned To: georg
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
If you want to convert double value to a string, use MySQL
cast function: SELECT CAST(1.234 AS CHAR) FROM DUAL
While mysql_query uses a string based protocol (server
sends all values as string), prepared statements use
binary protocol, which was introduced in MySQL 4.1. That
means numeric values will be transferred in binary
representation and stored in PHP's corresponding data
types.
Previous Comments:
[2005-09-30 11:11:12] [EMAIL PROTECTED]
I tested with these (mysql --version):
mysql Ver 14.7 Distrib 4.1.13, for pc-linux-gnu (i686) using readline
4.3
mysql Ver 14.7 Distrib 4.1.12, for pc-linux-gnu (i686) using readline
4.3
I don't know what you meant with 'client library version'.
[2005-09-30 10:29:21] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
What MySQL Version do you use, which client library version?
[2005-09-29 17:54:30] [EMAIL PROTECTED]
By replacing the echo's with var_dump() calls, I get this:
float(0)
array(2) {
[0]=>
string(5) "0.000"
["number"]=>
string(5) "0.000"
}
So what you think is truncation is simply how PHP handles floats. Try
"echo 0.00;" for example.
Assigned to Georg since this seems really inconsistent behaviour first.
(perhaps just needs to be documented?)
[2005-09-29 17:09:12] adrian at fuzzee dot co dot uk
Description:
With mysqli statements, a MySQL double loses trailing zeroes, so
'0.000' becomes just '0' and '3.350' would become '3.35'. However, if
you use regular mysqli queries (non prepared statements) the trailing
zeroes are preserved... Obviously not a fatal bug, but an odd
difference in behaviour.
Reproduce code:
---
$sql = "SELECT 0.000 as number";
$mysqli = new mysqli(...);
$stmt = $mysqli->prepare($sql);
$stmt->bind_result($number);
$stmt->execute();
$stmt->store_result();
$stmt->fetch();
$stmt->close();
echo "$number\n";
$r = $mysqli->query($sql);
$tmp = $r->fetch_array();
echo "$tmp[0]\n";
Expected result:
0.000
0.000
Actual result:
--
0
0.000
--
Edit this bug report at http://bugs.php.net/?id=34681&edit=1
#26005 [Com]: Random "cannot change the session's ini settings" errors
ID: 26005
Comment by: codebowl at gmail dot com
Reported By: parsnip11 at hotmail dot com
Status: No Feedback
Bug Type: Session related
Operating System: *
PHP Version: 4CVS-2003-10-31
New Comment:
I am also having this problem however i am using php 5.0.5 on windows.
I am running Apache 2 and the isapi module.
This seems to happen when i run a script that will do about 20 curl
executions.
I also have no ini_set for session stuff, however i do have
ini_set('max_execution_time', 600);
I am not sure why i am getting this since it was brought up in php 4 i
figured it would be fixed by 5, maybe it's something new?
I am also using a custom session handler, but up until now have never
had a problem with it.
Previous Comments:
[2005-02-14 11:02:35] zehunter38 at hotmail dot com
i'm using php 4.3.9 with apache 1.3.32 and i got the same error message
: A session is active. You cannot change the session module's ini
settings at this time...
memory seems ok in my server (still 46Mo free, maybe it's link to some
memory allocation parameters?)
[2004-09-23 01:00:04] php-bugs at lists dot php dot net
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".
[2004-09-15 15:35:53] [EMAIL PROTECTED]
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
[2004-07-04 22:28:41] [EMAIL PROTECTED]
We have tackled down the problem to memory allocation issues. If PHP is
unable to allocate more memory it quits, but then the session module
still tries to save stuff, and due to the unavailability of memory, it
is unable to do so.
The interesting part is that regardless of our display_errors=off
setting, this session error still gets printed out to the browser (the
mem allocation problem is only present in our logs). The session module
should not print errors if display_errors is off.
[2004-07-04 13:51:38] [EMAIL PROTECTED]
We also experience the same error with PHP 4.3.7 with Apache 1.3.31. We
have the following session settings in .htaccess:
php_value session.cache_expire20
php_value session.gc_maxlifetime 20
php_value session.cookie_domain ".weblabor.hu"
php_value session.cookie_lifetime 200
php_value session.auto_start 0
php_value session.save_handleruser
php_value session.cache_limiter none
Our session handlers store data in a database, and are set with
session_set_save_handler() in userland code. The error is the exact one
reported by the bug opener.
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/26005
--
Edit this bug report at http://bugs.php.net/?id=26005&edit=1
#34717 [Asn]: PHP 5.0.5 ships with wrong php_gd2.dll
ID: 34717 User updated by: webmaster at hackquest dot de Reported By: webmaster at hackquest dot de Status: Assigned Bug Type: GD related Operating System: Windows 2003 PHP Version: 5.0.5 Assigned To: edink New Comment: Correction: 5.1.0 works fine, crashes came due to me trying out stuff with the 5.0.5 version. Namely, I copied over 5.0.5 DLL files into the Apache directory. After I deleted all php DLL files from all places, 5.1.0 works fine. 5.0.5 still does not like the GD2 DLL, though. Previous Comments: [2005-10-03 14:29:21] [EMAIL PROTECTED] Will look into it. [2005-10-03 14:25:19] webmaster at hackquest dot de Description: Problem: I tried to update my old PHP5 with the new version. Installing 5.0.5 over 5.0.4 breaks the GD functionality, because it cannot find the procedure entry into the DLL. Looks like the supplied php_gd2.dll file is too old/new/different than supposed to. The new 5.1.0 RC has the correct DLL coming with it, however I can't use it because the RC crashes in php5ts.dll every few minutes. Fix: Installing either 5.0.4 or 5.1.0 fixes the problem. (However, 5.1.0 does not work on Windows 2003/Apache2, due to above mentioned crashes) -- Edit this bug report at http://bugs.php.net/?id=34717&edit=1
#34717 [Opn->Asn]: PHP 5.0.5 ships with wrong php_gd2.dll
ID: 34717 Updated by: [EMAIL PROTECTED] Reported By: webmaster at hackquest dot de -Status: Open +Status: Assigned Bug Type: GD related Operating System: Windows 2003 PHP Version: 5.0.5 -Assigned To: +Assigned To: edink New Comment: Will look into it. Previous Comments: [2005-10-03 14:25:19] webmaster at hackquest dot de Description: Problem: I tried to update my old PHP5 with the new version. Installing 5.0.5 over 5.0.4 breaks the GD functionality, because it cannot find the procedure entry into the DLL. Looks like the supplied php_gd2.dll file is too old/new/different than supposed to. The new 5.1.0 RC has the correct DLL coming with it, however I can't use it because the RC crashes in php5ts.dll every few minutes. Fix: Installing either 5.0.4 or 5.1.0 fixes the problem. (However, 5.1.0 does not work on Windows 2003/Apache2, due to above mentioned crashes) -- Edit this bug report at http://bugs.php.net/?id=34717&edit=1
#34717 [NEW]: PHP 5.0.5 ships with wrong php_gd2.dll
From: webmaster at hackquest dot de Operating system: Windows 2003 PHP version: 5.0.5 PHP Bug Type: GD related Bug description: PHP 5.0.5 ships with wrong php_gd2.dll Description: Problem: I tried to update my old PHP5 with the new version. Installing 5.0.5 over 5.0.4 breaks the GD functionality, because it cannot find the procedure entry into the DLL. Looks like the supplied php_gd2.dll file is too old/new/different than supposed to. The new 5.1.0 RC has the correct DLL coming with it, however I can't use it because the RC crashes in php5ts.dll every few minutes. Fix: Installing either 5.0.4 or 5.1.0 fixes the problem. (However, 5.1.0 does not work on Windows 2003/Apache2, due to above mentioned crashes) -- Edit bug report at http://bugs.php.net/?id=34717&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34717&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34717&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34717&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34717&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34717&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34717&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34717&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34717&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34717&r=support Expected behavior: http://bugs.php.net/fix.php?id=34717&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34717&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34717&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34717&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34717&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34717&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34717&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34717&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34717&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34717&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34717&r=mysqlcfg
#34358 [Opn->Asn]: Fatal error: Cannot re-assign $this
ID: 34358
Updated by: [EMAIL PROTECTED]
Reported By: pacha dot shevaev at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.*
Assigned To: dmitry
Previous Comments:
[2005-10-03 12:42:48] [EMAIL PROTECTED]
I'm reopening this so that we can discuss it. I don't think we should
be silently ignoring references as that's something vague. See mail to
internals@ in a bit.
[2005-10-03 12:14:59] [EMAIL PROTECTED]
So for the curious who are wondering what "fixed" means. The & is
simply ignored in this case now.
[2005-10-03 10:22:47] [EMAIL PROTECTED]
Fixed in CVS HEAD and PHP_5_1.
[2005-10-03 09:40:14] [EMAIL PROTECTED]
It has everything to do with the new object model. Take this code:
$x = &$this;
$x = 'foo';
For performance reasons we need to catch such references when they
happen in order to prevent the object being overwritten inside itself.
It would be a bit less confusing if the error happened on the actual
assignment, but in this new object model there $x = &$this; is just as
wrong as $this = &$x since the only purpose one could have for making a
reference to $this itself is if you wanted to change it directly. In
all valid cases this should be $x = $this.
I suppose an option would be to ignore the reference in this case and
continue on. That seems to be happening with that last indirect case
you posted, but it would cost us a lookup.
[2005-09-15 15:32:13] pacha dot shevaev at gmail dot com
And why does the following code work then???
ref =& $this;
$this->ref->test();
}
function test() {
echo 'test';
}
}
$foo = new Foo();
?>
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/34358
--
Edit this bug report at http://bugs.php.net/?id=34358&edit=1
#27891 [Com]: Bad behavior of require() function and relative paths with IIS
ID: 27891 Comment by: david_amer at yahoo dot co dot uk Reported By: faraco dot phpbugs at mailnull dot com Status: No Feedback Bug Type: IIS related Operating System: win32 PHP Version: 5CVS, 4CVS (2005-06-19) New Comment: I was having the same problem so i tryed the latest build as sugested in the previous post, it still isnt working unfortunatly. Previous Comments: [2005-08-07 01:00:03] php-bugs at lists dot php dot net 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". [2005-07-30 15:29:05] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-05-17 22:54:53] faraco dot phpbugs at mailnull dot com The problem persists. [2005-05-17 16:46:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-05-16 22:34:47] faraco dot phpbugs at mailnull dot com Another way to explain the problem... Following de example above: 1. when I require 'lib/functions.php', the file is first looked in my domain document root ['docroot/lib/'] and then in my actual path ['subroot/lib'] because if I delete the first directory, the same script finds the second directory; 2. Yes, my 'include_path' is set to '.'; 3. Again, ISAPI Caching is disabled. 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/27891 -- Edit this bug report at http://bugs.php.net/?id=27891&edit=1
#26771 [Sus]: register_tick_funtions crash under threaded webservers
ID: 26771 Updated by: [EMAIL PROTECTED] Reported By: info at tphnet dot com Status: Suspended Bug Type: *General Issues Operating System: * (ZTS only!) PHP Version: 5CVS, 4CVS (2005-06-17) New Comment: I added a warning to the docs Friedhelm Previous Comments: [2005-08-10 20:02:22] [EMAIL PROTECTED] You are probably right that the tick stuff is broken in ZTS mode. But I doubt anybody is all that interested in fixing it as it is a very fringe feature in a very fringe environment. You can always hope, but chances are you will need to dig into the code yourself and send us a patch to get any movement on this. [2004-01-02 19:23:33] info at tphnet dot com Description: While searching the bug database I found some similar problems, but all were suspended. I wasn't sure if it was useful to reply to one of those (Most recent one: http://bugs.php.net/bug.php?id=26286). Well anyways, here goes: The problem is very simple. I just copy and paste the 'tick' example from the php manual into a new php file an try to execute it on my apache2 server. The apache child process crashes, restarts, crashes, restarts and eventually just stops restarting. When I comment out the line 'register_tick_function', everyting works just fine. Also, when I start the file from the CLI version of PHP it is executed without any problems. I'm using PHP 4.3.4 and Apache 2.0.48 (in conjunction with php4apache2.dll). Reproduce code: --- http://nl.php.net/manual/en/control-structures.declare.php See Example 11-1 Actual result: -- [Sat Jan 03 01:11:04 2004] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Sat Jan 03 01:11:04 2004] [notice] Parent: Created child process 3036 [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Child process is running [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Acquired the start mutex. [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Starting 250 worker threads. Small snippit from my apache2 error.log. It's filled with the above lines, the status code is the same for every restart. -- Edit this bug report at http://bugs.php.net/?id=26771&edit=1
#34358 [Csd->Opn]: Fatal error: Cannot re-assign $this(again)
ID: 34358
Updated by: [EMAIL PROTECTED]
Reported By: pacha dot shevaev at gmail dot com
-Status: Closed
+Status: Open
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.*
Assigned To: dmitry
New Comment:
I'm reopening this so that we can discuss it. I don't think we should
be silently ignoring references as that's something vague. See mail to
internals@ in a bit.
Previous Comments:
[2005-10-03 12:14:59] [EMAIL PROTECTED]
So for the curious who are wondering what "fixed" means. The & is
simply ignored in this case now.
[2005-10-03 10:22:47] [EMAIL PROTECTED]
Fixed in CVS HEAD and PHP_5_1.
[2005-10-03 09:40:14] [EMAIL PROTECTED]
It has everything to do with the new object model. Take this code:
$x = &$this;
$x = 'foo';
For performance reasons we need to catch such references when they
happen in order to prevent the object being overwritten inside itself.
It would be a bit less confusing if the error happened on the actual
assignment, but in this new object model there $x = &$this; is just as
wrong as $this = &$x since the only purpose one could have for making a
reference to $this itself is if you wanted to change it directly. In
all valid cases this should be $x = $this.
I suppose an option would be to ignore the reference in this case and
continue on. That seems to be happening with that last indirect case
you posted, but it would cost us a lookup.
[2005-09-15 15:32:13] pacha dot shevaev at gmail dot com
And why does the following code work then???
ref =& $this;
$this->ref->test();
}
function test() {
echo 'test';
}
}
$foo = new Foo();
?>
[2005-09-15 15:28:02] [EMAIL PROTECTED]
It's still bogus, you can call it a BC break if you want, but we're not
going to change this back.
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/34358
--
Edit this bug report at http://bugs.php.net/?id=34358&edit=1
#34358 [Csd]: Fatal error: Cannot re-assign $this(again)
ID: 34358
Updated by: [EMAIL PROTECTED]
Reported By: pacha dot shevaev at gmail dot com
Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.*
Assigned To: dmitry
New Comment:
So for the curious who are wondering what "fixed" means. The & is
simply ignored in this case now.
Previous Comments:
[2005-10-03 10:22:47] [EMAIL PROTECTED]
Fixed in CVS HEAD and PHP_5_1.
[2005-10-03 09:40:14] [EMAIL PROTECTED]
It has everything to do with the new object model. Take this code:
$x = &$this;
$x = 'foo';
For performance reasons we need to catch such references when they
happen in order to prevent the object being overwritten inside itself.
It would be a bit less confusing if the error happened on the actual
assignment, but in this new object model there $x = &$this; is just as
wrong as $this = &$x since the only purpose one could have for making a
reference to $this itself is if you wanted to change it directly. In
all valid cases this should be $x = $this.
I suppose an option would be to ignore the reference in this case and
continue on. That seems to be happening with that last indirect case
you posted, but it would cost us a lookup.
[2005-09-15 15:32:13] pacha dot shevaev at gmail dot com
And why does the following code work then???
ref =& $this;
$this->ref->test();
}
function test() {
echo 'test';
}
}
$foo = new Foo();
?>
[2005-09-15 15:28:02] [EMAIL PROTECTED]
It's still bogus, you can call it a BC break if you want, but we're not
going to change this back.
[2005-09-15 15:23:37] pacha dot shevaev at gmail dot com
I'm not an expert in PHP internals but there's a guy(stereofrog) on the
SitePoint forum who has a different point of
view(http://www.sitepoint.com/forums/showpost.php?p=2146304&postcount=9):
[quote]
it's 'simply ridiculous. They have a code in zend_compile.c that
handles "$this=$x" and copy-pasted that code in the function that
comples assignment by reference. This should prevent "$this=&$x" (which
is wrong), but for some reason it "prevents" "$x=&$this" as well (which
is absolutely correct). It's pure c-level bug and has nothing to do
with "new object model" and other blah-blah.
[/quote]
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/34358
--
Edit this bug report at http://bugs.php.net/?id=34358&edit=1
#34712 [Asn->Fbk]: zend.ze1_compatibility_mode = on segfault
ID: 34712
Updated by: [EMAIL PROTECTED]
Reported By: jason at jasonjustman dot com
-Status: Assigned
+Status: Feedback
Bug Type: Reproducible crash
Operating System: solars 10
PHP Version: 5CVS-2005-10-03 (snap)
Assigned To: dmitry
New Comment:
This test case must not work at all.
$ php -d "zend.ze1_compatibility_mode=1" bug34712.php
Fatal error: Cannot use 'parent' as class name as it is reserved in
/home/dmitry/php/test/bug34712.php on line 20
Without "parent" it works fine on Linux/i386.
Try to make full rebuild.
Previous Comments:
[2005-10-03 11:24:37] [EMAIL PROTECTED]
Dmitry, you did something related to this lately?
[2005-10-03 10:29:43] jason at jasonjustman dot com
last two lines of sample code should be:
$c = new child;
$a = new aggrevator($c);
[2005-10-03 10:26:29] jason at jasonjustman dot com
still present:
(gdb) n
Single stepping until exit from function child_main,
which has no line number information.
Program received signal SIGSEGV, Segmentation fault.
0xfef36f20 in zend_objects_clone_obj (zobject=0xff3fffc8) at
/export/apache/php5-200510030630/Zend/zend_objects.c:167
167 new_obj_val = zend_objects_new(&new_object,
old_object->ce TSRMLS_CC);
(gdb) backtrace
#0 0xfef36f20 in zend_objects_clone_obj (zobject=0xff3fffc8) at
/export/apache/php5-200510030630/Zend/zend_objects.c:167
#1 0xfef36de0 in zval_add_ref_or_clone (p=0x0) at
/export/apache/php5-200510030630/Zend/zend_objects.c:129
sniped
[2005-10-03 10:06:07] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-10-03 10:05:08] jason at jasonjustman dot com
Description:
segfault in solaris 10, using php-5.0.6-dev - php5-STABLE-200510030637
Program received signal SIGSEGV, Segmentation fault.
0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
181 new_obj_val = zend_objects_new(&new_object,
old_object->ce TSRMLS_CC);
(gdb) backtrace
#0 0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
#1 0xff019970 in zval_add_ref_or_clone (p=0x0) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:127
Reproduce code:
---
can't exactly pin down reproduceable code, but it seems to be something
similar to the following:
class aggrevator {
function aggrevator(&$obj) {
$this->obj = &$obj;
$this->_call();
}
function _call()
{
$this->obj->callback();
}
}
class helper {
function helper(&$obj)
{
$this->obj_ref = &$obj;
}
}
class parent { }
class child extends parent {
function callback() {
$this->_helper = new helper($this);
}
}
$c = new child;
$h = new helper($c);
Expected result:
not to crash...
Actual result:
--
f'd in the a, segfault
--
Edit this bug report at http://bugs.php.net/?id=34712&edit=1
#34716 [Opn->Fbk]: ODBCconnect & Segmentation fault
ID: 34716 Updated by: [EMAIL PROTECTED] Reported By: angelo dot courtel at cordonweb dot com -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: Linux FC4 PHP Version: 5.0.5 New Comment: 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. Previous Comments: [2005-10-03 12:09:55] angelo dot courtel at cordonweb dot com Description: Hi, I try to connect a Linux computer with an Informix database using an ODBC component. First I try, to test the ODBC connectivity with PHP, with a MySQL database. I've successfully installed unixODBC, I've been confgured it, and the ODBC driver for the MySQL databse works fine when I try to connect it in terminal mode with the isql command. But when I use the function ODBCconnect() in my PHP script, the connection failed. And if I execute the script in terminal the error is "Segmentation fault". I don't know why, the Apache server is normally configure to work with ODBC because the configure string contains : '--with-unixODBC=shared,/usr' But I think the PHP not communicate fine with ODBC. Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=34716&edit=1
#34716 [NEW]: ODBCconnect & Segmentation fault
From: angelo dot courtel at cordonweb dot com Operating system: Linux FC4 PHP version: 5.0.5 PHP Bug Type: ODBC related Bug description: ODBCconnect & Segmentation fault Description: Hi, I try to connect a Linux computer with an Informix database using an ODBC component. First I try, to test the ODBC connectivity with PHP, with a MySQL database. I've successfully installed unixODBC, I've been confgured it, and the ODBC driver for the MySQL databse works fine when I try to connect it in terminal mode with the isql command. But when I use the function ODBCconnect() in my PHP script, the connection failed. And if I execute the script in terminal the error is "Segmentation fault". I don't know why, the Apache server is normally configure to work with ODBC because the configure string contains : '--with-unixODBC=shared,/usr' But I think the PHP not communicate fine with ODBC. Actual result: -- Segmentation fault -- Edit bug report at http://bugs.php.net/?id=34716&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34716&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34716&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34716&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34716&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34716&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34716&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34716&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34716&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34716&r=support Expected behavior: http://bugs.php.net/fix.php?id=34716&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34716&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34716&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34716&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34716&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34716&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34716&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34716&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34716&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34716&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34716&r=mysqlcfg
#34643 [Asn->Csd]: wsdl default value
ID: 34643 Updated by: [EMAIL PROTECTED] Reported By: camka at email dot ee -Status: Assigned +Status: Closed Bug Type: SOAP related Operating System: linux PHP Version: 5CVS-2005-09-26 (snap) Assigned To: dmitry New Comment: Fixed Previous Comments: [2005-09-28 20:44:27] [EMAIL PROTECTED] Dmitry, not fixed? [2005-09-28 19:42:37] camka at email dot ee problem exists with the latest snapshot. [2005-09-28 13:46:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-09-27 23:42:07] camka at email dot ee if i call function with parameter=NULL explicitly $cl->get_it(NULL); the default value is returned as a result. should be NULL value. [2005-09-27 17:28:44] [EMAIL PROTECTED] The bug is fixed in CVS HEAD, PHP_5_1 and PHP_5_0. The wsdl file in report has mistakes. The fixed file can be found in CVS: ext/soap/tests/bugs/bug34643.wsdl 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/34643 -- Edit this bug report at http://bugs.php.net/?id=34643&edit=1
#26286 [Com]: Parent: child process exited with status 3221225477 -- Restarting
ID: 26286
Comment by: mark dot pearson at capita dot co dot uk
Reported By: igg10 at alu dot ua dot es
Status: No Feedback
Bug Type: Apache2 related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
I forgot to add that the script submitted in my last message:
$excel = new COM('Excel.Application')
works perfectly when run from the command line.
Previous Comments:
[2005-10-03 11:20:36] mark dot pearson at capita dot co dot uk
Description: Apache 2 crashes
PHP 4.3.11 as module on Apache 2.0.54 on Windows XP Pro
SP2.
Script which causes crash:
- START -
$excel = new COM("Excel.Application");
- END -
Apache error log output:
[Mon Oct 03 10:03:10 2005] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
Reproducable? Yes, 100%
Details:
What happens is that Dr Watson (DW20.exe) reports that 'Microsoft Excel
has encountered a problem and needs to close'.
Then approximately 30 seconds later Apache crashes with the
error log output given above. This occurs momentarily after the CPU
usage for svchost.exe jumps to 100%.
Hope this helps somebody to close this bug one way or the other.
[2005-10-03 06:03:27] valerius at iamtex dot com
Even on a Apache/2.0.54 (Win32) with PHP/5.0.4 this problem occurs very
often. So an upgrade to PHP5 would not solve the solution.
Though I can not 100% rule out, that there might be infinite loops, the
application is using an ODBC connection to ORACLE8 extensivly. I am
still checking on memory and thread resources.
[2005-09-24 20:18:13] anonymous at anon dot com
Come on... This bug has been plaguing Apache2/PHP server admins for
quite some time now, and there has yet to be any official solution.
I am currently running Apache 2.0.54 with PHP isapi module 4.4.0 on a
Windows XP Pro server. This error (3221225477) is occurring very
randomly, and does not seem to be code related.
I had this exact same problem on another server using Apache 2.0.52
with PHP 4.3.2, which was solved by switching to a beta 4.4 version of
PHP at the time. However, I can't quite remember what that exact
version was, and besides, I don't think my primary server should need a
beta version of PHP to run properly.
Could somebody please get a solution going for this bug.
[2005-09-07 20:53:42] jeffdripps at isegames dot com
Using 4.4.1 binary this problem occurs and the process restarts as
soon
as the first *.php file is requested. PHP 4.4.1 is unusable on a
multiprocessor machine running W2K and Apache2.
[2005-09-06 14:04:08] hollowlife1987 at gmail dot com
Using Apache/2.0.54 (Win32) PHP/5.0.4
This bug only happens for me when I load php_threads.dll
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/26286
--
Edit this bug report at http://bugs.php.net/?id=26286&edit=1
#34712 [Opn->Asn]: zend.ze1_compatibility_mode = on segfault
ID: 34712
Updated by: [EMAIL PROTECTED]
Reported By: jason at jasonjustman dot com
-Status: Open
+Status: Assigned
Bug Type: Reproducible crash
Operating System: solars 10
PHP Version: 5CVS-2005-10-03 (snap)
-Assigned To:
+Assigned To: dmitry
New Comment:
Dmitry, you did something related to this lately?
Previous Comments:
[2005-10-03 10:29:43] jason at jasonjustman dot com
last two lines of sample code should be:
$c = new child;
$a = new aggrevator($c);
[2005-10-03 10:26:29] jason at jasonjustman dot com
still present:
(gdb) n
Single stepping until exit from function child_main,
which has no line number information.
Program received signal SIGSEGV, Segmentation fault.
0xfef36f20 in zend_objects_clone_obj (zobject=0xff3fffc8) at
/export/apache/php5-200510030630/Zend/zend_objects.c:167
167 new_obj_val = zend_objects_new(&new_object,
old_object->ce TSRMLS_CC);
(gdb) backtrace
#0 0xfef36f20 in zend_objects_clone_obj (zobject=0xff3fffc8) at
/export/apache/php5-200510030630/Zend/zend_objects.c:167
#1 0xfef36de0 in zval_add_ref_or_clone (p=0x0) at
/export/apache/php5-200510030630/Zend/zend_objects.c:129
sniped
[2005-10-03 10:06:07] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-10-03 10:05:08] jason at jasonjustman dot com
Description:
segfault in solaris 10, using php-5.0.6-dev - php5-STABLE-200510030637
Program received signal SIGSEGV, Segmentation fault.
0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
181 new_obj_val = zend_objects_new(&new_object,
old_object->ce TSRMLS_CC);
(gdb) backtrace
#0 0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
#1 0xff019970 in zval_add_ref_or_clone (p=0x0) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:127
Reproduce code:
---
can't exactly pin down reproduceable code, but it seems to be something
similar to the following:
class aggrevator {
function aggrevator(&$obj) {
$this->obj = &$obj;
$this->_call();
}
function _call()
{
$this->obj->callback();
}
}
class helper {
function helper(&$obj)
{
$this->obj_ref = &$obj;
}
}
class parent { }
class child extends parent {
function callback() {
$this->_helper = new helper($this);
}
}
$c = new child;
$h = new helper($c);
Expected result:
not to crash...
Actual result:
--
f'd in the a, segfault
--
Edit this bug report at http://bugs.php.net/?id=34712&edit=1
#31953 [Asn->Csd]: SoapClient::setHeader
ID: 31953
Updated by: [EMAIL PROTECTED]
Reported By: wico at cnh dot nl
-Status: Assigned
+Status: Closed
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.0.3
Assigned To: dmitry
New Comment:
SoapClient::__setSoapHeaders() was added into CVS HEAD, PHP_5_1 and
PHP_5.0
Previous Comments:
[2005-02-13 11:35:23] wico at cnh dot nl
Description:
I think it's usefull to have a SoapClient::setHeader (or something like
that) for soap servers that requires static headers (mostly with
authentication parameters)
$soapHeader = new SoapHeader($ns, 'AuthHeader', array (
'Username' => $user,
'Password' => $pass
));
$soap = new SoapClient($wsdl, $options);
/* so you can do this: */
$soap->setHeader($soapHeader);
$soap->function1($parameters);
$soap->function2($parameters);
$soap->function3($parameters);
/*instead of this:*/
$soap = new SoapClient($wsdl, $options);
$soap->__soapCall('function1', $parameters, null, $soapHeader);
$soap->__soapCall('function2', $parameters, null, $soapHeader);
$soap->__soapCall('function3', $parameters, null, $soapHeader);
--
Edit this bug report at http://bugs.php.net/?id=31953&edit=1
#26286 [Com]: Parent: child process exited with status 3221225477 -- Restarting
ID: 26286
Comment by: mark dot pearson at capita dot co dot uk
Reported By: igg10 at alu dot ua dot es
Status: No Feedback
Bug Type: Apache2 related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Description: Apache 2 crashes
PHP 4.3.11 as module on Apache 2.0.54 on Windows XP Pro
SP2.
Script which causes crash:
- START -
$excel = new COM("Excel.Application");
- END -
Apache error log output:
[Mon Oct 03 10:03:10 2005] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
Reproducable? Yes, 100%
Details:
What happens is that Dr Watson (DW20.exe) reports that 'Microsoft Excel
has encountered a problem and needs to close'.
Then approximately 30 seconds later Apache crashes with the
error log output given above. This occurs momentarily after the CPU
usage for svchost.exe jumps to 100%.
Hope this helps somebody to close this bug one way or the other.
Previous Comments:
[2005-10-03 06:03:27] valerius at iamtex dot com
Even on a Apache/2.0.54 (Win32) with PHP/5.0.4 this problem occurs very
often. So an upgrade to PHP5 would not solve the solution.
Though I can not 100% rule out, that there might be infinite loops, the
application is using an ODBC connection to ORACLE8 extensivly. I am
still checking on memory and thread resources.
[2005-09-24 20:18:13] anonymous at anon dot com
Come on... This bug has been plaguing Apache2/PHP server admins for
quite some time now, and there has yet to be any official solution.
I am currently running Apache 2.0.54 with PHP isapi module 4.4.0 on a
Windows XP Pro server. This error (3221225477) is occurring very
randomly, and does not seem to be code related.
I had this exact same problem on another server using Apache 2.0.52
with PHP 4.3.2, which was solved by switching to a beta 4.4 version of
PHP at the time. However, I can't quite remember what that exact
version was, and besides, I don't think my primary server should need a
beta version of PHP to run properly.
Could somebody please get a solution going for this bug.
[2005-09-07 20:53:42] jeffdripps at isegames dot com
Using 4.4.1 binary this problem occurs and the process restarts as
soon
as the first *.php file is requested. PHP 4.4.1 is unusable on a
multiprocessor machine running W2K and Apache2.
[2005-09-06 14:04:08] hollowlife1987 at gmail dot com
Using Apache/2.0.54 (Win32) PHP/5.0.4
This bug only happens for me when I load php_threads.dll
[2005-08-02 14:55:05] nikobaer at gmx dot net
Hi,
I've the same problem, and the advice to search the bug in the own
application didn't solve it.
I can rule out an infinite repeat.
The Apache crashes in unreproducable intervals, but everytime at a
OCILogon. I've had ran the scripts at an IBM AIX Server with Apache
1.3.31 and php 4.3.11 and at a HP-UX Server with Apache 2.0.47 and php
4.2.3 without any crash. Win2k Sp4 with apache 2.0.54 and php 4.3.10
crashes randomly.
cu
nikobaer
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/26286
--
Edit this bug report at http://bugs.php.net/?id=26286&edit=1
#34678 [Asn->Csd]: __call(), is_callable() and static methods
ID: 34678
Updated by: [EMAIL PROTECTED]
Reported By: bmansion at mamasam dot com
-Status: Assigned
+Status: Closed
Bug Type: Class/Object related
Operating System: *
PHP Version: 5CVS-2005-10-01
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD, PHP_5_1 and PHP_5_0.
Previous Comments:
[2005-10-02 00:03:30] [EMAIL PROTECTED]
Dmitry, check this out.
[2005-10-01 17:48:25] bmansion at mamasam dot com
Same problem with the snapshot.
[2005-09-29 13:14:03] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-09-29 11:57:39] bmansion at mamasam dot com
Description:
I think is_callable() should check for existing methods instead of
returning true all the time when the class uses overloading. Otherwise
it becomes useless.
This is IMO particularly true for static methods checks, since __call
is defined as non-static.
Reproduce code:
---
class A {
public function __call($m, $a) {
}
}
class B extends A {
public static function foo() {
echo 'foo';
}
}
if (is_callable(array('A', 'foo'))) {
call_user_func(array('A', 'foo'));
}
Expected result:
Outputs nothing.
Actual result:
--
Fatal error: Call to undefined method A::foo()
--
Edit this bug report at http://bugs.php.net/?id=34678&edit=1
#34703 [Opn->Bgs]: late binding for static calls
ID: 34703
Updated by: [EMAIL PROTECTED]
Reported By: pornel at despammed dot com
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.1.0RC1
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2005-10-02 13:34:16] kowalski-kamil at wp dot pl
I can afford to correct code:
class Base
{
static function test1() {self::test2();}
static function test2() {echo 'failure';}
}
class Child extends Base
{
static function test2() {echo 'success';}
}
Child::test1();
pornel - it's ok?
[2005-10-02 13:16:37] kowalski-kamil at wp dot pl
How do you want to use Base, if Child class is not linked to it? :D
lol!
[2005-10-02 00:18:34] pornel at despammed dot com
Ooops, code example should have "class Child extends Base" and
"Child::test1()", ofcourse.
[2005-10-02 00:16:33] pornel at despammed dot com
Description:
In PHP it is not possible to write base class for singleton and similar
programming patterns.
I know it is intended behavior and backwards compatibility may make
changes difficult, but there is significant number of complaints about
current implementation:
http://bugs.php.net/bug.php?id=30235
http://bugs.php.net/bug.php?id=30934
http://bugs.php.net/bug.php?id=30423
http://bugs.php.net/bug.php?id=19376
http://bugs.php.net/bug.php?id=26930
http://bugs.php.net/bug.php?id=28442
http://bugs.php.net/bug.php?id=29647
and I'd like to add another one.
I'm trying to write functionality that works similar to ActiveRow
implementation in RubyOnRails, but the way in which PHP handles static
methods and inheritance makes such implementation impossible.
I hope you could implement late binding for static calls and fields.
It could be used with this:: construct instead of self::, which may be
emulated for backwards compatiblity.
Reproduce code:
---
class Base
{
static function test1() {self::test2();}
static function test2() {echo 'failure';}
}
class Child
{
static function test2() {echo 'success';}
}
Child::test();
Expected result:
success
Actual result:
--
failure
backtrace doesn't contain reference to Child class (that would be
enough for a workaround).
--
Edit this bug report at http://bugs.php.net/?id=34703&edit=1
#34714 [NEW]: set Default Fetch Mode in PDO class
From: mcka at gmx dot net Operating system: Irrelevant PHP version: 5.1.0RC1 PHP Bug Type: PDO related Bug description: set Default Fetch Mode in PDO class Description: If you have a lot of queries in a script and you don't want to use the default PDO::FETCH_BOTH Mode (which returns an array with numbers and col-name indexes) - perhaps you want do use PDO::FETCH_OBJ or PDO::FETCH_ASSOC... - you have to set the fetch mode again and again for every query/statement. If there would be something like: PDO::setDefaultFetchMode() or PDO::setAttribute(PDO::DEFAULT_FETCH_MODE...) you could set the fetch mode once in the script. -- Edit bug report at http://bugs.php.net/?id=34714&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34714&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34714&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34714&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34714&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34714&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34714&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34714&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34714&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34714&r=support Expected behavior: http://bugs.php.net/fix.php?id=34714&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34714&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34714&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34714&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34714&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34714&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34714&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34714&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34714&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34714&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34714&r=mysqlcfg
#34712 [Opn]: zend.ze1_compatibility_mode = on segfault
ID: 34712
User updated by: jason at jasonjustman dot com
Reported By: jason at jasonjustman dot com
Status: Open
Bug Type: Reproducible crash
Operating System: solars 10
PHP Version: 5CVS-2005-10-03 (snap)
New Comment:
last two lines of sample code should be:
$c = new child;
$a = new aggrevator($c);
Previous Comments:
[2005-10-03 10:26:29] jason at jasonjustman dot com
still present:
(gdb) n
Single stepping until exit from function child_main,
which has no line number information.
Program received signal SIGSEGV, Segmentation fault.
0xfef36f20 in zend_objects_clone_obj (zobject=0xff3fffc8) at
/export/apache/php5-200510030630/Zend/zend_objects.c:167
167 new_obj_val = zend_objects_new(&new_object,
old_object->ce TSRMLS_CC);
(gdb) backtrace
#0 0xfef36f20 in zend_objects_clone_obj (zobject=0xff3fffc8) at
/export/apache/php5-200510030630/Zend/zend_objects.c:167
#1 0xfef36de0 in zval_add_ref_or_clone (p=0x0) at
/export/apache/php5-200510030630/Zend/zend_objects.c:129
sniped
[2005-10-03 10:06:07] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-10-03 10:05:08] jason at jasonjustman dot com
Description:
segfault in solaris 10, using php-5.0.6-dev - php5-STABLE-200510030637
Program received signal SIGSEGV, Segmentation fault.
0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
181 new_obj_val = zend_objects_new(&new_object,
old_object->ce TSRMLS_CC);
(gdb) backtrace
#0 0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
#1 0xff019970 in zval_add_ref_or_clone (p=0x0) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:127
Reproduce code:
---
can't exactly pin down reproduceable code, but it seems to be something
similar to the following:
class aggrevator {
function aggrevator(&$obj) {
$this->obj = &$obj;
$this->_call();
}
function _call()
{
$this->obj->callback();
}
}
class helper {
function helper(&$obj)
{
$this->obj_ref = &$obj;
}
}
class parent { }
class child extends parent {
function callback() {
$this->_helper = new helper($this);
}
}
$c = new child;
$h = new helper($c);
Expected result:
not to crash...
Actual result:
--
f'd in the a, segfault
--
Edit this bug report at http://bugs.php.net/?id=34712&edit=1
#34712 [Fbk->Opn]: zend.ze1_compatibility_mode = on segfault
ID: 34712
User updated by: jason at jasonjustman dot com
Reported By: jason at jasonjustman dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: solars 10
PHP Version: 5CVS-2005-10-03 (snap)
New Comment:
still present:
(gdb) n
Single stepping until exit from function child_main,
which has no line number information.
Program received signal SIGSEGV, Segmentation fault.
0xfef36f20 in zend_objects_clone_obj (zobject=0xff3fffc8) at
/export/apache/php5-200510030630/Zend/zend_objects.c:167
167 new_obj_val = zend_objects_new(&new_object,
old_object->ce TSRMLS_CC);
(gdb) backtrace
#0 0xfef36f20 in zend_objects_clone_obj (zobject=0xff3fffc8) at
/export/apache/php5-200510030630/Zend/zend_objects.c:167
#1 0xfef36de0 in zval_add_ref_or_clone (p=0x0) at
/export/apache/php5-200510030630/Zend/zend_objects.c:129
sniped
Previous Comments:
[2005-10-03 10:06:07] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-10-03 10:05:08] jason at jasonjustman dot com
Description:
segfault in solaris 10, using php-5.0.6-dev - php5-STABLE-200510030637
Program received signal SIGSEGV, Segmentation fault.
0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
181 new_obj_val = zend_objects_new(&new_object,
old_object->ce TSRMLS_CC);
(gdb) backtrace
#0 0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
#1 0xff019970 in zval_add_ref_or_clone (p=0x0) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:127
Reproduce code:
---
can't exactly pin down reproduceable code, but it seems to be something
similar to the following:
class aggrevator {
function aggrevator(&$obj) {
$this->obj = &$obj;
$this->_call();
}
function _call()
{
$this->obj->callback();
}
}
class helper {
function helper(&$obj)
{
$this->obj_ref = &$obj;
}
}
class parent { }
class child extends parent {
function callback() {
$this->_helper = new helper($this);
}
}
$c = new child;
$h = new helper($c);
Expected result:
not to crash...
Actual result:
--
f'd in the a, segfault
--
Edit this bug report at http://bugs.php.net/?id=34712&edit=1
#34358 [Bgs->Csd]: Fatal error: Cannot re-assign $this(again)
ID: 34358
Updated by: [EMAIL PROTECTED]
Reported By: pacha dot shevaev at gmail dot com
-Status: Bogus
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.*
-Assigned To:
+Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_1.
Previous Comments:
[2005-10-03 09:40:14] [EMAIL PROTECTED]
It has everything to do with the new object model. Take this code:
$x = &$this;
$x = 'foo';
For performance reasons we need to catch such references when they
happen in order to prevent the object being overwritten inside itself.
It would be a bit less confusing if the error happened on the actual
assignment, but in this new object model there $x = &$this; is just as
wrong as $this = &$x since the only purpose one could have for making a
reference to $this itself is if you wanted to change it directly. In
all valid cases this should be $x = $this.
I suppose an option would be to ignore the reference in this case and
continue on. That seems to be happening with that last indirect case
you posted, but it would cost us a lookup.
[2005-09-15 15:32:13] pacha dot shevaev at gmail dot com
And why does the following code work then???
ref =& $this;
$this->ref->test();
}
function test() {
echo 'test';
}
}
$foo = new Foo();
?>
[2005-09-15 15:28:02] [EMAIL PROTECTED]
It's still bogus, you can call it a BC break if you want, but we're not
going to change this back.
[2005-09-15 15:23:37] pacha dot shevaev at gmail dot com
I'm not an expert in PHP internals but there's a guy(stereofrog) on the
SitePoint forum who has a different point of
view(http://www.sitepoint.com/forums/showpost.php?p=2146304&postcount=9):
[quote]
it's 'simply ridiculous. They have a code in zend_compile.c that
handles "$this=$x" and copy-pasted that code in the function that
comples assignment by reference. This should prevent "$this=&$x" (which
is wrong), but for some reason it "prevents" "$x=&$this" as well (which
is absolutely correct). It's pure c-level bug and has nothing to do
with "new object model" and other blah-blah.
[/quote]
[2005-09-15 14:27:03] [EMAIL PROTECTED]
NOTE: This is about PHP 5. It might have worked in PHP 4 but it does
not and will not work in PHP 5.
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/34358
--
Edit this bug report at http://bugs.php.net/?id=34358&edit=1
#34712 [Opn->Fbk]: zend.ze1_compatibility_mode = on segfault
ID: 34712
Updated by: [EMAIL PROTECTED]
Reported By: jason at jasonjustman dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: solars 10
PHP Version: 5CVS-2005-10-03 (snap)
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
[2005-10-03 10:05:08] jason at jasonjustman dot com
Description:
segfault in solaris 10, using php-5.0.6-dev - php5-STABLE-200510030637
Program received signal SIGSEGV, Segmentation fault.
0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
181 new_obj_val = zend_objects_new(&new_object,
old_object->ce TSRMLS_CC);
(gdb) backtrace
#0 0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
#1 0xff019970 in zval_add_ref_or_clone (p=0x0) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:127
Reproduce code:
---
can't exactly pin down reproduceable code, but it seems to be something
similar to the following:
class aggrevator {
function aggrevator(&$obj) {
$this->obj = &$obj;
$this->_call();
}
function _call()
{
$this->obj->callback();
}
}
class helper {
function helper(&$obj)
{
$this->obj_ref = &$obj;
}
}
class parent { }
class child extends parent {
function callback() {
$this->_helper = new helper($this);
}
}
$c = new child;
$h = new helper($c);
Expected result:
not to crash...
Actual result:
--
f'd in the a, segfault
--
Edit this bug report at http://bugs.php.net/?id=34712&edit=1
#34712 [NEW]: zend.ze1_compatibility_mode = on segfault
From: jason at jasonjustman dot com
Operating system: solars 10
PHP version: 5CVS-2005-10-03 (snap)
PHP Bug Type: Reproducible crash
Bug description: zend.ze1_compatibility_mode = on segfault
Description:
segfault in solaris 10, using php-5.0.6-dev - php5-STABLE-200510030637
Program received signal SIGSEGV, Segmentation fault.
0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
181 new_obj_val = zend_objects_new(&new_object, old_object->ce
TSRMLS_CC);
(gdb) backtrace
#0 0xff019b38 in zend_objects_clone_obj (zobject=0xff3fffd8) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:181
#1 0xff019970 in zval_add_ref_or_clone (p=0x0) at
/export/apache/php5-STABLE-200510030637/Zend/zend_objects.c:127
Reproduce code:
---
can't exactly pin down reproduceable code, but it seems to be something
similar to the following:
class aggrevator {
function aggrevator(&$obj) {
$this->obj = &$obj;
$this->_call();
}
function _call()
{
$this->obj->callback();
}
}
class helper {
function helper(&$obj)
{
$this->obj_ref = &$obj;
}
}
class parent { }
class child extends parent {
function callback() {
$this->_helper = new helper($this);
}
}
$c = new child;
$h = new helper($c);
Expected result:
not to crash...
Actual result:
--
f'd in the a, segfault
--
Edit bug report at http://bugs.php.net/?id=34712&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34712&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34712&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34712&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34712&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34712&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34712&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34712&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34712&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34712&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34712&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34712&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34712&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34712&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34712&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34712&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34712&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34712&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34712&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34712&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34712&r=mysqlcfg
#34695 [Opn->Bgs]: preg_replace(): {}-expresion overflow
ID: 34695
User updated by: php at koterov dot ru
Reported By: php at koterov dot ru
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 4.4.0
New Comment:
You are right:
> pcretest.exe
re> / ( (?: [^<] | < [^>]* >){1,1000}) .* /xs
Failed: regular expression too large at offset 0
Don't know why, but - this RE was not eaten by PCRE lib.
Sorry.
Previous Comments:
[2005-10-03 08:49:27] [EMAIL PROTECTED]
Perl doesn't use libpcre at all. Try this with the command-line pcre
test client. If it works there and not in PHP, then you can blame PHP.
[2005-10-03 08:42:28] php at koterov dot ru
First. Quoting this article:
<<<
There are some size limitations in PCRE but it is hoped that
they will
never in practice be relevant.
The maximum length of a compiled pattern is 65539 (sic) bytes
if PCRE
is compiled with the default internal linkage size of 2. If you
want to
process regular expressions that are truly enormous, you can
compile
PCRE with an internal linkage size of 3 or 4 (see the README
file in
the source distribution and the pcrebuild documentation for
details).
In these cases the limit is substantially larger. However, the
speed
of execution will be slower.
All values in repeating quantifiers must be less than 65536.
The maxi-
mum number of capturing subpatterns is 65535.
There is no limit to the number of non-capturing subpatterns,
but the
maximum depth of nesting of all kinds of parenthesized
subpattern,
including capturing subpatterns, assertions, and other types of
subpat-
tern, is 200.
The maximum length of a subject string is the largest positive
number
that an integer variable can hold. However, when using the
traditional
matching function, PCRE uses recursion to handle subpatterns and
indef-
inite repetition. This means that the available stack space may
limit
the size of a subject string that can be processed by certain
patterns.
>>>
Which limitation did you mean? As you can see, expression
/((?:[^<]|<[^>]*>){1,1000}).*/xs
does not break any limitation bounds quoted above.
Second. The same RE works in Perl 5.6 and 5.8 even with {1,1}
repeating quantifiers. But Perl 5.6 uses wittingly older version of
libpcre than PHP 4.4.0. So, possibly source of bug is not in PCRE, but
in PHP?..
Third. It is NOT a backtracking overflow, because for string with 1001
"a"'s this expression does not work too.
[2005-10-02 13:00:58] [EMAIL PROTECTED]
RTFM: "You should be aware of some limitations of PCRE. Read
http://www.pcre.org/pcre.txt for more info."
[2005-10-02 08:46:36] php at koterov dot ru
Snapshot does not work too.
[2005-10-01 10:10:46] [EMAIL PROTECTED]
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
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/34695
--
Edit this bug report at http://bugs.php.net/?id=34695&edit=1
#34358 [Bgs]: Fatal error: Cannot re-assign $this(again)
ID: 34358
Updated by: [EMAIL PROTECTED]
Reported By: pacha dot shevaev at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.*
New Comment:
It has everything to do with the new object model. Take this code:
$x = &$this;
$x = 'foo';
For performance reasons we need to catch such references when they
happen in order to prevent the object being overwritten inside itself.
It would be a bit less confusing if the error happened on the actual
assignment, but in this new object model there $x = &$this; is just as
wrong as $this = &$x since the only purpose one could have for making a
reference to $this itself is if you wanted to change it directly. In
all valid cases this should be $x = $this.
I suppose an option would be to ignore the reference in this case and
continue on. That seems to be happening with that last indirect case
you posted, but it would cost us a lookup.
Previous Comments:
[2005-09-15 15:32:13] pacha dot shevaev at gmail dot com
And why does the following code work then???
ref =& $this;
$this->ref->test();
}
function test() {
echo 'test';
}
}
$foo = new Foo();
?>
[2005-09-15 15:28:02] [EMAIL PROTECTED]
It's still bogus, you can call it a BC break if you want, but we're not
going to change this back.
[2005-09-15 15:23:37] pacha dot shevaev at gmail dot com
I'm not an expert in PHP internals but there's a guy(stereofrog) on the
SitePoint forum who has a different point of
view(http://www.sitepoint.com/forums/showpost.php?p=2146304&postcount=9):
[quote]
it's 'simply ridiculous. They have a code in zend_compile.c that
handles "$this=$x" and copy-pasted that code in the function that
comples assignment by reference. This should prevent "$this=&$x" (which
is wrong), but for some reason it "prevents" "$x=&$this" as well (which
is absolutely correct). It's pure c-level bug and has nothing to do
with "new object model" and other blah-blah.
[/quote]
[2005-09-15 14:27:03] [EMAIL PROTECTED]
NOTE: This is about PHP 5. It might have worked in PHP 4 but it does
not and will not work in PHP 5.
[2005-09-15 13:37:28] pacha dot shevaev at gmail dot com
I still find it a bug. I need a reference to $this for BC with PHP4 in
the following piece of code:
function &getRootDataSource() {
$root =& $this;
while ($root->parent != NULL) {
$root =& $root->parent;
}
return $root;
}
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/34358
--
Edit this bug report at http://bugs.php.net/?id=34358&edit=1
#34707 [WFx]: Cannot reuse XML parser, get "junk after document element" error message
ID: 34707 User updated by: apc at hotmail dot kg Reported By: apc at hotmail dot kg Status: Wont fix Bug Type: XML related Operating System: Windows XP Pro SP2 PHP Version: 4.4.0 New Comment: It's very bad for performance - creating new parser takes long time relatively to parse time... So if I have to do 10 parses I'll spend 0.05 sec creating parsers and only 0.001 sec in actual parsing. Also - for what I have ability to create and destroy parsers without reusing created?.. And, at last - no single note about "You cannot use parser twice!" Previous Comments: [2005-10-03 08:46:30] [EMAIL PROTECTED] Simply, you can't use the same parser twice... Just make a new one for the second parsing. [2005-10-02 16:58:43] apc at hotmail dot kg Description: When I try to parse XML into struct twice using the same parser - second attempt fails. Reproduce code: --- "; var_dump(xml_parse_into_struct ($th, $XMLContent, $V)); ; echo "Result size: ".sizeof($V); echo "Error code: ".$ec=xml_get_error_code($th); echo "Error text: ".xml_error_string($ec); echo ""; var_dump(xml_parse_into_struct ($th, $XMLContent, $V)); ; echo "Result size: ".sizeof($V); echo "Error code: ".$ec=xml_get_error_code($th); echo "Error text: ".xml_error_string($ec); ?> Expected result: int(1) Result size: 301 Error code: 0 Error text: int(1) Result size: 301 Error code: 0 Error text: Actual result: -- int(1) Result size: 301 Error code: 0 Error text: int(0) Result size: 0 Error code: 9 Error text: junk after document element -- Edit this bug report at http://bugs.php.net/?id=34707&edit=1
