#34530 [Bgs]: preg_match result depends on input string length when it should not
ID: 34530 User updated by: php at clayst dot com Reported By: php at clayst dot com Status: Bogus Bug Type: PCRE related Operating System: Windows XP Pro PHP Version: 4.4.0 New Comment: A specific question -- the PCRE file you referred to documents 4 limitations: (1) 64KB in a compiled pattern under normal circumstances; (2) 64K max for repeating quantifiers, 64K max capturing subpatterns; (3) Max subpattern nesting depth 200; and (4) Stack space may limit the size of a subject string due to use of recursion for subpatterns and repetition. As far as I can see only (4) could apply to this case. Is that what you are referring to? If so, why is there no crash and no error but merely a silent incorrect return from preg_match? Does either PCRE or PHP fail to notice a stack overflow? Previous Comments: [2005-09-17 05:10:41] php at clayst dot com There is no need to be nasty, particularly since you have no idea what I did and did not do and in fact your deductions are wrong on both counts. I am a developer myself and I know better than to submit a bug report without trying to see if someone else found the same thing first. You have the advantage of knowing about the prior reports which make make the similarities obvious. I did not. I searched the bugs database several times using the advanced search page and several different sets of keywords and other conditions. I did not find anything that looked like this bug. I also reviewed each of the reports that the system pulled up on my initial submission as potentially similar bugs and found nothing that matched. I also read the Pattern Syntax and preg_match pages of the manual, multiple times in fact, and have read them many times before. I saw several statements that explain about various types of loops, stack space, etc. Some of them might apply but there is no way to tell which, if any, do apply. More generally, IMO PHP should not fail silently and relatively randomly (in this case depending on the length of an input to a function) due to some kind of overflow condition. In the software I write I'd consider that to be a bug, whether it occurred in an external library I chose to use or in my own code. If a limitation can't be worked around that's completely fine and not unusual, but IMO running into it should produce an error, not silence. PHP developers might make a different choice and decide that silent failure in this case is within their design parameters but then that should be documented. I don't see that it is. [2005-09-16 21:02:10] [EMAIL PROTECTED] Thank you for not searching the bug database before submitting yet another bogus bug report about this issue. Read about the limitations in PCRE library here: http://www.pcre.org/pcre.txt This is not PHP bug, just PCRE library's limitation. (also mentioned in the manual, if you had bothered reading it) [2005-09-16 19:27:39] php at clayst dot com Description: A regular expression which involves some unnecessary extra loops in execution will give the proper result (a match) with a given input string but will fail to match when it should if the input is one character longer. In the example, the pattern is intended to match a string which contains: (1) An optional substring consisting of one or more groups of word characters separated by dashes, with the entire substring (if present) terminated by a period; followed by (2) A required substring consisting of one or more groups of word characters separated by dashes. The 'good' pattern shown does this properly. The 'bad' pattern incorrectly makes the dashes between substrings optional -- i.e. there's an extra '?" after the '-' in both portions of the pattern. This error makes the pattern inefficient as there are many possible matching substrings, but I believe it should still match a simple alpha string. In fact it fails to match if the input string is more than 20 characters long. Reproduce code: --- Expected result: All matches should return a 1 because they all match the given string. Actual result: -- The first three matches return a 1 but the last returns a 0: Good pattern, 20 characters: 1 Good pattern, 21 characters: 1 Bad pattern, 20 characters: 1 Bad pattern, 21 characters: 0 -- Edit this bug report at http://bugs.php.net/?id=34530&edit=1
#34530 [Bgs]: preg_match result depends on input string length when it should not
ID: 34530 User updated by: php at clayst dot com Reported By: php at clayst dot com Status: Bogus Bug Type: PCRE related Operating System: Windows XP Pro PHP Version: 4.4.0 New Comment: There is no need to be nasty, particularly since you have no idea what I did and did not do and in fact your deductions are wrong on both counts. I am a developer myself and I know better than to submit a bug report without trying to see if someone else found the same thing first. You have the advantage of knowing about the prior reports which make make the similarities obvious. I did not. I searched the bugs database several times using the advanced search page and several different sets of keywords and other conditions. I did not find anything that looked like this bug. I also reviewed each of the reports that the system pulled up on my initial submission as potentially similar bugs and found nothing that matched. I also read the Pattern Syntax and preg_match pages of the manual, multiple times in fact, and have read them many times before. I saw several statements that explain about various types of loops, stack space, etc. Some of them might apply but there is no way to tell which, if any, do apply. More generally, IMO PHP should not fail silently and relatively randomly (in this case depending on the length of an input to a function) due to some kind of overflow condition. In the software I write I'd consider that to be a bug, whether it occurred in an external library I chose to use or in my own code. If a limitation can't be worked around that's completely fine and not unusual, but IMO running into it should produce an error, not silence. PHP developers might make a different choice and decide that silent failure in this case is within their design parameters but then that should be documented. I don't see that it is. Previous Comments: [2005-09-16 21:02:10] [EMAIL PROTECTED] Thank you for not searching the bug database before submitting yet another bogus bug report about this issue. Read about the limitations in PCRE library here: http://www.pcre.org/pcre.txt This is not PHP bug, just PCRE library's limitation. (also mentioned in the manual, if you had bothered reading it) [2005-09-16 19:27:39] php at clayst dot com Description: A regular expression which involves some unnecessary extra loops in execution will give the proper result (a match) with a given input string but will fail to match when it should if the input is one character longer. In the example, the pattern is intended to match a string which contains: (1) An optional substring consisting of one or more groups of word characters separated by dashes, with the entire substring (if present) terminated by a period; followed by (2) A required substring consisting of one or more groups of word characters separated by dashes. The 'good' pattern shown does this properly. The 'bad' pattern incorrectly makes the dashes between substrings optional -- i.e. there's an extra '?" after the '-' in both portions of the pattern. This error makes the pattern inefficient as there are many possible matching substrings, but I believe it should still match a simple alpha string. In fact it fails to match if the input string is more than 20 characters long. Reproduce code: --- Expected result: All matches should return a 1 because they all match the given string. Actual result: -- The first three matches return a 1 but the last returns a 0: Good pattern, 20 characters: 1 Good pattern, 21 characters: 1 Bad pattern, 20 characters: 1 Bad pattern, 21 characters: 0 -- Edit this bug report at http://bugs.php.net/?id=34530&edit=1
#33966 [Asn->Csd]: wrong use of reflectionproperty causes a segfault
ID: 33966 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Class/Object related Operating System: * PHP Version: 5CVS-2005-08-02 Assigned To: helly New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-08-02 20:52:23] [EMAIL PROTECTED] This happens because METHOD_NOTSTATIC just checks this_ptr presence and doesn't check it's class entry. So I'd propose this patch: http://tony2001.phpclub.net/dev/tmp/bug33966.diff [2005-08-02 14:23:59] [EMAIL PROTECTED] Description: When (ab)using the ReflectionProperty class' methods as static, it segfaults. Reproduce code: --- foo; ?> Actual result: -- 0x083c2bdb in _property_check_flag (ht=0, return_value=0x878cfd4, return_value_ptr=0x0, this_ptr=0x878c714, return_value_used=1, mask=256) at /dat/dev/php/php-5.1dev/Zend/zend_reflection_api.c:3359 3359RETURN_BOOL(ref->prop->flags & mask); (gdb) bt #0 0x083c2bdb in _property_check_flag (ht=0, return_value=0x878cfd4, return_value_ptr=0x0, this_ptr=0x878c714, return_value_used=1, mask=256) at /dat/dev/php/php-5.1dev/Zend/zend_reflection_api.c:3359 #1 0x083c2c24 in zif_reflection_property_isPublic (ht=0, return_value=0x878cfd4, return_value_ptr=0x0, this_ptr=0x878c714, return_value_used=1) at /dat/dev/php/php-5.1dev/Zend/zend_reflection_api.c:3366 #2 0x083c6309 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffd090) at zend_vm_execute.h:184 #3 0x083c692d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffd090) at zend_vm_execute.h:299 #4 0x083c5f8a in execute (op_array=0x878dd34) at zend_vm_execute.h:87 #5 0x0838edc6 in zend_call_function (fci=0xbfffd260, fci_cache=0xbfffd220) at /dat/dev/php/php-5.1dev/Zend/zend_execute_API.c:871 #6 0x083aee9d in zend_call_method (object_pp=0xbfffd2f0, obj_ce=0x878c36c, fn_proxy=0x878c44c, function_name=0x85cfd54 "__get", function_name_len=5, retval_ptr_ptr=0xbfffd2e4, param_count=1, arg1=0x878cea4, arg2=0x0) at /dat/dev/php/php-5.1dev/Zend/zend_interfaces.c:87 #7 0x083b4e26 in zend_std_call_getter (object=0x878c714, member=0x878cea4) at /dat/dev/php/php-5.1dev/Zend/zend_object_handlers.c:72 #8 0x083b576e in zend_std_read_property (object=0x878c714, member=0x878b148, type=0) at /dat/dev/php/php-5.1dev/Zend/zend_object_handlers.c:305 #9 0x083ff3f9 in zend_fetch_property_address_read_helper_SPEC_CV_CONST ( type=0, execute_data=0xbfffd440) at zend_vm_execute.h:20491 #10 0x083ff510 in ZEND_FETCH_OBJ_R_SPEC_CV_CONST_HANDLER ( execute_data=0xbfffd440) at zend_vm_execute.h:20513 #11 0x083c5f8a in execute (op_array=0x8786de4) at zend_vm_execute.h:87 #12 0x0839b2fb in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /dat/dev/php/php-5.1dev/Zend/zend.c:1087 #13 0x08350fc4 in php_execute_script (primary_file=0xb8b0) at /dat/dev/php/php-5.1dev/main/main.c:1672 #14 0x0841325c in main (argc=1, argv=0xb994) at /dat/dev/php/php-5.1dev/sapi/cli/php_cli.c:1039 (gdb) print *ref Cannot access memory at address 0x2a8fcc84 -- Edit this bug report at http://bugs.php.net/?id=33966&edit=1
#33941 [Asn]: overloading not working with arrays not stored as arrays
ID: 33941 Updated by: [EMAIL PROTECTED] Reported By: gordon at heydon dot com dot au Status: Assigned Bug Type: Class/Object related Operating System: * PHP Version: 5CVS-2005-08-02 Assigned To: dmitry New Comment: For the record, I don't see any memleaks with 5.0/5.1/6.0 now. Previous Comments: [2005-09-09 14:18:51] fanfatal at fanfatal dot pl In PHP 5.0.4 this bug has been corrected Greatings ;-) ... [2005-08-18 09:27:48] [EMAIL PROTECTED] Can we atleast make sure it gives a nice big warning on this? Now it merely produces some leaks: bar[1] = 42; produces: [EMAIL PROTECTED]:~$ php-6.0dev /tmp/f.php /dat/dev/php/php-6.0dev/Zend/zend_execute.c(827) : Freeing 0x08796494 (16 bytes), script=/tmp/f.php /dat/dev/php/php-6.0dev/Zend/zend_execute.c(1005) : Freeing 0x0879643C (35 bytes), script=/tmp/f.php /dat/dev/php/php-6.0dev/Zend/zend_hash.c(383) : Actual location (location was relayed) /dat/dev/php/php-6.0dev/Zend/zend_execute.c(1060) : Freeing 0x087963DC (44 bytes), script=/tmp/f.php /dat/dev/php/php-6.0dev/Zend/zend_API.c(712) : Actual location (location was relayed) Last leak repeated 1 time /dat/dev/php/php-6.0dev/Zend/zend_execute.c(1057) : Freeing 0x087842CC (16 bytes), script=/tmp/f.php === Total 5 memory leaks detected === [2005-08-05 12:06:17] [EMAIL PROTECTED] This is not fixable :( [2005-08-05 11:44:23] [EMAIL PROTECTED] Dmitry "The Fixer", please check this out. [2005-08-01 12:42:33] stochnagara at hotmail dot com I've tested this with the lastest win32 binary package. The bug is still present. When __get prototype is changed to function & __get everything works fine. 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/33941 -- Edit this bug report at http://bugs.php.net/?id=33941&edit=1
#33931 [Asn->Fbk]: __get and __set don't handle arrays correctly
ID: 33931
Updated by: [EMAIL PROTECTED]
Reported By: wkonkel at gmail dot com
-Status: Assigned
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS-2005-08-19
Assigned To: dmitry
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
I'm unable to replicate it anymore.
Previous Comments:
[2005-08-01 09:51:38] [EMAIL PROTECTED]
Dmitry, could you check it plz ?
[2005-07-31 20:01:33] [EMAIL PROTECTED]
And this with Sean's code:
PHP Notice: Undefined property: A::$foo in /home/jani/t.php on line
8
Notice: Undefined property: A::$foo in /home/jani/t.php on line 8
PHP Notice: Undefined property: A::$foo in /home/jani/t.php on line
9
Notice: Undefined property: A::$foo in /home/jani/t.php on line 9
PHP Notice: Undefined variable: undefined in /home/jani/t.php on line
10
Notice: Undefined variable: undefined in /home/jani/t.php on line 10
NULL
array(2) {
["bar1"]=>
string(5) "oink1"
[0]=>
string(4) "blah"
}
/usr/src/php/php5/Zend/zend_variables.h(45) : Freeing 0x088ED84C (6
bytes), script=t.php
/usr/src/php/php5/Zend/zend_variables.c(120) : Actual location
(location was relayed)
Last leak repeated 1 time
/usr/src/php/php5/Zend/zend_execute.c(798) : Freeing 0x088ED80C (16
bytes), script=t.php
Last leak repeated 1 time
/usr/src/php/php5/Zend/zend_hash.c(242) : Freeing 0x088ED7B4 (40
bytes), script=t.php
Last leak repeated 1 time
/usr/src/php/php5/Zend/zend_execute.c(1031) : Freeing 0x088ED754 (44
bytes), script=t.php
/usr/src/php/php5/Zend/zend_API.c(712) : Actual location (location was
relayed)
Last leak repeated 3 times
/usr/src/php/php5/Zend/zend_execute.c(1028) : Freeing 0x088DE7CC (16
bytes), script=t.php
=== Total 11 memory leaks detected ===
[2005-07-31 20:00:32] [EMAIL PROTECTED]
Output with CVS HEAD:
Array
(
[foo2] => bar2
[foo3] => bar3
[0] => blah
)
/usr/src/php/php5/Zend/zend_hash.c(242) : Freeing 0x088EF6FC (40
bytes), script=t.php
Last leak repeated 2 times
/usr/src/php/php5/Zend/zend_variables.h(45) : Freeing 0x088EF664 (5
bytes), script=t.php
/usr/src/php/php5/Zend/zend_variables.c(120) : Actual location
(location was relayed)
Last leak repeated 2 times
/usr/src/php/php5/Zend/zend_execute.c(798) : Freeing 0x088EF624 (16
bytes), script=t.php
Last leak repeated 2 times
/usr/src/php/php5/Zend/zend_execute.c(1031) : Freeing 0x088EF56C (44
bytes), script=t.php
/usr/src/php/php5/Zend/zend_API.c(712) : Actual location (location was
relayed)
Last leak repeated 3 times
/usr/src/php/php5/Zend/zend_execute.c(1028) : Freeing 0x088DE7CC (16
bytes), script=t.php
=== Total 14 memory leaks detected ===
[2005-07-30 23:52:13] [EMAIL PROTECTED]
Happens to me on 5.0.3 as well.
Shorter code:
data[$key] = $val;
}
}
$A = new A();
$A->foo['bar'] = 'oink';
$A->foo['bar1'] = 'oink1';
var_dump($undefined);
$undefined[] = 'blah';
var_dump($undefined);
?>
Outputs:
NULL
array(2) {
["bar1"]=>
string(5) "oink1"
[0]=>
string(4) "blah"
}
[2005-07-30 22:39:55] wkonkel at gmail dot com
Description:
The __set and __get don't seem to handle arrays correctly. What's even
worse, is it adds data to memory which is allocated at a later time
($boz gets foo2 and foo3 of $myObj). The code example speaks for
itself.
Reproduce code:
---
data[$key] = $val;
}
function __get($key) {
return $this->data[$key];
}
}
$myObj = new buggy();
$myObj->somevar['foo1'] = 'bar1';
$myObj->somevar['foo2'] = 'bar2';
$myObj->somevar['foo3'] = 'bar3';
$boz[] = 'blah';
print_r($boz);
?>
Expected result:
Array
(
[0] => blah
)
Actual result:
--
Array
(
[foo2] => bar2
[foo3] => bar3
[0] => blah
)
--
Edit this bug report at http://bugs.php.net/?id=33931&edit=1
#34536 [Opn->Fbk]: ini_get('register_globals') does not return correct value
ID: 34536
Updated by: [EMAIL PROTECTED]
Reported By: leoli at optonline dot net
-Status: Open
+Status: Feedback
Bug Type: PHP options/info functions
Operating System: Windows XP
PHP Version: 5.0.5
New Comment:
Try this:
php.exe -n -d register_globals=1 -r
'var_dump(ini_get("register_globals"));'
or
php -n -d register_globals=1 -r
Previous Comments:
[2005-09-17 00:36:17] leoli at optonline dot net
I used php5.0-win32-latest.zip to reinstall PHP5
I used the follow code
result:
string(0) "" string(0) "" string(1) "1" string(1) "1"
The return values for
display_errors and y2k_compliance
are correct
[2005-09-16 21:36:40] [EMAIL PROTECTED]
Also, please use var_dump(ini_get("register_globals")); instead of
echo.
[2005-09-16 21:35:50] [EMAIL PROTECTED]
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
Can't reproduce.
[2005-09-16 21:31:37] leoli at optonline dot net
Description:
ini_get('register_globals') always return empty string no matter what
value is set in php.ini.
ini_get() function returns all other values defined in php.ini
correctly.
Reproduce code:
---
/*
Our php.ini contains the following settings:
register_globals = On
*/
echo 'register_globals = ' . ini_get('register_globals') . "\n";
Expected result:
register_globals = 1
Actual result:
--
register_globals =
--
Edit this bug report at http://bugs.php.net/?id=34536&edit=1
#34536 [Fbk->Opn]: ini_get('register_globals') does not return correct value
ID: 34536
User updated by: leoli at optonline dot net
Reported By: leoli at optonline dot net
-Status: Feedback
+Status: Open
Bug Type: PHP options/info functions
Operating System: Windows XP
PHP Version: 5.0.5
New Comment:
I used php5.0-win32-latest.zip to reinstall PHP5
I used the follow code
result:
string(0) "" string(0) "" string(1) "1" string(1) "1"
The return values for
display_errors and y2k_compliance
are correct
Previous Comments:
[2005-09-16 21:36:40] [EMAIL PROTECTED]
Also, please use var_dump(ini_get("register_globals")); instead of
echo.
[2005-09-16 21:35:50] [EMAIL PROTECTED]
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
Can't reproduce.
[2005-09-16 21:31:37] leoli at optonline dot net
Description:
ini_get('register_globals') always return empty string no matter what
value is set in php.ini.
ini_get() function returns all other values defined in php.ini
correctly.
Reproduce code:
---
/*
Our php.ini contains the following settings:
register_globals = On
*/
echo 'register_globals = ' . ini_get('register_globals') . "\n";
Expected result:
register_globals = 1
Actual result:
--
register_globals =
--
Edit this bug report at http://bugs.php.net/?id=34536&edit=1
#34532 [Opn->WFx]: It would be nice if empty() could accept multiple arguments just like isset()
ID: 34532 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at majiclab dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: N/A PHP Version: 5.0.5 New Comment: We discussed this a year ago, and came to the conclusion that we could not agree on semantics. This is why we will not be adding this feature to PHP. Previous Comments: [2005-09-16 20:35:54] phpbugs at majiclab dot com Description: It would be nice if empty() would accept multiple arguments like isset() does. It would be functionally equivalent to: empty(var) || empty(var2) ... || empty(varN) Reproduce code: --- Expected result: Either $a, $b or $c was empty/did not exist. Actual result: -- parse error, unexpected ',', expecting ')' in /.../file.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=34532&edit=1
#34533 [Fbk->Opn]: LDAP cannot connect when linked against Oracle LDAP libraries
ID: 34533
User updated by: liamr at umich dot edu
Reported By: liamr at umich dot edu
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: linux 2.4.31
PHP Version: 5CVS-2005-09-16 (snap)
New Comment:
It's not much more complicated, but here..
LDAP query test" );
echo( "Connecting ..." );
$ds=ldap_connect('ldap.itd.umich.edu', 389);
print_r( $ds );
echo( "connect result is ".$ds."" );
if ($ds) {
echo( "Binding ..." );
$r=ldap_bind($ds);
echo( "Bind result is ".$r."" );
echo( "Closing connection" );
ldap_close( $ds );
} else {
echo( "Unable to connect to LDAP server" );
}
?>
Previous Comments:
[2005-09-16 21:25:49] [EMAIL PROTECTED]
Obviously the script you provided in your report is not the one you
used to generate that (useless) strace. Can you please show the code
you tried?
[2005-09-16 20:37:35] liamr at umich dot edu
Description:
ldap_connect() returns "Unable to connect to LDAP server" when linked
against Oracle LDAP libraries. I've tried this with PHP 4.3.11, 5.0.5,
5.1.0RC1, and a snapshot I downloaded today (php5-200509161630), all
against Oracle 8.1.7 (full install), 10.1.0.3 (full install), and
10.1.0.4 (instantclient w/ the LDAP headers copied from a full
install). Apache 1.3.33 on an LFS based distro running the 2.4.31
kernel.
Reproduce code:
---
$ds=ldap_connect('ldap.example.com', 389);
Expected result:
When the ldap extension is linked against openldap, the ldap_connect()
results in an LDAP connection.
Actual result:
--
When linked against Oracle's LDAP, the server is unable to establish a
connection. Looking at strace, it doesn't even query the network:
open("/usr/lib/php/extensions/no-debug-non-zts-20050617/ldap.so",
O_RDONLY) = 8
read(8,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300+\0\0004\0\0\00085\1\0\0\0\0\0004\0
\0\4\0(\0\"\0\37\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0xw\0\0xw\0\0\5\0\0\0\0\20\0\0\1\0\0\0\200w\0\0\200\207\0\0\200\207\0\0\240\5\0\0\274\5\0\0\6\0\0\0\0\20\0\0\2\0\0\0\f|\0\0\f\214\0\0\f\214\0\0\340\0\0\0\340\0\0\0\6\0\0\0\4\0\0\0P\345td\\w\0\0\\w\0\0\\w\0\0\34\0\0\0\34\0\0\0\4\0\0\0\4\0\0\0\203\0\0\0\233\0\0\0\0\0\0\0002\0\0\0A\0\0\0\0\0\0\0\226\0\0\0\0\0\0\0006\0\0\0\0\0\0\0q\0\0\0009\0\0\0|\0\0\0U\0\0\0%\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\214\0\0\0\210\0\0\0\0\0\0\0\215\0\0\0\0\0\0\0\0\0\0\0~\0\0\0\0\0\0\0\0\0\0\0v\0\0\0\231\0\0\0]\0\0\0\0\0\0\0\225\0\0\0\0\0\0\0[\0\0\0O\0\0\0\0\0\0\0\201\0\0\0008\0\0\0C\0\0\0\0\0\0\0S\0\0\0m\0\0\0\0\0\0\0\217\0\0\0\0\0\0\0z\0\0\0J\0\0\0Q\0\0\0\211\0\0\0/\0\0\0)\0\0\0\0\0\0\0K\0\0\0\232\0\0\0\0\0\0\0h\0\0\0\0\0\0\0\0\0\0\0H\0\0\0\0\0\0\0\227\0\0\0\220\0\0\0\223\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0_\0\0\0\0\0\0\0\222\0\0\0\0\0\0\0&\0\0\0\"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=\0\0\0\177\0\0\0\0\0\0\0e\0\0\0\0\0\0\0b\0\0\0w\0\0\0003\0\0\0I\0\0\0005\0\0\!
0n\0\0\0\216\0\0\0\0\0\0\0\230\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0#\0\0\0k\0\0\0([EMAIL
PROTECTED]:\0\0\0\0\0\0\0\0\0\0\0>\0\0\0.\0\0\!
0\0\0\0\0",
1024) = 1024
fstat64(8, {st_dev=makedev(8, 1), st_ino=1947378, st_mode=S_IFREG|0755,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=184,
st_size=86383, st_atime=2005/09/16-12:58:21,
st_mtime=2005/09/16-12:56:19, st_ctime=2005/09/16-12:56:28}) = 0
old_mmap(NULL, 36156, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) =
0x42b59000
mprotect(0x42b61000, 3388, PROT_NONE) = 0
old_mmap(0x42b61000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
8, 0x7000) = 0x42b61000
close(8)= 0
open("/usr/local/oracle/lib/mmx/cmov/libclntsh.so.10.1", O_RDONLY) = -1
ENOENT (No such file or directory)
stat64("/usr/local/oracle/lib/mmx/cmov", 0xbfffa1d0) = -1 ENOENT (No
such file or directory)
open("/usr/local/oracle/lib/mmx/libclntsh.so.10.1", O_RDONLY) = -1
ENOENT (No such file or directory)
stat64("/usr/local/oracle/lib/mmx", 0xbfffa1d0) = -1 ENOENT (No such
file or directory)
open("/usr/local/oracle/lib/cmov/libclntsh.so.10.1", O_RDONLY) = -1
ENOENT (No such file or directory)
stat64("/usr/local/oracle/lib/cmov", 0xbfffa1d0) = -1 ENOENT (No such
file or directory)
open("/usr/local/oracle/lib/libclntsh.so.10.1", O_RDONLY) = 8
read(8,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\267\17\0004\0\0\0\314\364\300\0\0\0\0\0004\0
\0\3\0(\0\33\0\30\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0` \250\0`
\250\0\5\0\0\0\0\20\0\0\1\0\0\0`
\250\0`0\250\0`0\250\0xB\20\0004\236\21\0\6\0\0\0\0\20\0\0\2\0\0\0\304\310\267\0\304\330\267\0\304\330\267\0\0\1\0\0\0\1\0\0\6\0\0\0\4\0\0\0\21
\0\0\20=\0\0v0\0\0=0\0\0\372#\0\0\\(\0\0\323<\0\0<6\0\0\360.\0\0\0315\0\0t;\0\0A,\0\0B*\0\0\0\0\0\0\n9\0\0\344\25\0\0L+\0\0\0\0\0\0\17;\0\0\216\23\0\0\23\22\0\0\260\34\0\0\2727\0\0\21*\0\0\277$\0\0\r<\0\0\3129\0\0\3577\0\0\204\30\0\0\0\0\0\0p5\0\0\3000
#34535 [Opn->Fbk]: thttpd-2.21b with oci8 extendion Segmentation fault
ID: 34535 Updated by: [EMAIL PROTECTED] Reported By: dimitri at vinogradov dot de -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: linux debian -PHP Version: 5.0.5 +PHP Version: 5CVS-2005-09-16 (snap) New Comment: we're holding our breaths! :) Previous Comments: [2005-09-16 21:38:36] dimitri at vinogradov dot de @sniper(at)php.net: Same result... @tony2001(at)php.net: will compile it in debug mode and report ASAP [2005-09-16 21:32:43] [EMAIL PROTECTED] Please provide a GDB backtrace. [2005-09-16 21:12:14] [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-16 21:05:51] dimitri at vinogradov dot de Description: thttpd-2.21b compiled with php-5.0.5 and oci8-1.1 exits due to Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=34535&edit=1
#34535 [Fbk->Opn]: thttpd-2.21b with oci8 extendion Segmentation fault
ID: 34535 User updated by: dimitri at vinogradov dot de Reported By: dimitri at vinogradov dot de -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: linux debian PHP Version: 5.0.5 New Comment: @sniper(at)php.net: Same result... @tony2001(at)php.net: will compile it in debug mode and report ASAP Previous Comments: [2005-09-16 21:32:43] [EMAIL PROTECTED] Please provide a GDB backtrace. [2005-09-16 21:12:14] [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-16 21:05:51] dimitri at vinogradov dot de Description: thttpd-2.21b compiled with php-5.0.5 and oci8-1.1 exits due to Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=34535&edit=1
#34536 [Fbk]: ini_get('register_globals') does not return correct value
ID: 34536
Updated by: [EMAIL PROTECTED]
Reported By: leoli at optonline dot net
Status: Feedback
Bug Type: PHP options/info functions
Operating System: Windows XP
PHP Version: 5.0.5
New Comment:
Also, please use var_dump(ini_get("register_globals")); instead of
echo.
Previous Comments:
[2005-09-16 21:35:50] [EMAIL PROTECTED]
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
Can't reproduce.
[2005-09-16 21:31:37] leoli at optonline dot net
Description:
ini_get('register_globals') always return empty string no matter what
value is set in php.ini.
ini_get() function returns all other values defined in php.ini
correctly.
Reproduce code:
---
/*
Our php.ini contains the following settings:
register_globals = On
*/
echo 'register_globals = ' . ini_get('register_globals') . "\n";
Expected result:
register_globals = 1
Actual result:
--
register_globals =
--
Edit this bug report at http://bugs.php.net/?id=34536&edit=1
#34536 [Opn->Fbk]: ini_get('register_globals') does not return correct value
ID: 34536
Updated by: [EMAIL PROTECTED]
Reported By: leoli at optonline dot net
-Status: Open
+Status: Feedback
-Bug Type: Unknown/Other Function
+Bug Type: PHP options/info functions
Operating System: Windows XP
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
Can't reproduce.
Previous Comments:
[2005-09-16 21:31:37] leoli at optonline dot net
Description:
ini_get('register_globals') always return empty string no matter what
value is set in php.ini.
ini_get() function returns all other values defined in php.ini
correctly.
Reproduce code:
---
/*
Our php.ini contains the following settings:
register_globals = On
*/
echo 'register_globals = ' . ini_get('register_globals') . "\n";
Expected result:
register_globals = 1
Actual result:
--
register_globals =
--
Edit this bug report at http://bugs.php.net/?id=34536&edit=1
#34535 [Fbk]: thttpd-2.21b with oci8 extendion Segmentation fault
ID: 34535 Updated by: [EMAIL PROTECTED] Reported By: dimitri at vinogradov dot de Status: Feedback Bug Type: OCI8 related Operating System: linux debian PHP Version: 5.0.5 New Comment: Please provide a GDB backtrace. Previous Comments: [2005-09-16 21:12:14] [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-16 21:05:51] dimitri at vinogradov dot de Description: thttpd-2.21b compiled with php-5.0.5 and oci8-1.1 exits due to Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=34535&edit=1
#34536 [NEW]: ini_get('register_globals') does not return correct value
From: leoli at optonline dot net
Operating system: Windows XP
PHP version: 5.0.5
PHP Bug Type: Unknown/Other Function
Bug description: ini_get('register_globals') does not return correct value
Description:
ini_get('register_globals') always return empty string no matter what
value is set in php.ini.
ini_get() function returns all other values defined in php.ini correctly.
Reproduce code:
---
/*
Our php.ini contains the following settings:
register_globals = On
*/
echo 'register_globals = ' . ini_get('register_globals') . "\n";
Expected result:
register_globals = 1
Actual result:
--
register_globals =
--
Edit bug report at http://bugs.php.net/?id=34536&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34536&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34536&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34536&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34536&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34536&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34536&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34536&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34536&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34536&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34536&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34536&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34536&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34536&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34536&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34536&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34536&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34536&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34536&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34536&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34536&r=mysqlcfg
#34533 [Opn->Fbk]: LDAP cannot connect when linked against Oracle LDAP libraries
ID: 34533
Updated by: [EMAIL PROTECTED]
Reported By: liamr at umich dot edu
-Status: Open
+Status: Feedback
Bug Type: LDAP related
Operating System: linux 2.4.31
PHP Version: 5CVS-2005-09-16 (snap)
New Comment:
Obviously the script you provided in your report is not the one you
used to generate that (useless) strace. Can you please show the code
you tried?
Previous Comments:
[2005-09-16 20:37:35] liamr at umich dot edu
Description:
ldap_connect() returns "Unable to connect to LDAP server" when linked
against Oracle LDAP libraries. I've tried this with PHP 4.3.11, 5.0.5,
5.1.0RC1, and a snapshot I downloaded today (php5-200509161630), all
against Oracle 8.1.7 (full install), 10.1.0.3 (full install), and
10.1.0.4 (instantclient w/ the LDAP headers copied from a full
install). Apache 1.3.33 on an LFS based distro running the 2.4.31
kernel.
Reproduce code:
---
$ds=ldap_connect('ldap.example.com', 389);
Expected result:
When the ldap extension is linked against openldap, the ldap_connect()
results in an LDAP connection.
Actual result:
--
When linked against Oracle's LDAP, the server is unable to establish a
connection. Looking at strace, it doesn't even query the network:
open("/usr/lib/php/extensions/no-debug-non-zts-20050617/ldap.so",
O_RDONLY) = 8
read(8,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300+\0\0004\0\0\00085\1\0\0\0\0\0004\0
\0\4\0(\0\"\0\37\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0xw\0\0xw\0\0\5\0\0\0\0\20\0\0\1\0\0\0\200w\0\0\200\207\0\0\200\207\0\0\240\5\0\0\274\5\0\0\6\0\0\0\0\20\0\0\2\0\0\0\f|\0\0\f\214\0\0\f\214\0\0\340\0\0\0\340\0\0\0\6\0\0\0\4\0\0\0P\345td\\w\0\0\\w\0\0\\w\0\0\34\0\0\0\34\0\0\0\4\0\0\0\4\0\0\0\203\0\0\0\233\0\0\0\0\0\0\0002\0\0\0A\0\0\0\0\0\0\0\226\0\0\0\0\0\0\0006\0\0\0\0\0\0\0q\0\0\0009\0\0\0|\0\0\0U\0\0\0%\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\214\0\0\0\210\0\0\0\0\0\0\0\215\0\0\0\0\0\0\0\0\0\0\0~\0\0\0\0\0\0\0\0\0\0\0v\0\0\0\231\0\0\0]\0\0\0\0\0\0\0\225\0\0\0\0\0\0\0[\0\0\0O\0\0\0\0\0\0\0\201\0\0\0008\0\0\0C\0\0\0\0\0\0\0S\0\0\0m\0\0\0\0\0\0\0\217\0\0\0\0\0\0\0z\0\0\0J\0\0\0Q\0\0\0\211\0\0\0/\0\0\0)\0\0\0\0\0\0\0K\0\0\0\232\0\0\0\0\0\0\0h\0\0\0\0\0\0\0\0\0\0\0H\0\0\0\0\0\0\0\227\0\0\0\220\0\0\0\223\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0_\0\0\0\0\0\0\0\222\0\0\0\0\0\0\0&\0\0\0\"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=\0\0\0\177\0\0\0\0\0\0\0e\0\0\0\0\0\0\0b\0\0\0w\0\0\0003\0\0\0I\0\0\0005\0\0\!
0n\0\0\0\216\0\0\0\0\0\0\0\230\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0#\0\0\0k\0\0\0([EMAIL
PROTECTED]:\0\0\0\0\0\0\0\0\0\0\0>\0\0\0.\0\0\!
0\0\0\0\0",
1024) = 1024
fstat64(8, {st_dev=makedev(8, 1), st_ino=1947378, st_mode=S_IFREG|0755,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=184,
st_size=86383, st_atime=2005/09/16-12:58:21,
st_mtime=2005/09/16-12:56:19, st_ctime=2005/09/16-12:56:28}) = 0
old_mmap(NULL, 36156, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) =
0x42b59000
mprotect(0x42b61000, 3388, PROT_NONE) = 0
old_mmap(0x42b61000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
8, 0x7000) = 0x42b61000
close(8)= 0
open("/usr/local/oracle/lib/mmx/cmov/libclntsh.so.10.1", O_RDONLY) = -1
ENOENT (No such file or directory)
stat64("/usr/local/oracle/lib/mmx/cmov", 0xbfffa1d0) = -1 ENOENT (No
such file or directory)
open("/usr/local/oracle/lib/mmx/libclntsh.so.10.1", O_RDONLY) = -1
ENOENT (No such file or directory)
stat64("/usr/local/oracle/lib/mmx", 0xbfffa1d0) = -1 ENOENT (No such
file or directory)
open("/usr/local/oracle/lib/cmov/libclntsh.so.10.1", O_RDONLY) = -1
ENOENT (No such file or directory)
stat64("/usr/local/oracle/lib/cmov", 0xbfffa1d0) = -1 ENOENT (No such
file or directory)
open("/usr/local/oracle/lib/libclntsh.so.10.1", O_RDONLY) = 8
read(8,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\267\17\0004\0\0\0\314\364\300\0\0\0\0\0004\0
\0\3\0(\0\33\0\30\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0` \250\0`
\250\0\5\0\0\0\0\20\0\0\1\0\0\0`
\250\0`0\250\0`0\250\0xB\20\0004\236\21\0\6\0\0\0\0\20\0\0\2\0\0\0\304\310\267\0\304\330\267\0\304\330\267\0\0\1\0\0\0\1\0\0\6\0\0\0\4\0\0\0\21
\0\0\20=\0\0v0\0\0=0\0\0\372#\0\0\\(\0\0\323<\0\0<6\0\0\360.\0\0\0315\0\0t;\0\0A,\0\0B*\0\0\0\0\0\0\n9\0\0\344\25\0\0L+\0\0\0\0\0\0\17;\0\0\216\23\0\0\23\22\0\0\260\34\0\0\2727\0\0\21*\0\0\277$\0\0\r<\0\0\3129\0\0\3577\0\0\204\30\0\0\0\0\0\0p5\0\0\3000\0\0~;\0\0\0\0\0\0l\36\0\0\2312\0\0\0161\0\0\177\36\0\0\364\20\0\0[+\0\0\270/\0\0\3604\0\0\220\33\0\0007&\0\0c,\0\0r<\0\0\363\'\0\0\0\0\0\0O0\0\0\370\f\0\0J\23\0\0\210-\0\0\262:\0\0\3676\0\0\3118\0\0a\'\0\0\207\16\0\0\10\22\0\0Q8\0\0\252<\0\0\2070\0\0\3166\0\0\0\0\0\0\0\0\0\0\0\0\0\0-7\0\0\2157\0\0(7\0\0\0\0\0\0`&\0\0%2\0\0\271\23\0\0\240\t\0\0002\21\0\0\3552\0\0\0\0\0\0$\35\0\0G0\0\0\2400\0\0-/\0\0^7\0\0\3317\0\0\0\0\0\0\2723\0\0\251\0\0\0t8\0\0=\10\0\0\2310\0\0R6\0\0\354\25\0\0R:\0\0\0\0\0\0\0\0\0\0\0\0\0\0m(\0\00084\0\0\270
#34009 [Asn->Bgs]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009 Updated by: [EMAIL PROTECTED] Reported By: ast at gmx dot ch -Status: Assigned +Status: Bogus Bug Type: Scripting Engine problem Operating System: Gentoo Linux PHP Version: 4.4.0 Assigned To: Derick New Comment: The bug here is in Zend Optimizer. It sees your variable assigned immediately before the return and substitutes the intermediate TMP_VAR for the real variable. Please report this bug to Zend at http://www.zend.com Previous Comments: [2005-09-16 21:11:51] [EMAIL PROTECTED] I will not reply since I don't use PHP 4 anymore. Assigned to Derick who likes it so much and loves to fix reference bugs! :) [2005-09-16 19:04:54] ast at gmx dot ch [EMAIL PROTECTED]: I have yet another ISP claiming that their PHP 4.4.0 is ok, but the code is wrong (Notices showing up when they shouldn't). Could you please reply to my point "1." from message "[7 Aug 2:32pm CEST] ast at gmx dot ch"? I'd like to make sure that we agree that the code is correct. A lot of servers running PHP 4.4.0 don't show notices which indicates it's correct code and my mind tells me it's correct. Also, do you think John Lim from the adodb project is right with his theory that 3rd party PHP extensions could be the issue. Or maybe some C libraries? See the message from "[8 Aug 10:48am CEST] ast at gmx dot ch". Thank you very much. - Andy [2005-08-08 13:51:22] ast at gmx dot ch The reproduce script starts with: error_reporting(E_ALL); And even if not all of the tested systems have a default error_reporting level of E_ALL, some of them have and don't show / show the Notice. I'd disagree, it should not be return &$false; That would even give a parse error. But that's offtopic. If you think it should give a Notice with error_reporting = E_ALL for the reproduce script, please try it. On most systems, it doesn't return a Notice. Bottom line: I hope after reading the report carefully you'll understand the issue and agree with [EMAIL PROTECTED] and me that it shouldn't show a Notice in either of the cases. One of the ISPs is still trying to figure out why it gives the Notice, I guess the next step will be to disable all extensions etc. [2005-08-08 13:25:57] [EMAIL PROTECTED] No, whatever you may think all test cases do NOT have E_ALL set. The two phpinfo URLs listed under your "Unexpected result observed on" have error_reporting = E_ALL (2047). The URL listed under "Correct behaviour observed on" has error_reporting set to 2039 (E_ALL ^ E_NOTICE). It's a Notice. You get it when E_NOTICE is enabled and not when it isn't. QED (And yes, I personally think it's a correct Notice; the return line should be "return &$false" to not get a Notice, surely? But maybe I'm wrong about that) [2005-08-08 12:58:48] ast at gmx dot ch [EMAIL PROTECTED]: So you say with error_reporting = E_ALL it *should* give a Notice in this case? If so, no offence, but I think you haven't read the bug report carefully. All tested systems have error_reporting E_ALL. The point is that even with E_ALL, it doesn't give a Notice on most systems (and I think that's correct), but others do. But we're now at a point where we think that 3rd party extensions could be responsible for the incorrect behavior. 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/34009 -- Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#34535 [Opn->Fbk]: thttpd-2.21b with oci8 extendion Segmentation fault
ID: 34535 Updated by: [EMAIL PROTECTED] Reported By: dimitri at vinogradov dot de -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: linux debian 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-09-16 21:05:51] dimitri at vinogradov dot de Description: thttpd-2.21b compiled with php-5.0.5 and oci8-1.1 exits due to Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=34535&edit=1
#34009 [Opn->Asn]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009 Updated by: [EMAIL PROTECTED] Reported By: ast at gmx dot ch -Status: Open +Status: Assigned Bug Type: Scripting Engine problem Operating System: Gentoo Linux PHP Version: 4.4.0 -Assigned To: +Assigned To: Derick New Comment: I will not reply since I don't use PHP 4 anymore. Assigned to Derick who likes it so much and loves to fix reference bugs! :) Previous Comments: [2005-09-16 19:04:54] ast at gmx dot ch [EMAIL PROTECTED]: I have yet another ISP claiming that their PHP 4.4.0 is ok, but the code is wrong (Notices showing up when they shouldn't). Could you please reply to my point "1." from message "[7 Aug 2:32pm CEST] ast at gmx dot ch"? I'd like to make sure that we agree that the code is correct. A lot of servers running PHP 4.4.0 don't show notices which indicates it's correct code and my mind tells me it's correct. Also, do you think John Lim from the adodb project is right with his theory that 3rd party PHP extensions could be the issue. Or maybe some C libraries? See the message from "[8 Aug 10:48am CEST] ast at gmx dot ch". Thank you very much. - Andy [2005-08-08 13:51:22] ast at gmx dot ch The reproduce script starts with: error_reporting(E_ALL); And even if not all of the tested systems have a default error_reporting level of E_ALL, some of them have and don't show / show the Notice. I'd disagree, it should not be return &$false; That would even give a parse error. But that's offtopic. If you think it should give a Notice with error_reporting = E_ALL for the reproduce script, please try it. On most systems, it doesn't return a Notice. Bottom line: I hope after reading the report carefully you'll understand the issue and agree with [EMAIL PROTECTED] and me that it shouldn't show a Notice in either of the cases. One of the ISPs is still trying to figure out why it gives the Notice, I guess the next step will be to disable all extensions etc. [2005-08-08 13:25:57] [EMAIL PROTECTED] No, whatever you may think all test cases do NOT have E_ALL set. The two phpinfo URLs listed under your "Unexpected result observed on" have error_reporting = E_ALL (2047). The URL listed under "Correct behaviour observed on" has error_reporting set to 2039 (E_ALL ^ E_NOTICE). It's a Notice. You get it when E_NOTICE is enabled and not when it isn't. QED (And yes, I personally think it's a correct Notice; the return line should be "return &$false" to not get a Notice, surely? But maybe I'm wrong about that) [2005-08-08 12:58:48] ast at gmx dot ch [EMAIL PROTECTED]: So you say with error_reporting = E_ALL it *should* give a Notice in this case? If so, no offence, but I think you haven't read the bug report carefully. All tested systems have error_reporting E_ALL. The point is that even with E_ALL, it doesn't give a Notice on most systems (and I think that's correct), but others do. But we're now at a point where we think that 3rd party extensions could be responsible for the incorrect behavior. [2005-08-08 12:51:54] [EMAIL PROTECTED] There's no fault in the code or PHP. It's the server setup differing. (Strong Hint: look at the value of error_reporting on each of the phpinfo pages you quoted.) 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/34009 -- Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#34535 [NEW]: thttpd-2.21b with oci8 extendion Segmentation fault
From: dimitri at vinogradov dot de Operating system: linux debian PHP version: 5.0.5 PHP Bug Type: OCI8 related Bug description: thttpd-2.21b with oci8 extendion Segmentation fault Description: thttpd-2.21b compiled with php-5.0.5 and oci8-1.1 exits due to Segmentation fault -- Edit bug report at http://bugs.php.net/?id=34535&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34535&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34535&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34535&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34535&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34535&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34535&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34535&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34535&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34535&r=support Expected behavior: http://bugs.php.net/fix.php?id=34535&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34535&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34535&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34535&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34535&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34535&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34535&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34535&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34535&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34535&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34535&r=mysqlcfg
#34530 [Opn->Bgs]: preg_match result depends on input string length when it should not
ID: 34530 Updated by: [EMAIL PROTECTED] Reported By: php at clayst dot com -Status: Open +Status: Bogus Bug Type: PCRE related Operating System: Windows XP Pro PHP Version: 4.4.0 New Comment: Thank you for not searching the bug database before submitting yet another bogus bug report about this issue. Read about the limitations in PCRE library here: http://www.pcre.org/pcre.txt This is not PHP bug, just PCRE library's limitation. (also mentioned in the manual, if you had bothered reading it) Previous Comments: [2005-09-16 19:27:39] php at clayst dot com Description: A regular expression which involves some unnecessary extra loops in execution will give the proper result (a match) with a given input string but will fail to match when it should if the input is one character longer. In the example, the pattern is intended to match a string which contains: (1) An optional substring consisting of one or more groups of word characters separated by dashes, with the entire substring (if present) terminated by a period; followed by (2) A required substring consisting of one or more groups of word characters separated by dashes. The 'good' pattern shown does this properly. The 'bad' pattern incorrectly makes the dashes between substrings optional -- i.e. there's an extra '?" after the '-' in both portions of the pattern. This error makes the pattern inefficient as there are many possible matching substrings, but I believe it should still match a simple alpha string. In fact it fails to match if the input string is more than 20 characters long. Reproduce code: --- Expected result: All matches should return a 1 because they all match the given string. Actual result: -- The first three matches return a 1 but the last returns a 0: Good pattern, 20 characters: 1 Good pattern, 21 characters: 1 Bad pattern, 20 characters: 1 Bad pattern, 21 characters: 0 -- Edit this bug report at http://bugs.php.net/?id=34530&edit=1
#34533 [NEW]: LDAP cannot connect when linked against Oracle LDAP libraries
From: liamr at umich dot edu
Operating system: linux 2.4.31
PHP version: 5CVS-2005-09-16 (snap)
PHP Bug Type: LDAP related
Bug description: LDAP cannot connect when linked against Oracle LDAP libraries
Description:
ldap_connect() returns "Unable to connect to LDAP server" when linked
against Oracle LDAP libraries. I've tried this with PHP 4.3.11, 5.0.5,
5.1.0RC1, and a snapshot I downloaded today (php5-200509161630), all
against Oracle 8.1.7 (full install), 10.1.0.3 (full install), and 10.1.0.4
(instantclient w/ the LDAP headers copied from a full install). Apache
1.3.33 on an LFS based distro running the 2.4.31 kernel.
Reproduce code:
---
$ds=ldap_connect('ldap.example.com', 389);
Expected result:
When the ldap extension is linked against openldap, the ldap_connect()
results in an LDAP connection.
Actual result:
--
When linked against Oracle's LDAP, the server is unable to establish a
connection. Looking at strace, it doesn't even query the network:
open("/usr/lib/php/extensions/no-debug-non-zts-20050617/ldap.so",
O_RDONLY) = 8
read(8,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300+\0\0004\0\0\00085\1\0\0\0\0\0004\0
\0\4\0(\0\"\0\37\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0xw\0\0xw\0\0\5\0\0\0\0\20\0\0\1\0\0\0\200w\0\0\200\207\0\0\200\207\0\0\240\5\0\0\274\5\0\0\6\0\0\0\0\20\0\0\2\0\0\0\f|\0\0\f\214\0\0\f\214\0\0\340\0\0\0\340\0\0\0\6\0\0\0\4\0\0\0P\345td\\w\0\0\\w\0\0\\w\0\0\34\0\0\0\34\0\0\0\4\0\0\0\4\0\0\0\203\0\0\0\233\0\0\0\0\0\0\0002\0\0\0A\0\0\0\0\0\0\0\226\0\0\0\0\0\0\0006\0\0\0\0\0\0\0q\0\0\0009\0\0\0|\0\0\0U\0\0\0%\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\214\0\0\0\210\0\0\0\0\0\0\0\215\0\0\0\0\0\0\0\0\0\0\0~\0\0\0\0\0\0\0\0\0\0\0v\0\0\0\231\0\0\0]\0\0\0\0\0\0\0\225\0\0\0\0\0\0\0[\0\0\0O\0\0\0\0\0\0\0\201\0\0\0008\0\0\0C\0\0\0\0\0\0\0S\0\0\0m\0\0\0\0\0\0\0\217\0\0\0\0\0\0\0z\0\0\0J\0\0\0Q\0\0\0\211\0\0\0/\0\0\0)\0\0\0\0\0\0\0K\0\0\0\232\0\0\0\0\0\0\0h\0\0\0\0\0\0\0\0\0\0\0H\0\0\0\0\0\0\0\227\0\0\0\220\0\0\0\223\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0_\0\0\0\0\0\0\0\222\0\0\0\0\0\0\0&\0\0\0\"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=\0\0\0\177\0\0\0\0\0\0\0e\0\0\0\0\0\0\0b\0\0\0w\0\0\0003\0\0\0I\0\0\0005\0\0\!
0n\0\0\0\216\0\0\0\0\0\0\0\230\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0#\0\0\0k\0\0\0([EMAIL
PROTECTED]:\0\0\0\0\0\0\0\0\0\0\0>\0\0\0.\0\0\!
0\0\0\0\0",
1024) = 1024
fstat64(8, {st_dev=makedev(8, 1), st_ino=1947378, st_mode=S_IFREG|0755,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=184,
st_size=86383, st_atime=2005/09/16-12:58:21, st_mtime=2005/09/16-12:56:19,
st_ctime=2005/09/16-12:56:28}) = 0
old_mmap(NULL, 36156, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) =
0x42b59000
mprotect(0x42b61000, 3388, PROT_NONE) = 0
old_mmap(0x42b61000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8,
0x7000) = 0x42b61000
close(8)= 0
open("/usr/local/oracle/lib/mmx/cmov/libclntsh.so.10.1", O_RDONLY) = -1
ENOENT (No such file or directory)
stat64("/usr/local/oracle/lib/mmx/cmov", 0xbfffa1d0) = -1 ENOENT (No such
file or directory)
open("/usr/local/oracle/lib/mmx/libclntsh.so.10.1", O_RDONLY) = -1 ENOENT
(No such file or directory)
stat64("/usr/local/oracle/lib/mmx", 0xbfffa1d0) = -1 ENOENT (No such file
or directory)
open("/usr/local/oracle/lib/cmov/libclntsh.so.10.1", O_RDONLY) = -1 ENOENT
(No such file or directory)
stat64("/usr/local/oracle/lib/cmov", 0xbfffa1d0) = -1 ENOENT (No such file
or directory)
open("/usr/local/oracle/lib/libclntsh.so.10.1", O_RDONLY) = 8
read(8,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\267\17\0004\0\0\0\314\364\300\0\0\0\0\0004\0
\0\3\0(\0\33\0\30\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0` \250\0`
\250\0\5\0\0\0\0\20\0\0\1\0\0\0`
\250\0`0\250\0`0\250\0xB\20\0004\236\21\0\6\0\0\0\0\20\0\0\2\0\0\0\304\310\267\0\304\330\267\0\304\330\267\0\0\1\0\0\0\1\0\0\6\0\0\0\4\0\0\0\21
\0\0\20=\0\0v0\0\0=0\0\0\372#\0\0\\(\0\0\323<\0\0<6\0\0\360.\0\0\0315\0\0t;\0\0A,\0\0B*\0\0\0\0\0\0\n9\0\0\344\25\0\0L+\0\0\0\0\0\0\17;\0\0\216\23\0\0\23\22\0\0\260\34\0\0\2727\0\0\21*\0\0\277$\0\0\r<\0\0\3129\0\0\3577\0\0\204\30\0\0\0\0\0\0p5\0\0\3000\0\0~;\0\0\0\0\0\0l\36\0\0\2312\0\0\0161\0\0\177\36\0\0\364\20\0\0[+\0\0\270/\0\0\3604\0\0\220\33\0\0007&\0\0c,\0\0r<\0\0\363\'\0\0\0\0\0\0O0\0\0\370\f\0\0J\23\0\0\210-\0\0\262:\0\0\3676\0\0\3118\0\0a\'\0\0\207\16\0\0\10\22\0\0Q8\0\0\252<\0\0\2070\0\0\3166\0\0\0\0\0\0\0\0\0\0\0\0\0\0-7\0\0\2157\0\0(7\0\0\0\0\0\0`&\0\0%2\0\0\271\23\0\0\240\t\0\0002\21\0\0\3552\0\0\0\0\0\0$\35\0\0G0\0\0\2400\0\0-/\0\0^7\0\0\3317\0\0\0\0\0\0\2723\0\0\251\0\0\0t8\0\0=\10\0\0\2310\0\0R6\0\0\354\25\0\0R:\0\0\0\0\0\0\0\0\0\0\0\0\0\0m(\0\00084\0\0\2703\0\0\2656\0\0\0\0\0\0\316\33\0\0\0\0\0\0i\35\0\0\"\f\0\0*\25\0\0\n\23\0\0\272$\0\0\323(\0\0\235\22\0\0N\22\0\0\0\0\0\0\0\0\0\0\264\31\0\0D0\0\0\3267\0\0]1\0\0\256\22\0\0\220:\0\0\356\36\0\0z:\0\0a&\0\0a#\!
0\0\236+\0\0\0\0\0\0Z4\0\0V;\0\0\0\0\0\0\325&\0\0(4\0\0003\t\0\0\0\0\0\0r4\0\0\16*\0\0
\27\0\0\266*\0\0^!\0\0\0\0\0\0\222\34\0\0\2308\0
#34532 [NEW]: It would be nice if empty() could accept multiple arguments just like isset()
From: phpbugs at majiclab dot com Operating system: N/A PHP version: 5.0.5 PHP Bug Type: Feature/Change Request Bug description: It would be nice if empty() could accept multiple arguments just like isset() Description: It would be nice if empty() would accept multiple arguments like isset() does. It would be functionally equivalent to: empty(var) || empty(var2) ... || empty(varN) Reproduce code: --- Expected result: Either $a, $b or $c was empty/did not exist. Actual result: -- parse error, unexpected ',', expecting ')' in /.../file.php on line 3 -- Edit bug report at http://bugs.php.net/?id=34532&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34532&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34532&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34532&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34532&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34532&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34532&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34532&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34532&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34532&r=support Expected behavior: http://bugs.php.net/fix.php?id=34532&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34532&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34532&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34532&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34532&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34532&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34532&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34532&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34532&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34532&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34532&r=mysqlcfg
#33533 [Fbk]: PDO_ODBC: Segmentation Fault with selecting informix text column
ID: 33533 Updated by: [EMAIL PROTECTED] Reported By: scott dot barnett at thuringowa dot qld dot gov dot au Status: Feedback Bug Type: PDO related Operating System: CentOS 4.1 / Redhat Enterprise 4 PHP Version: 5CVS-2005-07-04 Assigned To: wez New Comment: I've poked around, and this really looks like either a unixODBC or informix bug (perhaps both). It's quite possible that PDO is doing something that unixODBC or informix doesn't like, but the problem is that unixODBC is trying to call a function that is set to NULL. (gdb) info linkmap /lib/libcrypt.so.1 /usr/lib/libz.so.1 /lib/libresolv.so.2 /lib/tls/libm.so.6 /lib/libnsl.so.1 00a4 /usr/local/lib/libodbc.so.1 /lib/libdl.so.2 /lib/tls/libpthread.so.0 /lib/tls/libc.so.6 /lib/ld-linux.so.2 005e1000 /usr/lib/gconv/ISO8859-1.so 001f7000 /opt/informix/lib/cli/iclis09b.so 007d5000 /opt/informix/lib/esql/libifgls.so 00d89000 /opt/informix/lib/esql/libifglx.so 0039e000 /lib/libnss_files.so.2 00198000 /opt/informix/lib/esql/igo4a304.so 0098d000 /usr/local/lib/libodbccr.so.1 (gdb) where #0 0x in ?? () fault here, calling a NULL function. #1 0x00990ef2 in CLGetData (statement_handle=0x8faec48, column_number=2, target_type=1, target_value=0x8fb383c, buffer_length=256, strlen_or_ind=0x8fb36c4) at SQLGetData.c:336 this address is in libodbccr.so.1, part of unix odbc #2 0x00a58f0c in SQLGetData (statement_handle=0x8fae670, column_number=2, target_type=1, target_value=0x8fb383c, buffer_length=256, strlen_or_ind=0x8fb36c4) at SQLGetData.c:412 this address is in libodbccr.so.1, part of unix odbc #3 0x080abd8a in odbc_stmt_get_col (stmt=0x8fb7f94, colno=1, ptr=0xbfe6083c, len=0xbfe60838, caller_frees=0xbfe60834) at /home/wez/php5-200509161630/ext/pdo_odbc/odbc_stmt.c:434 this address is in the pdo odbc driver. What I suspect is the problem is that either informix doesn't set a flag to tell unixodbc about the functions it supports, or that unixodbc doesn't respect a flag that it should. Ultimately, unixODBC should catch that NULL and report an error properly. I don't think I can do anything while this crash problem exists, and I think you should file a bug report with the unix ODBC guys so that we can figure out what is going wrong, and then we can figure out how to make things work for you. I'm happy to co-operate with them in tracking this down. Previous Comments: [2005-09-10 21:47:04] [EMAIL PROTECTED] That crash looks like the informix libraries are trying to call a NULL callback handler. There's no way I can debug this without being able to sit down at the machine with my hands on gdb; Can I get a non-privileged account on that machine, so that I can build a CLI php and test it? [2005-08-03 08:41:40] [EMAIL PROTECTED] Wez, the fix didn't quite fix it? :) (note to myself: need to get my eyes checked) [2005-08-03 06:32:45] scott dot barnett at thuringowa dot qld dot gov dot au Still having build problems. Thanks. (gdb) bt #0 0x in ?? () #1 0x002e7ef2 in CLGetData (statement_handle=0x83a5590, column_number=2, target_type=1, target_value=0x83a5a74, buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:336 #2 0x00498f0c in SQLGetData (statement_handle=0x83a4fb8, column_number=2, target_type=1, target_value=0x83a5a74, buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:412 #3 0x00d63d9e in odbc_stmt_get_col (stmt=0x83ae01c, colno=1, ptr=0xbff2e70c, len=0xbff2e708, caller_frees=0xbff2e704) at /usr/src/apache/php5-200508030230/ext/pdo_odbc/odbc_stmt.c:434 #4 0x00d5caa5 in fetch_value (stmt=0x83ae01c, dest=0x83a7724, colno=1) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:447 #5 0x00d5d776 in do_fetch (stmt=0x83ae01c, do_bind=1, return_value=0x834b8cc, how=PDO_FETCH_OBJ, ori=PDO_FETCH_ORI_NEXT, offset=0, return_all=0x0) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:870 #6 0x00d60903 in pdo_stmt_iter_get (ce=0x83004e0, object=0x834b94c) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:2135 #7 0x00f42baf in ZEND_FE_RESET_SPEC_CV_HANDLER (execute_data=0xbff2ebf0) at /usr/src/apache/php5-200508030230/Zend/zend_vm_execute.h:19523 #8 0x00f0f51c in execute (op_array=0x83468fc) at /usr/src/apache/php5-200508030230/Zend/zend_vm_execute.h:87 #9 0x00ee8ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/apache/php5-200508030230/Zend/zend.c:1078 #10 0x00ea8058 in php_execute_script (primary_file=0xbff30f70) at /usr/src/apache/php5-200508030230/main/main.c:1672 #11 0x00f53f8e in php_handler (r=0x8337be0) at /usr/src/apache/php5-200508030230/sapi/apache2handler
#34530 [NEW]: preg_match result depends on input string length when it should not
From: php at clayst dot com Operating system: Windows XP Pro PHP version: 4.4.0 PHP Bug Type: PCRE related Bug description: preg_match result depends on input string length when it should not Description: A regular expression which involves some unnecessary extra loops in execution will give the proper result (a match) with a given input string but will fail to match when it should if the input is one character longer. In the example, the pattern is intended to match a string which contains: (1) An optional substring consisting of one or more groups of word characters separated by dashes, with the entire substring (if present) terminated by a period; followed by (2) A required substring consisting of one or more groups of word characters separated by dashes. The 'good' pattern shown does this properly. The 'bad' pattern incorrectly makes the dashes between substrings optional -- i.e. there's an extra '?" after the '-' in both portions of the pattern. This error makes the pattern inefficient as there are many possible matching substrings, but I believe it should still match a simple alpha string. In fact it fails to match if the input string is more than 20 characters long. Reproduce code: --- Expected result: All matches should return a 1 because they all match the given string. Actual result: -- The first three matches return a 1 but the last returns a 0: Good pattern, 20 characters: 1 Good pattern, 21 characters: 1 Bad pattern, 20 characters: 1 Bad pattern, 21 characters: 0 -- Edit bug report at http://bugs.php.net/?id=34530&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34530&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34530&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34530&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34530&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34530&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34530&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34530&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34530&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34530&r=support Expected behavior: http://bugs.php.net/fix.php?id=34530&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34530&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34530&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34530&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34530&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34530&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34530&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34530&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34530&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34530&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34530&r=mysqlcfg
#34009 [Bgs->Opn]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009 User updated by: ast at gmx dot ch Reported By: ast at gmx dot ch -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: Gentoo Linux PHP Version: 4.4.0 New Comment: [EMAIL PROTECTED]: I have yet another ISP claiming that their PHP 4.4.0 is ok, but the code is wrong (Notices showing up when they shouldn't). Could you please reply to my point "1." from message "[7 Aug 2:32pm CEST] ast at gmx dot ch"? I'd like to make sure that we agree that the code is correct. A lot of servers running PHP 4.4.0 don't show notices which indicates it's correct code and my mind tells me it's correct. Also, do you think John Lim from the adodb project is right with his theory that 3rd party PHP extensions could be the issue. Or maybe some C libraries? See the message from "[8 Aug 10:48am CEST] ast at gmx dot ch". Thank you very much. - Andy Previous Comments: [2005-08-08 13:51:22] ast at gmx dot ch The reproduce script starts with: error_reporting(E_ALL); And even if not all of the tested systems have a default error_reporting level of E_ALL, some of them have and don't show / show the Notice. I'd disagree, it should not be return &$false; That would even give a parse error. But that's offtopic. If you think it should give a Notice with error_reporting = E_ALL for the reproduce script, please try it. On most systems, it doesn't return a Notice. Bottom line: I hope after reading the report carefully you'll understand the issue and agree with [EMAIL PROTECTED] and me that it shouldn't show a Notice in either of the cases. One of the ISPs is still trying to figure out why it gives the Notice, I guess the next step will be to disable all extensions etc. [2005-08-08 13:25:57] [EMAIL PROTECTED] No, whatever you may think all test cases do NOT have E_ALL set. The two phpinfo URLs listed under your "Unexpected result observed on" have error_reporting = E_ALL (2047). The URL listed under "Correct behaviour observed on" has error_reporting set to 2039 (E_ALL ^ E_NOTICE). It's a Notice. You get it when E_NOTICE is enabled and not when it isn't. QED (And yes, I personally think it's a correct Notice; the return line should be "return &$false" to not get a Notice, surely? But maybe I'm wrong about that) [2005-08-08 12:58:48] ast at gmx dot ch [EMAIL PROTECTED]: So you say with error_reporting = E_ALL it *should* give a Notice in this case? If so, no offence, but I think you haven't read the bug report carefully. All tested systems have error_reporting E_ALL. The point is that even with E_ALL, it doesn't give a Notice on most systems (and I think that's correct), but others do. But we're now at a point where we think that 3rd party extensions could be responsible for the incorrect behavior. [2005-08-08 12:51:54] [EMAIL PROTECTED] There's no fault in the code or PHP. It's the server setup differing. (Strong Hint: look at the value of error_reporting on each of the phpinfo pages you quoted.) [2005-08-08 10:48:38] ast at gmx dot ch John Lim from the adodb project wrote the following: > There is nothing wrong with this code. > > I have found this problem normally occurs when php 4.4 is > being run with an old version of zend optimizer or similar > 3rd party software. Also, one of the ISPs that can reproduce this incorrect behavior said they've compiled PHP statically, but zend was DSO. They use the same PHP on multiple boxes and only on one they can reproduce this issue. I'll notify them about the statement from John Lim, probably that's it. If that's the case, the bug is indeed invalid. But it's good to know what can cause this issue. 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/34009 -- Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#34478 [Asn->Csd]: Incorrect parsing of # character in location option
ID: 34478
Updated by: [EMAIL PROTECTED]
Reported By: eric dot bourlon at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: SOAP related
Operating System: Win XP
PHP Version: 5CVS-2005-09-12 (snap)
Assigned To: dmitry
New Comment:
Fixed in CVS HAED, PHP_5_1 and PHP_5_0.
Previous Comments:
[2005-09-13 10:55:21] [EMAIL PROTECTED]
Assigning to the maintainer.
[2005-09-13 10:39:53] eric dot bourlon at gmail dot com
I downloaded the last version but unfortunately observe the same
phenomenon.
[2005-09-12 11:13:03] eric dot bourlon at gmail dot com
Description:
I'm using SOAP in non WSDL mode. The location URL of my SOAP server
contains a # character. When calling a function on this server the
posted URL is truncated at the position of the # character.
This may be a supplementary case of the already reported bug 28702 but
not solved in last CVS.
Reproduce code:
---
$accountCode="1234";
$saidsoap=new SoapClient();
$SoapClient_options=array('location'=>
"http://my.server.be/cgi-bin/ws_account.cgi#ws_account";,
'uri'=>
"http://my.server.be/cgi-bin/ws_account_view";,
'proxy_host' => "192.168.157.111",
'proxy_port' => 8080,
'proxy_login'=> "toto",
'proxy_password' => "tata",
'trace' => 1);
$saidsoap->__construct(NULL,SoapClient_options);
$input_param[]=new SoapParam($accountCode, "account_oidval");
$output_param=$saidsoap->__soapCall("wsACCOUNTVIEWIn",$input_param,$SoapClient_options);
Expected result:
POST http://my.server.be/cgi-bin/ws_account.cgi#ws_account HTTP/1.1
Host: my.server.be
Connection: Keep-Alive
User-Agent: PHP SOAP 0.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://my.server.be/cgi-bin/ws_account";
Content-Length: 568
Proxy-Authorization: Basic ZWJvdXJsb246cHllMDIw
Actual result:
--
POST http://my.server.be/cgi-bin/ws_account.cgi HTTP/1.1
Host: my.server.be
Connection: Keep-Alive
User-Agent: PHP SOAP 0.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://my.server.be/cgi-bin/ws_account";
Content-Length: 568
Proxy-Authorization: Basic ZWJvdXJsb246cHllMDIw
--
Edit this bug report at http://bugs.php.net/?id=34478&edit=1
#34519 [Bgs]: Unexpected return value
ID: 34519 User updated by: douglas at gcoders dot net Reported By: douglas at gcoders dot net Status: Bogus Bug Type: Date/time related Operating System: FreeBSD PHP Version: 5.1.0RC1 New Comment: Yes, before 5.1, expected return is -1 instead of FALSE Previous Comments: [2005-09-16 04:57:18] [EMAIL PROTECTED] The behavior is correct, although it is different from < PHP 5.1.0. [2005-09-16 01:56:18] douglas at gcoders dot net Sorry, expect result is bool(FALSE) not bool(NULL) [2005-09-16 01:53:25] douglas at gcoders dot net Description: When using mktime(0, 0, 0, 0, 0, 0), the returned value is different of expected. ONLY after update to 5.1RC1, before, it's ok. Reproduce code: --- http://bugs.php.net/?id=34519&edit=1
#34518 [Asn->Csd]: copy-on-write error
ID: 34518 Updated by: [EMAIL PROTECTED] Reported By: genome at digitaljunkies dot ca -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-09-15 Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_1. Previous Comments: [2005-09-16 10:09:19] [EMAIL PROTECTED] Dmitry, I think it was you who fixed the problem in bug #27381, can you check this one out? [2005-09-16 00:02:30] genome at digitaljunkies dot ca Description: Altering a subindex of a copy of an array alters the original array as well. Similar to bug#27381. Altering a root index does not exhibit this behaviour. Reproduce code: --- Expected result: Array ( [0] => 1 [1] => 2 [2] => 3 [foo] => Array ( [0] => 4 [1] => 5 [2] => 6 ) ) Actual result: -- Array ( [0] => 1 [1] => 2 [2] => 3 [foo] => Array ( [1] => 5 [2] => 6 ) ) -- Edit this bug report at http://bugs.php.net/?id=34518&edit=1
#34528 [NEW]: strange destructor behavior
From: silencer at reignofwar dot de
Operating system: Ubuntu 5.10 (Linux 2.6.12)
PHP version: 5.0.5
PHP Bug Type: Class/Object related
Bug description: strange destructor behavior
Description:
Only look at the code and the output of it. I think, new
objects in variables, which are already existent and
contain an old object, should be call the destructor of
the old object... im sorry for my english...
Reproduce code:
---
";
}
public function __destruct() {
echo "dead" . self::$i . "";
}
}
$obj = new test;
$obj = new test;
?>
Expected result:
alive: 1
dead1
alive: 2
dead2
Actual result:
--
alive: 1
alive: 2
dead2
dead2
--
Edit bug report at http://bugs.php.net/?id=34528&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34528&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34528&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34528&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34528&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34528&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34528&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34528&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34528&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34528&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34528&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34528&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34528&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34528&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34528&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34528&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34528&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34528&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34528&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34528&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34528&r=mysqlcfg
#34528 [Opn->Bgs]: strange destructor behavior
ID: 34528
Updated by: [EMAIL PROTECTED]
Reported By: silencer at reignofwar dot de
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Ubuntu 5.10 (Linux 2.6.12)
PHP Version: 5.0.5
New Comment:
__construct() call are always run before __destruct(). Latter being
done during request shutdown. No bug here.
Previous Comments:
[2005-09-16 16:39:56] silencer at reignofwar dot de
Description:
Only look at the code and the output of it. I think, new
objects in variables, which are already existent and
contain an old object, should be call the destructor of
the old object... im sorry for my english...
Reproduce code:
---
";
}
public function __destruct() {
echo "dead" . self::$i . "";
}
}
$obj = new test;
$obj = new test;
?>
Expected result:
alive: 1
dead1
alive: 2
dead2
Actual result:
--
alive: 1
alive: 2
dead2
dead2
--
Edit this bug report at http://bugs.php.net/?id=34528&edit=1
#21306 [Opn->Fbk]: [PATCH] warning about "cannot change the session settings"
ID: 21306
Updated by: [EMAIL PROTECTED]
Reported By: Xuefer at 21cn dot com
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: linux
-PHP Version: PHP 4.4.1 cvs (cgi-fcgi) (cvs up/built: Sep 14 2005
14:13:54)
+PHP Version: 4CVS (2005-09-14)
Assigned To: sas
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
And provide a script that actually is usable. For that script it's
perfectly fine to give an error..
Also: The version string in the 'Version' field in the bug reports MUST
start with a number 4,5 or 6.
Previous Comments:
[2005-09-14 08:32:02] Xuefer at 21cn dot com
i have verified it in lastest cvs in 4.4 branch.
./sapi/cgi/php -c /home/xuefer/etc/php.ini test.php
Content-type: text/html
X-Powered-By: PHP/4.4.1-dev
Set-Cookie: PHPSESSID=b50128d8959939728d21dd36eaf15b7c; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma: no-cache
Warning: Unknown(): A session is active. You cannot change the
session module's ini settings at this time. in Unknown on line
0
php.ini:
include_path=".:/usr/local/lib/php"
display_errors=On
error_reporting=E_ALL
log_errors = On
error_log = /tmp/phperr
memory_limit = 50M
(no other options)
reproduce script:
[2005-09-02 08:44:21] [EMAIL PROTECTED]
Can not reproduce, there's been couple of reports and none them with
proper way to get this reproduced. Most likely user error.
[2005-02-12 09:23:34] Xuefer at 21cn dot com
confirmed with CVS
again, exit() in sess_write() cause this issue
other modules after session module is not shutdown properly
i don't see any fix in the php4-src/ext/session/ source
[2005-01-25 15:28:30] [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-11-08 17:24:27] Xuefer at 21cn dot com
i guess i've found the bug
it's a "exception safe" problem as c++
well, not php5 exception, i meant zend_bailout(longjmp)
when write handler issue a Fatal error, will trigger zend_bailout() and
skip ALL other modules rshutdown, including the one right after
session_flush_data();
session.c:
static void php_session_flush(TSRMLS_D)
{
if(PS(session_status)==php_session_active) {
php_session_save_current_state(TSRMLS_C); <-- NOT exception
safe using for mod_user.c
}
PS(session_status)=php_session_none; <- WON'T executed when
zend_bailout
}
suggested fix:
mod_user.c :: function PS_WRITE_FUNC(user)
chnage
==
retval = ps_call_handler(PSF(write), 2, args TSRMLS_CC);
==
to
==
zend_try {
retval = ps_call_handler(PSF(write), 2, args TSRMLS_CC);
} zend_end_try();
==
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/21306
--
Edit this bug report at http://bugs.php.net/?id=21306&edit=1
#34524 [Bgs]: session_regenerate_id doubles request
ID: 34524
Updated by: [EMAIL PROTECTED]
Reported By: zoom at atlas dot sk
Status: Bogus
Bug Type: Session related
Operating System: WinXP
PHP Version: 5.1.0RC2
New Comment:
AND I can't reproduce it with your incomplete script either.
Previous Comments:
[2005-09-16 15:08:10] [EMAIL PROTECTED]
Like Lennon sang, "let it be, let it be.." (your script was incomplete)
[2005-09-16 14:37:09] zoom at atlas dot sk
everything neccessary is already here. I have nothing to add to this.
solve it, or let it be. I dont care.
[2005-09-16 14:12:06] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-09-16 13:47:19] zoom at atlas dot sk
here is sniplet of my code that should authentificate user, rewrite
current session_id, assign some attribute to it and let him go to next
page.
//
session_start()
session_regenerate_id(true);
$sql = "INSERT INTO logins VALUES ('{$log_date}','{$IP['addr']}')";
$db->query($sql);
$_SESSION['userid'] = $uid;
$link = "Location: http://"; . $CONFIG['APP_HOST'] . "in/";
session_commit();
header($link);
// expected behaviour
1. rewrite session id (I use cookies to propagate SID) and keep current
attributes.
2. remove old session file from filesystem
3. insert 1 record into database
4. add new attribute into $_SESSION['uid']
5. redirect user to new page
// actual results
1. rewrite session id (cookie) and file
2. remove old session file (*randomly* error "Warning:
session_regenerate_id() [function.session-regenerate-id]: Session
object destruction failed in" occurs!)
3. 2 records are inserted into database (instead of one)
4. ok
5. if no error occured in point 2, then redirect is ok.
Used system is
WinXP - SP2
PHP5.1RC2 instaled in SAPI mode
Apache 2.0.53
Clients used: IE6, Firefox1.0.6
[2005-09-16 12:01:12] [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.
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/34524
--
Edit this bug report at http://bugs.php.net/?id=34524&edit=1
#34524 [Opn->Bgs]: session_regenerate_id doubles request
ID: 34524
Updated by: [EMAIL PROTECTED]
Reported By: zoom at atlas dot sk
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: WinXP
PHP Version: 5.1.0RC2
New Comment:
Like Lennon sang, "let it be, let it be.." (your script was incomplete)
Previous Comments:
[2005-09-16 14:37:09] zoom at atlas dot sk
everything neccessary is already here. I have nothing to add to this.
solve it, or let it be. I dont care.
[2005-09-16 14:12:06] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-09-16 13:47:19] zoom at atlas dot sk
here is sniplet of my code that should authentificate user, rewrite
current session_id, assign some attribute to it and let him go to next
page.
//
session_start()
session_regenerate_id(true);
$sql = "INSERT INTO logins VALUES ('{$log_date}','{$IP['addr']}')";
$db->query($sql);
$_SESSION['userid'] = $uid;
$link = "Location: http://"; . $CONFIG['APP_HOST'] . "in/";
session_commit();
header($link);
// expected behaviour
1. rewrite session id (I use cookies to propagate SID) and keep current
attributes.
2. remove old session file from filesystem
3. insert 1 record into database
4. add new attribute into $_SESSION['uid']
5. redirect user to new page
// actual results
1. rewrite session id (cookie) and file
2. remove old session file (*randomly* error "Warning:
session_regenerate_id() [function.session-regenerate-id]: Session
object destruction failed in" occurs!)
3. 2 records are inserted into database (instead of one)
4. ok
5. if no error occured in point 2, then redirect is ok.
Used system is
WinXP - SP2
PHP5.1RC2 instaled in SAPI mode
Apache 2.0.53
Clients used: IE6, Firefox1.0.6
[2005-09-16 12:01:12] [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.
[2005-09-16 11:59:38] zoom at atlas dot sk
Description:
I use following order of code after users log-in, to regenerate session
id.
session_start()
...checking values...
...assigning values into $_SESSION
session_regenerate_id(true)
...inserting into database, date and IP of log event.
session_commit()
header() redirect into another page to show private content.
interesting thing is, that every time I run this script I get 2!
inserts into database - as there were 2 logins occured.
I use IE6 and FF and have also *random* problems with session_destroy()
function.
In debugging process I uncovered this above.
--
Edit this bug report at http://bugs.php.net/?id=34524&edit=1
#34527 [NEW]: trim functions extension
From: [EMAIL PROTECTED] Operating system: W2K PHP version: 6CVS-2005-09-16 (CVS) PHP Bug Type: Feature/Change Request Bug description: trim functions extension Description: To PHP 6 RFE list. Make trim functions accept arrays. -- Edit bug report at http://bugs.php.net/?id=34527&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34527&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34527&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34527&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34527&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34527&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34527&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34527&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34527&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34527&r=support Expected behavior: http://bugs.php.net/fix.php?id=34527&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34527&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34527&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34527&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34527&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34527&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34527&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34527&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34527&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34527&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34527&r=mysqlcfg
#34524 [Fbk->Opn]: session_regenerate_id doubles request
ID: 34524
User updated by: zoom at atlas dot sk
Reported By: zoom at atlas dot sk
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: WinXP
PHP Version: 5.1.0RC2
New Comment:
everything neccessary is already here. I have nothing to add to this.
solve it, or let it be. I dont care.
Previous Comments:
[2005-09-16 14:12:06] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-09-16 13:47:19] zoom at atlas dot sk
here is sniplet of my code that should authentificate user, rewrite
current session_id, assign some attribute to it and let him go to next
page.
//
session_start()
session_regenerate_id(true);
$sql = "INSERT INTO logins VALUES ('{$log_date}','{$IP['addr']}')";
$db->query($sql);
$_SESSION['userid'] = $uid;
$link = "Location: http://"; . $CONFIG['APP_HOST'] . "in/";
session_commit();
header($link);
// expected behaviour
1. rewrite session id (I use cookies to propagate SID) and keep current
attributes.
2. remove old session file from filesystem
3. insert 1 record into database
4. add new attribute into $_SESSION['uid']
5. redirect user to new page
// actual results
1. rewrite session id (cookie) and file
2. remove old session file (*randomly* error "Warning:
session_regenerate_id() [function.session-regenerate-id]: Session
object destruction failed in" occurs!)
3. 2 records are inserted into database (instead of one)
4. ok
5. if no error occured in point 2, then redirect is ok.
Used system is
WinXP - SP2
PHP5.1RC2 instaled in SAPI mode
Apache 2.0.53
Clients used: IE6, Firefox1.0.6
[2005-09-16 12:01:12] [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.
[2005-09-16 11:59:38] zoom at atlas dot sk
Description:
I use following order of code after users log-in, to regenerate session
id.
session_start()
...checking values...
...assigning values into $_SESSION
session_regenerate_id(true)
...inserting into database, date and IP of log event.
session_commit()
header() redirect into another page to show private content.
interesting thing is, that every time I run this script I get 2!
inserts into database - as there were 2 logins occured.
I use IE6 and FF and have also *random* problems with session_destroy()
function.
In debugging process I uncovered this above.
--
Edit this bug report at http://bugs.php.net/?id=34524&edit=1
#34524 [Opn->Fbk]: session_regenerate_id doubles request
ID: 34524
Updated by: [EMAIL PROTECTED]
Reported By: zoom at atlas dot sk
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: WinXP
PHP Version: 5.1.0RC1
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Previous Comments:
[2005-09-16 13:47:19] zoom at atlas dot sk
here is sniplet of my code that should authentificate user, rewrite
current session_id, assign some attribute to it and let him go to next
page.
//
session_start()
session_regenerate_id(true);
$sql = "INSERT INTO logins VALUES ('{$log_date}','{$IP['addr']}')";
$db->query($sql);
$_SESSION['userid'] = $uid;
$link = "Location: http://"; . $CONFIG['APP_HOST'] . "in/";
session_commit();
header($link);
// expected behaviour
1. rewrite session id (I use cookies to propagate SID) and keep current
attributes.
2. remove old session file from filesystem
3. insert 1 record into database
4. add new attribute into $_SESSION['uid']
5. redirect user to new page
// actual results
1. rewrite session id (cookie) and file
2. remove old session file (*randomly* error "Warning:
session_regenerate_id() [function.session-regenerate-id]: Session
object destruction failed in" occurs!)
3. 2 records are inserted into database (instead of one)
4. ok
5. if no error occured in point 2, then redirect is ok.
Used system is
WinXP - SP2
PHP5.1RC2 instaled in SAPI mode
Apache 2.0.53
Clients used: IE6, Firefox1.0.6
[2005-09-16 12:01:12] [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.
[2005-09-16 11:59:38] zoom at atlas dot sk
Description:
I use following order of code after users log-in, to regenerate session
id.
session_start()
...checking values...
...assigning values into $_SESSION
session_regenerate_id(true)
...inserting into database, date and IP of log event.
session_commit()
header() redirect into another page to show private content.
interesting thing is, that every time I run this script I get 2!
inserts into database - as there were 2 logins occured.
I use IE6 and FF and have also *random* problems with session_destroy()
function.
In debugging process I uncovered this above.
--
Edit this bug report at http://bugs.php.net/?id=34524&edit=1
#34525 [Opn->Csd]: Configuration problem with solaris 10 LDAP
ID: 34525 Updated by: [EMAIL PROTECTED] Reported By: webtech at get-telecom dot fr -Status: Open +Status: Closed -Bug Type: *Configuration Issues +Bug Type: LDAP related Operating System: Solaris 10 PHP Version: 5.0.5 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Fix will be in PHP 5.1. Previous Comments: [2005-09-16 13:59:24] webtech at get-telecom dot fr Description: Here is my configuration command : ./configure --prefix=/www/php-5.0.5/ --with-gd --with-apxs2=/www/apache-2.0.54/bin/apxs --with-mysql=/db/mysql --with-jpeg-dir=/usr/local/ --enable-gd-native-ttf --enable-gd-imgstrttf --with-ldap=/usr --with-libxml-dir=/usr --with-zlib-dir=/usr And I have this result : configure: error: Cannot find ldap libraries in /usr/lib. But in my /usr/lib, I've got : libldap.so -> libldap.so.5 libldap.so.4 libldap.so.5 And when I create a symbolic link libldap.so.3 -> libldap.so.5, the configuration for LDAP is OK... Is it a solution for my problem ? Why the libldap.so.5 is not supported by the ldap extension for PHP ? Is it possible to change your config.m4 in ext/ldap source folder ? -- Edit this bug report at http://bugs.php.net/?id=34525&edit=1
#34526 [NEW]: array-related operation to "reduce" contained items
From: soletan at toxa dot de Operating system: Linux PHP version: 5.0.5 PHP Bug Type: Feature/Change Request Bug description: array-related operation to "reduce" contained items Description: Is it possible to have an array_-method to perform the transformation on arrays as given below. Since I am working with DBs and wrapping records of tables using classes I often get the case to receive an array as given below and require to pass the list of IDs, only. For sure I can do the transformation all by myself in PHP using foreach. But since my software is getting more and more complex I appreciate any chance to increase my scripts' performance by having such trivial tasks being done in one step. Reproduce code: --- before: array( array( 'id' => 1, 'foo' => 'bar' ), array( 'id' => 2, 'foo' => 'bar' ), array( 'id' => 3, 'foo' => 'bar' ), array( 'id' => 4, 'foo' => 'bar' ), array( 'id' => 5, 'foo' => 'bar' ) ); action: $out = array_x( $in, 'id' ); result: array( 1, 2, 3, 4, 5 ); -- Edit bug report at http://bugs.php.net/?id=34526&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34526&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34526&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34526&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34526&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34526&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34526&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34526&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34526&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34526&r=support Expected behavior: http://bugs.php.net/fix.php?id=34526&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34526&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34526&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34526&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34526&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34526&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34526&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34526&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34526&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34526&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34526&r=mysqlcfg
#34525 [NEW]: Configuration problem with solaris 10 LDAP
From: webtech at get-telecom dot fr Operating system: Solaris 10 PHP version: 5.0.5 PHP Bug Type: *Configuration Issues Bug description: Configuration problem with solaris 10 LDAP Description: Here is my configuration command : ./configure --prefix=/www/php-5.0.5/ --with-gd --with-apxs2=/www/apache-2.0.54/bin/apxs --with-mysql=/db/mysql --with-jpeg-dir=/usr/local/ --enable-gd-native-ttf --enable-gd-imgstrttf --with-ldap=/usr --with-libxml-dir=/usr --with-zlib-dir=/usr And I have this result : configure: error: Cannot find ldap libraries in /usr/lib. But in my /usr/lib, I've got : libldap.so -> libldap.so.5 libldap.so.4 libldap.so.5 And when I create a symbolic link libldap.so.3 -> libldap.so.5, the configuration for LDAP is OK... Is it a solution for my problem ? Why the libldap.so.5 is not supported by the ldap extension for PHP ? Is it possible to change your config.m4 in ext/ldap source folder ? -- Edit bug report at http://bugs.php.net/?id=34525&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34525&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34525&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34525&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34525&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34525&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34525&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34525&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34525&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34525&r=support Expected behavior: http://bugs.php.net/fix.php?id=34525&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34525&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34525&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34525&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34525&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34525&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34525&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34525&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34525&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34525&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34525&r=mysqlcfg
#34524 [Fbk->Opn]: session_regenerate_id doubles request
ID: 34524
User updated by: zoom at atlas dot sk
Reported By: zoom at atlas dot sk
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: WinXP
PHP Version: 5.1.0RC1
New Comment:
here is sniplet of my code that should authentificate user, rewrite
current session_id, assign some attribute to it and let him go to next
page.
//
session_start()
session_regenerate_id(true);
$sql = "INSERT INTO logins VALUES ('{$log_date}','{$IP['addr']}')";
$db->query($sql);
$_SESSION['userid'] = $uid;
$link = "Location: http://"; . $CONFIG['APP_HOST'] . "in/";
session_commit();
header($link);
// expected behaviour
1. rewrite session id (I use cookies to propagate SID) and keep current
attributes.
2. remove old session file from filesystem
3. insert 1 record into database
4. add new attribute into $_SESSION['uid']
5. redirect user to new page
// actual results
1. rewrite session id (cookie) and file
2. remove old session file (*randomly* error "Warning:
session_regenerate_id() [function.session-regenerate-id]: Session
object destruction failed in" occurs!)
3. 2 records are inserted into database (instead of one)
4. ok
5. if no error occured in point 2, then redirect is ok.
Used system is
WinXP - SP2
PHP5.1RC2 instaled in SAPI mode
Apache 2.0.53
Clients used: IE6, Firefox1.0.6
Previous Comments:
[2005-09-16 12:01:12] [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.
[2005-09-16 11:59:38] zoom at atlas dot sk
Description:
I use following order of code after users log-in, to regenerate session
id.
session_start()
...checking values...
...assigning values into $_SESSION
session_regenerate_id(true)
...inserting into database, date and IP of log event.
session_commit()
header() redirect into another page to show private content.
interesting thing is, that every time I run this script I get 2!
inserts into database - as there were 2 logins occured.
I use IE6 and FF and have also *random* problems with session_destroy()
function.
In debugging process I uncovered this above.
--
Edit this bug report at http://bugs.php.net/?id=34524&edit=1
#34089 [Opn->Fbk]: Configure fails build test for libxml2
ID: 34089 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: Mac OS X 10.4.2 PHP Version: 6CVS-2005-08-12 New Comment: Can you reproduce this on some other Macosx machine? Can someone else reproduce this? Previous Comments: [2005-09-15 23:20:58] [EMAIL PROTECTED] I grabbed the latest HEAD and I'm using the latest ICU (v3.4). With the following config line, everything configures, makes, and make installs just fine: ./configure --with-layout=PHP --prefix=/usr/local/php/6.0.0 --disable-all --with-icu-dir=/usr/local/icu However, I still receive an error: ramsey:~ ramsey$ /usr/local/php/6.0.0/bin/php -i dyld: Library not loaded: libicui18n.dylib.34 Referenced from: /usr/local/php/6.0.0/bin/php Reason: image not found Trace/BPT trap [2005-09-13 09:54:19] [EMAIL PROTECTED] Try with newer icu release and latest CVS HEAD. [2005-08-23 20:18:58] [EMAIL PROTECTED] I did compile icu myself. I followed Andrei's instructions to download and build it. It compiled just fine without any problems. Andrei's instructions are here: http://news.php.net/php.internals/17848 [2005-08-23 17:32:16] [EMAIL PROTECTED] Try compiling the icu library yourself? [2005-08-17 20:21:11] [EMAIL PROTECTED] That configure line works. I tried: # ./configure --with-layout=PHP --prefix=/usr/local/php/6.0.0 --disable-all --with-icu-dir=/usr/local/icu # make # make install All worked just fine, but now I'm getting a "Library not loaded" error. ramsey:~ ramsey$ /usr/local/php/6.0.0/bin/php -m dyld: Library not loaded: libicui18n.dylib.34 Referenced from: /usr/local/php/6.0.0/bin/php Reason: image not found Trace/BPT trap 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/34089 -- Edit this bug report at http://bugs.php.net/?id=34089&edit=1
#34524 [Opn->Fbk]: session_regenerate_id doubles request
ID: 34524 Updated by: [EMAIL PROTECTED] Reported By: zoom at atlas dot sk -Status: Open +Status: Feedback Bug Type: Session related Operating System: WinXP PHP Version: 5.1.0RC1 New Comment: 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. Previous Comments: [2005-09-16 11:59:38] zoom at atlas dot sk Description: I use following order of code after users log-in, to regenerate session id. session_start() ...checking values... ...assigning values into $_SESSION session_regenerate_id(true) ...inserting into database, date and IP of log event. session_commit() header() redirect into another page to show private content. interesting thing is, that every time I run this script I get 2! inserts into database - as there were 2 logins occured. I use IE6 and FF and have also *random* problems with session_destroy() function. In debugging process I uncovered this above. -- Edit this bug report at http://bugs.php.net/?id=34524&edit=1
#34524 [NEW]: session_regenerate_id doubles request
From: zoom at atlas dot sk Operating system: WinXP PHP version: 5.1.0RC1 PHP Bug Type: Session related Bug description: session_regenerate_id doubles request Description: I use following order of code after users log-in, to regenerate session id. session_start() ...checking values... ...assigning values into $_SESSION session_regenerate_id(true) ...inserting into database, date and IP of log event. session_commit() header() redirect into another page to show private content. interesting thing is, that every time I run this script I get 2! inserts into database - as there were 2 logins occured. I use IE6 and FF and have also *random* problems with session_destroy() function. In debugging process I uncovered this above. -- Edit bug report at http://bugs.php.net/?id=34524&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34524&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34524&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34524&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34524&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34524&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34524&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34524&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34524&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34524&r=support Expected behavior: http://bugs.php.net/fix.php?id=34524&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34524&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34524&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34524&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34524&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34524&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34524&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34524&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34524&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34524&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34524&r=mysqlcfg
#34509 [Opn->Fbk]: APACHE_VERSION variable in configure is nonsense
ID: 34509
Updated by: [EMAIL PROTECTED]
Reported By: peter dot buki at vodafone dot hu
-Status: Open
+Status: Feedback
Bug Type: Compile Failure
Operating System: SunOS 5.9 Generic_112233-01
PHP Version: 5.1.0RC1
New Comment:
What does this output:
# /usr/apache/bin/httpd -v
Previous Comments:
[2005-09-16 10:47:55] peter dot buki at vodafone dot hu
Hope it helps:
APXS=/usr/apache/bin/apxs
EDITOR=vi
HOME=/export/home/vodafone
HOSTNAME=mis
HOSTTYPE=sparc
HTTPD=/usr/apache/bin/httpd
IFS=- /.
LOGNAME=vodafone
MACHTYPE=sparc-sun-solaris2.9
MAILCHECK=600
OLDPWD=/export/home/vodafone
OPTIND=1
OSTYPE=solaris2.9
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/ccs/bin
[EMAIL PROTECTED] \W]\$
PWD=/export/home/vodafone/src
SHELL=/bin/bash
SHLVL=2
SSH_TTY=/dev/pts/4
STY=11381.pts-4.mis
TERM=xterm
TERMCAP=SC|xterm|VT 100/ANSI X3.64 virtual terminal:\
:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\
:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\
:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\
:li#53:co#138:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\
:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\
:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\
:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\
:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E[24m:so=\E[3m:\
:se=\E[23m:md=\E[1m:mr=\E[7m:me=\E[m:ms:\
:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:G0:\
:as=\E(0:ae=\E(B:\
:ac=\140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\
:k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:\
:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:\
:F1=\E[23~:F2=\E[24~:F3=\E[25~:F4=\E[26~:F5=\E[28~:\
:F6=\E[29~:F7=\E[31~:F8=\E[32~:F9=\E[33~:FA=\E[34~:\
:kb=^H:kh=\E[1~:@1=\E[1~:kH=\E[4~:@7=\E[4~:kN=\E[6~:\
:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:kr=\EOC:\
:kl=\EOD:km:
TZ=Europe/Budapest
USER=vodafone
WINDOW=3
_=./apache.sh
ac_IFS=
ac_output=
expr: syntax error
[2005-09-15 20:40:34] [EMAIL PROTECTED]
Please download this script:
http://www.php.net/~jani/patches/apache.sh
Make it executable and run it and paste the output here.
[2005-09-15 14:33:43] peter dot buki at vodafone dot hu
Sorry for leaving out the possibility to filter out the most simple
cause. Apache/2.0.54 compiled on Aug 22 2005 16:34:58.
[EMAIL PROTECTED] php-5.1.0RC1]# /usr/local/apache2/bin/httpd -v
Server version: Apache/2.0.54
Server built: Aug 22 2005 16:34:58
[2005-09-15 14:30:47] [EMAIL PROTECTED]
So what apache version do you have? What is the output of
httpd -v ?
[2005-09-15 11:09:14] peter dot buki at vodafone dot hu
Description:
Variable APACHE_VERSION is calculated in a wrong way, because configure
halts, event if the apache has the required and set with --with-apxs2
version
configure returns with syntax error:
expr: syntax error
configure: error: You have enabled Apache 2 support while your server
is Apache 1.3. Please use the appropiate switch --with-apxs (without
the 2)
Please see possibly related bugs:
Bug #20457: APACHE_VERSION variable in configure is nonsense
Bug #23416: configure not knowing apache version
Reproduce code:
---
./config.nice:
CC='gcc -m64 -mcpu=v9' \
'./configure' \
'--with-apxs2=/usr/apache/bin/apxs' \
'--libexecdir=/usr/apache/libexec' \
'--enable-sysvmsg' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-mbstring=all' \
'--enable-sigchild' \
'--enable-sockets' \
'--enable-mbstring' \
'--with-postgresql=/usr/local/pgsql/' \
'--disable-shared' \
'--with-libxml-dir=/usr/local' \
"$@"
Expected result:
Configure going on with no errors.
Actual result:
--
configure returns with syntax error:
expr: syntax error
configure: error: You have enabled Apache 2 support while your server
is Apache 1.3. Please use the appropiate switch --with-apxs (without
the 2)
Added this line to configure (line 4226, 5534, 6366):
echo APACHE_VERSION \($APACHE_VERSION\) is calculated: $4 \* 100
+ $5 \* 1000 + $6
which prints this:
APACHE_VERSION () is calculated: * 100 + * 1000 +
--
Edit this bug report at http://bugs.php.net/?id=34509&edit=1
#34512 [Opn->Csd]: libphp5.so doesn't get built if --with-mysqli option is set
ID: 34512 Updated by: [EMAIL PROTECTED] Reported By: dar_tay at hotmail dot com -Status: Open +Status: Closed Bug Type: MySQLi related Operating System: Linux version 2.6.8-2-386 PHP Version: 5CVS-2005-09-15 (snap) New Comment: Let's close this for now. If someone else can actually reproduce this, I'll look again into this. Previous Comments: [2005-09-16 10:27:52] dar_tay at hotmail dot com I don't see how my install could be messed up, I've only every used apt-get to install packages, this is the first time I've needed to build anything. Having said that I seem to have solved it this morning, --enable-static seems to have done the trick. Thanks for taking the time to look into this. [2005-09-16 10:15:09] [EMAIL PROTECTED] I don't think this is any bug in PHP, it's just your Debian installation that is really messed up. Can you reproduce this on any other machine?? [2005-09-15 22:52:54] dar_tay at hotmail dot com Debian version is 'sarge' config log sent via email. [2005-09-15 20:10:09] [EMAIL PROTECTED] I meant what Debian version you have. (they have names like Potato, etc..) Please send me the config.log from the failing build. [2005-09-15 20:06:18] dar_tay at hotmail dot com Installed gawk, didn't make any difference. # sh config.guess # i686-pc-linux-gnu Not sure I understand the question regarding what debian it is?... it's a debian install from debian.org? Will build Apache2 from source and see if that helps. 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/34512 -- Edit this bug report at http://bugs.php.net/?id=34512&edit=1
#34509 [Fbk->Opn]: APACHE_VERSION variable in configure is nonsense
ID: 34509
User updated by: peter dot buki at vodafone dot hu
Reported By: peter dot buki at vodafone dot hu
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: SunOS 5.9 Generic_112233-01
PHP Version: 5.1.0RC1
New Comment:
Hope it helps:
APXS=/usr/apache/bin/apxs
EDITOR=vi
HOME=/export/home/vodafone
HOSTNAME=mis
HOSTTYPE=sparc
HTTPD=/usr/apache/bin/httpd
IFS=- /.
LOGNAME=vodafone
MACHTYPE=sparc-sun-solaris2.9
MAILCHECK=600
OLDPWD=/export/home/vodafone
OPTIND=1
OSTYPE=solaris2.9
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/ccs/bin
[EMAIL PROTECTED] \W]\$
PWD=/export/home/vodafone/src
SHELL=/bin/bash
SHLVL=2
SSH_TTY=/dev/pts/4
STY=11381.pts-4.mis
TERM=xterm
TERMCAP=SC|xterm|VT 100/ANSI X3.64 virtual terminal:\
:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\
:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\
:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\
:li#53:co#138:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\
:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\
:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\
:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\
:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E[24m:so=\E[3m:\
:se=\E[23m:md=\E[1m:mr=\E[7m:me=\E[m:ms:\
:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:G0:\
:as=\E(0:ae=\E(B:\
:ac=\140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\
:k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:\
:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:\
:F1=\E[23~:F2=\E[24~:F3=\E[25~:F4=\E[26~:F5=\E[28~:\
:F6=\E[29~:F7=\E[31~:F8=\E[32~:F9=\E[33~:FA=\E[34~:\
:kb=^H:kh=\E[1~:@1=\E[1~:kH=\E[4~:@7=\E[4~:kN=\E[6~:\
:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:kr=\EOC:\
:kl=\EOD:km:
TZ=Europe/Budapest
USER=vodafone
WINDOW=3
_=./apache.sh
ac_IFS=
ac_output=
expr: syntax error
Previous Comments:
[2005-09-15 20:40:34] [EMAIL PROTECTED]
Please download this script:
http://www.php.net/~jani/patches/apache.sh
Make it executable and run it and paste the output here.
[2005-09-15 14:33:43] peter dot buki at vodafone dot hu
Sorry for leaving out the possibility to filter out the most simple
cause. Apache/2.0.54 compiled on Aug 22 2005 16:34:58.
[EMAIL PROTECTED] php-5.1.0RC1]# /usr/local/apache2/bin/httpd -v
Server version: Apache/2.0.54
Server built: Aug 22 2005 16:34:58
[2005-09-15 14:30:47] [EMAIL PROTECTED]
So what apache version do you have? What is the output of
httpd -v ?
[2005-09-15 11:09:14] peter dot buki at vodafone dot hu
Description:
Variable APACHE_VERSION is calculated in a wrong way, because configure
halts, event if the apache has the required and set with --with-apxs2
version
configure returns with syntax error:
expr: syntax error
configure: error: You have enabled Apache 2 support while your server
is Apache 1.3. Please use the appropiate switch --with-apxs (without
the 2)
Please see possibly related bugs:
Bug #20457: APACHE_VERSION variable in configure is nonsense
Bug #23416: configure not knowing apache version
Reproduce code:
---
./config.nice:
CC='gcc -m64 -mcpu=v9' \
'./configure' \
'--with-apxs2=/usr/apache/bin/apxs' \
'--libexecdir=/usr/apache/libexec' \
'--enable-sysvmsg' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-mbstring=all' \
'--enable-sigchild' \
'--enable-sockets' \
'--enable-mbstring' \
'--with-postgresql=/usr/local/pgsql/' \
'--disable-shared' \
'--with-libxml-dir=/usr/local' \
"$@"
Expected result:
Configure going on with no errors.
Actual result:
--
configure returns with syntax error:
expr: syntax error
configure: error: You have enabled Apache 2 support while your server
is Apache 1.3. Please use the appropiate switch --with-apxs (without
the 2)
Added this line to configure (line 4226, 5534, 6366):
echo APACHE_VERSION \($APACHE_VERSION\) is calculated: $4 \* 100
+ $5 \* 1000 + $6
which prints this:
APACHE_VERSION () is calculated: * 100 + * 1000 +
--
Edit this bug report at http://bugs.php.net/?id=34509&edit=1
#34512 [Fbk->Opn]: libphp5.so doesn't get built if --with-mysqli option is set
ID: 34512 User updated by: dar_tay at hotmail dot com Reported By: dar_tay at hotmail dot com -Status: Feedback +Status: Open Bug Type: MySQLi related Operating System: Linux version 2.6.8-2-386 PHP Version: 5CVS-2005-09-15 (snap) New Comment: I don't see how my install could be messed up, I've only every used apt-get to install packages, this is the first time I've needed to build anything. Having said that I seem to have solved it this morning, --enable-static seems to have done the trick. Thanks for taking the time to look into this. Previous Comments: [2005-09-16 10:15:09] [EMAIL PROTECTED] I don't think this is any bug in PHP, it's just your Debian installation that is really messed up. Can you reproduce this on any other machine?? [2005-09-15 22:52:54] dar_tay at hotmail dot com Debian version is 'sarge' config log sent via email. [2005-09-15 20:10:09] [EMAIL PROTECTED] I meant what Debian version you have. (they have names like Potato, etc..) Please send me the config.log from the failing build. [2005-09-15 20:06:18] dar_tay at hotmail dot com Installed gawk, didn't make any difference. # sh config.guess # i686-pc-linux-gnu Not sure I understand the question regarding what debian it is?... it's a debian install from debian.org? Will build Apache2 from source and see if that helps. [2005-09-15 19:47:56] [EMAIL PROTECTED] Another thing: exactly WHAT Debian is it? 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/34512 -- Edit this bug report at http://bugs.php.net/?id=34512&edit=1
#34522 [Opn->Bgs]: Unexpected output
ID: 34522 Updated by: [EMAIL PROTECTED] Reported By: tv at net4you dot bg -Status: Open +Status: Bogus Bug Type: Output Control Operating System: Windows XP/Apache 2.0.54 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-09-16 09:07:13] tv at net4you dot bg executing this code return an unexpected result. Changing echo "Error"; to return "Error"; fix the problem but in larger functions sometimes we need to print output. [2005-09-16 08:57:49] tv at net4you dot bg Description: executing this code return an unexpected result. Changing echo "Error"; to return "Error"; fix the problem put in larger functions sometimes we need to print output. Reproduce code: --- Expected result: testErrortest Actual result: -- Errortesttest -- Edit this bug report at http://bugs.php.net/?id=34522&edit=1
#34523 [Opn->Asn]: pdo drivers are not compiled due to compilation errors
ID: 34523 Updated by: [EMAIL PROTECTED] Reported By: dan at yes dot lt -Status: Open +Status: Assigned Bug Type: PDO related Operating System: windows PHP Version: 5CVS-2005-09-16 (snap) -Assigned To: +Assigned To: edink New Comment: This is either caused by the build machine using outdated sources/headers or mixing some PDO stuff from PECL and some from the core..or wrong branch? Previous Comments: [2005-09-16 09:11:25] dan at yes dot lt Description: PDO drivers are not compiled due to compilation errors Some lines from http://snaps.php.net/win32/snapshot-5.1.log ext\pdo_dblib\dblib_driver.c(250) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_mysql\mysql_driver.c(100) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_oci\oci_driver.c(161) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_odbc\odbc_driver.c(90) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_pgsql\pgsql_driver.c(83) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_sqlite\sqlite_driver.c(78) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_sqlite\sqlite_driver.c(695) : error C2198: 'php_pdo_get_exception' : too few actual parameters -- Edit this bug report at http://bugs.php.net/?id=34523&edit=1
#34502 [Bgs->Opn]: method chaining on constructor causes parse error
ID: 34502
User updated by: goat at daholygoat dot com
Reported By: goat at daholygoat dot com
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.0.5
New Comment:
@Johannes:
I don't really get your interpretion of the problem. A() is of course
the constructor (A() in A). The constructor returns an object of type
A. returnStr() is a method of A, so when calling returnStr() on a new
A(), it should invoke returnStr() on a new object of A. For example, in
Java it's fine to do this:
System.out.println(new Object().toString());
Which makes sense because when you _can_ do method chaining (which you
can in PHP5), there are many times where you just want to call one
chain on a new object, instead of seperately instantiating the class.
So I have to go with Derick pointing out it's simply not supported
right now.
Previous Comments:
[2005-09-14 23:25:33] [EMAIL PROTECTED]
By reading the code I'd expect that A is some function
returning an object. returnStr() being a method of that
object returning a class name used for new. (Somehow a
combination of "new $a;" and a simple
"function_call()->methodCallOnReturnedObject()" which is
possible since PHP 5) I would like some syntax like this,
too - but thinking about it I see too much confusion and
didn't find a nice solution which is clear when reading
code.
I set this to bogus since I think it's too much confusion,
but if you have a nice and clear syntax feel free to
re-open it - I'd be happy, but don't see how this is
possible without logic conflicts :-)
[2005-09-14 21:26:50] [EMAIL PROTECTED]
I think this is simply not supported right now, so marking as a Feature
Request
[2005-09-14 21:14:57] goat at daholygoat dot com
Description:
When doing method chaining on a constructor (without seperately
instantiating the object first), a parse error occurs.
Reproduce code:
---
class A
{
private $str;
function A($str)
{
$this->str = $str;
}
function returnStr()
{
return $str;
}
}
echo new A("hello")->returnStr();
Expected result:
The reference to an object of A created with A's constructor would
allow me to call returnStr() on it.
Actual result:
--
I'm getting a parse error.
PHP Parse error: parse error, unexpected T_OBJECT_OPERATOR, expecting
',' or ';'
--
Edit this bug report at http://bugs.php.net/?id=34502&edit=1
#34512 [Opn->Fbk]: libphp5.so doesn't get built if --with-mysqli option is set
ID: 34512 Updated by: [EMAIL PROTECTED] Reported By: dar_tay at hotmail dot com -Status: Open +Status: Feedback Bug Type: MySQLi related Operating System: Linux version 2.6.8-2-386 PHP Version: 5CVS-2005-09-15 (snap) New Comment: I don't think this is any bug in PHP, it's just your Debian installation that is really messed up. Can you reproduce this on any other machine?? Previous Comments: [2005-09-15 22:52:54] dar_tay at hotmail dot com Debian version is 'sarge' config log sent via email. [2005-09-15 20:10:09] [EMAIL PROTECTED] I meant what Debian version you have. (they have names like Potato, etc..) Please send me the config.log from the failing build. [2005-09-15 20:06:18] dar_tay at hotmail dot com Installed gawk, didn't make any difference. # sh config.guess # i686-pc-linux-gnu Not sure I understand the question regarding what debian it is?... it's a debian install from debian.org? Will build Apache2 from source and see if that helps. [2005-09-15 19:47:56] [EMAIL PROTECTED] Another thing: exactly WHAT Debian is it? [2005-09-15 19:47:07] [EMAIL PROTECTED] Why don't you have gawk installed? Please install it.. Another thing to try: Compile Apache2 yourself! The CFLAGS debian build has used are really weird considering you're using prefork MPM. Another thing going wrong is the host detection. What does this output (run in the source directory): # sh config.guess 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/34512 -- Edit this bug report at http://bugs.php.net/?id=34512&edit=1
#34518 [Opn->Asn]: copy-on-write error
ID: 34518 Updated by: [EMAIL PROTECTED] Reported By: genome at digitaljunkies dot ca -Status: Open +Status: Assigned Bug Type: Arrays related -Operating System: Linux +Operating System: * -PHP Version: 5.1.0RC1 +PHP Version: 5CVS-2005-09-15 -Assigned To: +Assigned To: dmitry New Comment: Dmitry, I think it was you who fixed the problem in bug #27381, can you check this one out? Previous Comments: [2005-09-16 00:02:30] genome at digitaljunkies dot ca Description: Altering a subindex of a copy of an array alters the original array as well. Similar to bug#27381. Altering a root index does not exhibit this behaviour. Reproduce code: --- Expected result: Array ( [0] => 1 [1] => 2 [2] => 3 [foo] => Array ( [0] => 4 [1] => 5 [2] => 6 ) ) Actual result: -- Array ( [0] => 1 [1] => 2 [2] => 3 [foo] => Array ( [1] => 5 [2] => 6 ) ) -- Edit this bug report at http://bugs.php.net/?id=34518&edit=1
#34468 [Csd]: Fatal error for current
ID: 34468
Updated by: [EMAIL PROTECTED]
Reported By: j dot gizmo at aon dot at
Status: Closed
Bug Type: Feature/Change Request
Operating System: Windows 2000 Server
PHP Version: 5.0.5
Assigned To: zeev
New Comment:
current() is fixed in CVS.
Previous Comments:
[2005-09-12 11:17:52] j dot gizmo at aon dot at
Okay, this bug isn't critical, but why is it a bogus? Is
current() supposed to work on variables only? In all previous
versions of PHP it worked on all arrays, wheter returned from
a function or stored in a variable or whatever. So WHY the new
behaviour starting with 5.0.5?
[2005-09-11 23:43:45] [EMAIL PROTECTED]
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
Feel free to fix the whole engine though with a patch...
[2005-09-11 23:35:16] j dot gizmo at aon dot at
Description:
current() only works on variables; no longer on arrays
returned from functions.
This also explains Bug #34424, which has been classified as
Bogus.
Reproduce code:
---
$x = current(explode(' ','a b'));
echo $x;
Expected result:
a
Actual result:
--
Fatal error: Only variables can be passed by reference in ...
--
However, the following DOES work as expected:
$a = current($x=&explode(" ","a b"));
This new behaviour breaks backward compatibility. Furthermore,
it introduces continuity problems. In both cases, an array is
passed to current(), only one time it is stored in a variable
and the other time it isn't. This should not make a
difference, because even a "temporary array" should have a
current element.
--
Edit this bug report at http://bugs.php.net/?id=34468&edit=1
#34468 [Bgs->Csd]: Fatal error for current
ID: 34468
Updated by: [EMAIL PROTECTED]
Reported By: j dot gizmo at aon dot at
-Status: Bogus
+Status: Closed
-Bug Type: Reproducible crash
+Bug Type: Feature/Change Request
Operating System: Windows 2000 Server
PHP Version: 5.0.5
Assigned To: zeev
Previous Comments:
[2005-09-12 11:17:52] j dot gizmo at aon dot at
Okay, this bug isn't critical, but why is it a bogus? Is
current() supposed to work on variables only? In all previous
versions of PHP it worked on all arrays, wheter returned from
a function or stored in a variable or whatever. So WHY the new
behaviour starting with 5.0.5?
[2005-09-11 23:43:45] [EMAIL PROTECTED]
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
Feel free to fix the whole engine though with a patch...
[2005-09-11 23:35:16] j dot gizmo at aon dot at
Description:
current() only works on variables; no longer on arrays
returned from functions.
This also explains Bug #34424, which has been classified as
Bogus.
Reproduce code:
---
$x = current(explode(' ','a b'));
echo $x;
Expected result:
a
Actual result:
--
Fatal error: Only variables can be passed by reference in ...
--
However, the following DOES work as expected:
$a = current($x=&explode(" ","a b"));
This new behaviour breaks backward compatibility. Furthermore,
it introduces continuity problems. In both cases, an array is
passed to current(), only one time it is stored in a variable
and the other time it isn't. This should not make a
difference, because even a "temporary array" should have a
current element.
--
Edit this bug report at http://bugs.php.net/?id=34468&edit=1
#34523 [NEW]: pdo drivers are not compiled due to compilation errors
From: dan at yes dot lt Operating system: windows PHP version: 5CVS-2005-09-16 (snap) PHP Bug Type: PDO related Bug description: pdo drivers are not compiled due to compilation errors Description: PDO drivers are not compiled due to compilation errors Some lines from http://snaps.php.net/win32/snapshot-5.1.log ext\pdo_dblib\dblib_driver.c(250) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_mysql\mysql_driver.c(100) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_oci\oci_driver.c(161) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_odbc\odbc_driver.c(90) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_pgsql\pgsql_driver.c(83) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_sqlite\sqlite_driver.c(78) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_sqlite\sqlite_driver.c(695) : error C2198: 'php_pdo_get_exception' : too few actual parameters -- Edit bug report at http://bugs.php.net/?id=34523&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34523&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34523&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34523&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34523&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34523&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34523&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34523&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34523&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34523&r=support Expected behavior: http://bugs.php.net/fix.php?id=34523&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34523&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34523&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34523&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34523&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34523&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34523&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34523&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34523&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34523&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34523&r=mysqlcfg
#34522 [Opn]: Unexpected output
ID: 34522 User updated by: tv at net4you dot bg Reported By: tv at net4you dot bg Status: Open Bug Type: Output Control Operating System: Windows XP/Apache 2.0.54 PHP Version: 5.1.0RC1 New Comment: executing this code return an unexpected result. Changing echo "Error"; to return "Error"; fix the problem but in larger functions sometimes we need to print output. Previous Comments: [2005-09-16 09:06:45] tv at net4you dot bg executing this code return an unexpected result. Changing echo "Error"; to return "Error"; fix the problem but in larger functions sometimes we need to print output. [2005-09-16 08:57:49] tv at net4you dot bg Description: executing this code return an unexpected result. Changing echo "Error"; to return "Error"; fix the problem put in larger functions sometimes we need to print output. Reproduce code: --- Expected result: testErrortest Actual result: -- Errortesttest -- Edit this bug report at http://bugs.php.net/?id=34522&edit=1
#34522 [Opn]: Unexpected output
ID: 34522 User updated by: tv at net4you dot bg Reported By: tv at net4you dot bg Status: Open Bug Type: Output Control Operating System: Windows XP/Apache 2.0.54 PHP Version: 5.1.0RC1 New Comment: executing this code return an unexpected result. Changing echo "Error"; to return "Error"; fix the problem but in larger functions sometimes we need to print output. Previous Comments: [2005-09-16 08:57:49] tv at net4you dot bg Description: executing this code return an unexpected result. Changing echo "Error"; to return "Error"; fix the problem put in larger functions sometimes we need to print output. Reproduce code: --- Expected result: testErrortest Actual result: -- Errortesttest -- Edit this bug report at http://bugs.php.net/?id=34522&edit=1
