#49191 [Bgs]: Unknown exception at 0x000006c5
ID: 49191 Updated by: paj...@php.net Reported By: bmhrules at hotmail dot com Status: Bogus Bug Type: IIS related Operating System: Windows Server 2003 Ent. X64 PHP Version: 5.2SVN-2009-08-07 (snap) New Comment: "As was stated I am not using the libmysql.dll that MySQL supplies in my PHP directory. " You have to use libmysql.dll provided in the PHP directory. Previous Comments: [2009-08-08 04:39:08] bmhrules at hotmail dot com As was stated I am not using the libmysql.dll that MySQL supplies in my PHP directory. I hope that this apparent misunderstanding is not the cause for this bug reports permanent closure. [2009-08-07 17:40:47] bmhrules at hotmail dot com As was stated, all files in the php directory are those that came in the ZIP. I was just making a note that there seems to be a file called libmysql.dll in the MySQL/bin folder. I believe that was placed there by the MySQL installer. I have no clue as of why there is one there or if it is even required. [2009-08-07 17:36:46] paj...@php.net Do not use mysql's libmysql with PHP but only the DLL provided in our releases. Add c:\php first in your PATH (or whatever is the path to PHP). [2009-08-07 17:33:07] bmhrules at hotmail dot com As of using the 5.2.11-dev(snap), MySQL has not been upgraded. Before the dev, I may have upgraded MySQL, but my memory fails me. All files in the PHP directory are those that came with the ZIP and nothing else. There is a libmysql.dll in the MySQL/bin folder though. I am currently running MySQL 5.1.36. [2009-08-07 17:27:56] paj...@php.net Did you update to a recent mysql after having installed PHP? Or is libmysql not the DLL present in the PHP releases? 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/49191 -- Edit this bug report at http://bugs.php.net/?id=49191&edit=1
#49200 [NEW]: stream bindto context generates an error
From: jeremy at ssnet dot ca
Operating system: FreeBSD 7.2-STABLE
PHP version: 6SVN-2009-08-09 (SVN)
PHP Bug Type: Streams related
Bug description: stream bindto context generates an error
Description:
Specifying any IP address for bindto in stream_context_set_option()
produces an error "(local_addr context option is not a string.)"
Reproduce code:
---
$context = stream_context_create ();
stream_context_set_option ($context, 'socket', 'bindto', '127.0.0.1:0');
$contents = file_get_contents ("http://php.net";, FALSE, $context);
Expected result:
Should return the contents of php.net
Actual result:
--
Warning: file_get_contents(http://php.net/): failed to open stream:
local_addr context option is not a string.
--
Edit bug report at http://bugs.php.net/?id=49200&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49200&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49200&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49200&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49200&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49200&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49200&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49200&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49200&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49200&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49200&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49200&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49200&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49200&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49200&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49200&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49200&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49200&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49200&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49200&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49200&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49200&r=mysqlcfg
#49182 [Com]: PHP CGI always outputs the shebang line
ID: 49182 Comment by: salsi at icosaedro dot it Reported By: salsi at icosaedro dot it Status: Feedback Bug Type: CGI related Operating System: Slackware 12.0 PHP Version: 5.3SVN-2009-08-06 (SVN) New Comment: I also noted that the CGI version considers the shebang line as "generated output", and then namespace declarations are not allowed. For example: #!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini tells Fatal error: Namespace declaration statement has to be the very first statement in the script in /home/salsi/php530/test.php on line 3 The CLI version /usr/local/php-5.3.0/bin/php instead works as expected and the shebang line is not displayed. Previous Comments: [2009-08-06 20:45:08] salsi at icosaedro dot it I'm using Apache 2.2.8 + suexec without any support for PHP (it executes only CGI programs) and all worked well with PHP 5.2.5 I used until now. But this should not care, as in my opinion the shebang should not be displayed once the script has been detected to be executed as a program. I configured PHP as follows: ./configure \ --disable-all \ --prefix=/usr/local/php-5.3.0 \ --exec-prefix=/usr/local/php-5.3.0 \ --disable-rpath \ --disable-ipv6 \ --enable-ftp=shared \ --enable-sockets=shared \ --enable-tokenizer \ --with-gnu-ld=shared \ --with-pgsql=shared \ --enable-session \ --enable-posix \ --with-pcre-regex \ --enable-mbstring=all \ --enable-mbregex \ --enable-libxml \ --enable-xml \ --enable-dom \ --enable-pdo I can also confirm that with the old version of PHP the shebang line did not came out under Apache and neither did it under the command line. [2009-08-06 20:01:38] j...@php.net What webserver? How did you configure PHP into it? [2009-08-06 18:59:41] salsi at icosaedro dot it Description: Executing any PHP CGI script always results in the shebang line being displayed along the correct HTML code of the WEB page. This happens with and without the --enable-discard-path configuration flag (although I'm not really sure this flag be realted to the issue or not). Reproduce code: --- #!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini Expected result: $ ./shebang.php X-Powered-By: PHP/5.3.1-dev Content-type: text/html 5.3.1-dev Actual result: -- $ ./shebang.php X-Powered-By: PHP/5.3.1-dev Content-type: text/html #!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini 5.3.1-dev -- Edit this bug report at http://bugs.php.net/?id=49182&edit=1
#49198 [Com]: Incorrect result for .*
ID: 49198
Comment by: inf3rno dot hu at gmail dot com
Reported By: inf3rno dot hu at gmail dot com
Status: Open
Bug Type: PCRE related
Operating System: *
PHP Version: 5.2.10
New Comment:
It's not preg_match_all specific, same bug with every preg function.
Previous Comments:
[2009-08-08 21:04:32] paj...@php.net
Not windows specific
[2009-08-08 20:08:15] inf3rno dot hu at gmail dot com
Description:
For pattern: .* there is an empty match at the end of the string.
Reproduce code:
---
$p1='/.*/';
$p2='/.*$/';
$p3='/^.*/';
$p4='/^.*$/';
$test='some text';
function test($p,$t)
{
preg_match_all($p,$t,$m,PREG_SET_ORDER);
echo $p.'';
if (count($m)==1)
echo 'ok';
else
echo 'bug';
echo ''.var_export($m,true).'';
echo '';
}
test($p1,$test);
test($p2,$test);
test($p3,$test);
test($p4,$test);
Expected result:
I'm expecting one match in the preg_match_all result array, and I will
get two instead of one. The second match is empty.
Actual result:
--
/.*/
bug
array (
0 =>
array (
0 => 'some text',
),
1 =>
array (
0 => '',
),
)
/.*$/
bug
array (
0 =>
array (
0 => 'some text',
),
1 =>
array (
0 => '',
),
)
/^.*/
ok
array (
0 =>
array (
0 => 'some text',
),
)
/^.*$/
ok
array (
0 =>
array (
0 => 'some text',
),
)
--
Edit this bug report at http://bugs.php.net/?id=49198&edit=1
#49198 [Opn]: Incorrect result for .*
ID: 49198
Updated by: ras...@php.net
Reported By: inf3rno dot hu at gmail dot com
Status: Open
Bug Type: PCRE related
Operating System: *
PHP Version: 5.2.10
New Comment:
If you change:
preg_match_all($p,$t,$m,PREG_SET_ORDER);
to:
preg_match($p,$t,$m);
There is no empty match. I get this output:
/.*/okarray (
0 => 'some text',
)/.*$/okarray (
0 => 'some text',
)/^.*/okarray (
0 => 'some text',
)/^.*$/okarray (
0 => 'some text',
)
If you can get this effect with preg_match(), please show how.
Previous Comments:
[2009-08-09 10:49:19] inf3rno dot hu at gmail dot com
It's not preg_match_all specific, same bug with every preg function.
[2009-08-08 21:04:32] paj...@php.net
Not windows specific
[2009-08-08 20:08:15] inf3rno dot hu at gmail dot com
Description:
For pattern: .* there is an empty match at the end of the string.
Reproduce code:
---
$p1='/.*/';
$p2='/.*$/';
$p3='/^.*/';
$p4='/^.*$/';
$test='some text';
function test($p,$t)
{
preg_match_all($p,$t,$m,PREG_SET_ORDER);
echo $p.'';
if (count($m)==1)
echo 'ok';
else
echo 'bug';
echo ''.var_export($m,true).'';
echo '';
}
test($p1,$test);
test($p2,$test);
test($p3,$test);
test($p4,$test);
Expected result:
I'm expecting one match in the preg_match_all result array, and I will
get two instead of one. The second match is empty.
Actual result:
--
/.*/
bug
array (
0 =>
array (
0 => 'some text',
),
1 =>
array (
0 => '',
),
)
/.*$/
bug
array (
0 =>
array (
0 => 'some text',
),
1 =>
array (
0 => '',
),
)
/^.*/
ok
array (
0 =>
array (
0 => 'some text',
),
)
/^.*$/
ok
array (
0 =>
array (
0 => 'some text',
),
)
--
Edit this bug report at http://bugs.php.net/?id=49198&edit=1
#49198 [Opn->Bgs]: Incorrect result for .*
ID: 49198
Updated by: ras...@php.net
Reported By: inf3rno dot hu at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: *
PHP Version: 5.2.10
New Comment:
I am also pretty sure that this isn't actually a bug. Doing a
match_all on a non-anchored pattern containing .* is going to match an
empty string. Remember that * means 0 or more instances of the previous
term. So, you are doing a match_all for 0 or more characters, and when
you do this non-anchored you are going to get an empty string matching
that. Change it to .+ (+ means 1 or more) and your patterns start to
make sense and as you will see, the output is what you expect.
Previous Comments:
[2009-08-09 11:11:23] ras...@php.net
If you change:
preg_match_all($p,$t,$m,PREG_SET_ORDER);
to:
preg_match($p,$t,$m);
There is no empty match. I get this output:
/.*/okarray (
0 => 'some text',
)/.*$/okarray (
0 => 'some text',
)/^.*/okarray (
0 => 'some text',
)/^.*$/okarray (
0 => 'some text',
)
If you can get this effect with preg_match(), please show how.
[2009-08-09 10:49:19] inf3rno dot hu at gmail dot com
It's not preg_match_all specific, same bug with every preg function.
[2009-08-08 21:04:32] paj...@php.net
Not windows specific
[2009-08-08 20:08:15] inf3rno dot hu at gmail dot com
Description:
For pattern: .* there is an empty match at the end of the string.
Reproduce code:
---
$p1='/.*/';
$p2='/.*$/';
$p3='/^.*/';
$p4='/^.*$/';
$test='some text';
function test($p,$t)
{
preg_match_all($p,$t,$m,PREG_SET_ORDER);
echo $p.'';
if (count($m)==1)
echo 'ok';
else
echo 'bug';
echo ''.var_export($m,true).'';
echo '';
}
test($p1,$test);
test($p2,$test);
test($p3,$test);
test($p4,$test);
Expected result:
I'm expecting one match in the preg_match_all result array, and I will
get two instead of one. The second match is empty.
Actual result:
--
/.*/
bug
array (
0 =>
array (
0 => 'some text',
),
1 =>
array (
0 => '',
),
)
/.*$/
bug
array (
0 =>
array (
0 => 'some text',
),
1 =>
array (
0 => '',
),
)
/^.*/
ok
array (
0 =>
array (
0 => 'some text',
),
)
/^.*$/
ok
array (
0 =>
array (
0 => 'some text',
),
)
--
Edit this bug report at http://bugs.php.net/?id=49198&edit=1
#49197 [Opn->Bgs]: FILTER_VALIDATE_URL does not validate urls
ID: 49197 Updated by: il...@php.net Reported By: matt dot farina at gmail dot com -Status: Open +Status: Bogus Bug Type:Filter related PHP Version: 5.2.10 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . Previous Comments: [2009-08-08 14:32:15] matt dot farina at gmail dot com Description: FILTER_VALIDATE_URL doesn't actually validate a url. It passes the url through parse_url (which according to the documentation is not meant to validate a url). When tested against a test set this can be seen. Instead of this method PHP should use a regex or some other method to actually validate it. See http://api.drupal.org/api/function/valid_url/6 for an example that is to RFC 3986. I would hope for PHP 6 we can have it look for a valid IRL (with international characters) as well. -- Edit this bug report at http://bugs.php.net/?id=49197&edit=1
#49201 [NEW]: Add info about XSLT support into the get_browser() output
From: dm9 at mylinks dot ru Operating system: PHP version: 5.3.0 PHP Bug Type: Feature/Change Request Bug description: Add info about XSLT support into the get_browser() output Description: Probably it is a good idea to add info about XSLT support into the get_browser() function. Reproduce code: --- --- >From manual page: function.get-browser --- -- Edit bug report at http://bugs.php.net/?id=49201&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49201&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49201&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49201&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49201&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49201&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49201&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49201&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49201&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49201&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49201&r=support Expected behavior: http://bugs.php.net/fix.php?id=49201&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49201&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49201&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49201&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49201&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49201&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49201&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49201&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49201&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49201&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49201&r=mysqlcfg
#49193 [Opn->Csd]: gd_compat > gdJpegGetVersionString should return const char* not int
ID: 49193
Updated by: il...@php.net
Reported By: th at drillich dot com
-Status: Open
+Status: Closed
Bug Type: GD related
Operating System: All 64Bit systems
PHP Version: 5.3.0
New Comment:
This bug has been fixed in SVN.
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:
[2009-08-09 13:16:21] s...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=286949
Log: MFB: Fixed bug #49193 (gdJpegGetVersionString() inside gd_compact
identifies wrong type in declaration)
[2009-08-09 13:15:46] s...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=286948
Log: Fixed bug #49193 (gdJpegGetVersionString() inside gd_compact
identifies wrong type in declaration)
[2009-08-08 16:49:28] th at drillich dot com
Here's the patch which fixes the bug:
---
php5-5.3.0/ext/gd/libgd/gd_compat.hgdJpegGetVersionString_returnsInt
2009-08-07 19:09:40.0 +0200
+++ php5-5.3.0/ext/gd/libgd/gd_compat.h 2009-08-07 19:09:54.0
+0200
@@ -8,7 +8,7 @@
#endif
const char * gdPngGetVersionString();
-int gdJpegGetVersionString();
+const char * gdJpegGetVersionString();
int gdJpegGetVersionInt();
int overflow2(int a, int b);
---
php5-5.3.0/ext/gd/libgd/gd_compat.c.gdJpegGetVersionString_returnsInt
2009-08-07 19:09:07.0 +0200
+++ php5-5.3.0/ext/gd/libgd/gd_compat.c 2009-08-07 19:10:11.0
+0200
@@ -14,7 +14,7 @@
return JPEG_LIB_VERSION;
}
-int gdJpegGetVersionString()
+const char * gdJpegGetVersionString()
{
switch(JPEG_LIB_VERSION) {
case 62:
[2009-08-07 17:14:16] th at drillich dot com
Description:
In gd_compat.[hc]
gdJpegGetVersionString() is declared as returning int not const
char*, but sizeof(int) != sizeof(const char*) on some systems like
here sizeof(int) == 4 and sizeof(const char*) == 8.
this causes a segfault on phpinfo().
cu thomas
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f996e9c3740 (LWP 17235)]
strlen () at ../sysdeps/x86_64/strlen.S:48
48 ../sysdeps/x86_64/strlen.S: No such file or directory.
in ../sysdeps/x86_64/strlen.S
Current language: auto; currently asm
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:48
#1 0x7f9969a207c8 in format_converter (odp=0x7fff76a001f0,
fmt=0x7f9964f364d0 "s", ap=0x7fff76a00150) at
src/php5/php5-5.3.0/main/snprintf.c:964
#2 0x7f9969a213ac in strx_printv (ccp=0x7fff76a0020c,
buf=0x7f996e9c36f0 "(X\206n\231\177", len=1990197800,
format=0x7f9964f364cf "%s", ap=0x0)
at src/php5/php5-5.3.0/main/snprintf.c:1211
#3 0x7f9969a21554 in ap_php_snprintf (buf=0x7fff76a002db "",
len=1855731440, format=0x0) at
src/php5/php5-5.3.0/main/snprintf.c:1256
#4 0x7f9964f32b44 in zm_info_gd (zend_module=0x13c2bb0) at
src/php5/php5-5.3.0/ext/gd/gd.c:1296
#5 0x7f99699c06e0 in _display_module_info_func
(module=0x64f37878) at src/php5/php5-5.3.0/ext/standard/info.c:123
#6 0x7f9969a7c6d5 in zend_hash_apply (ht=0x7fff76a00520,
apply_func=0x7f99699c06d0 <_display_module_info_func>)
at src/php5/php5-5.3.0/Zend/zend_hash.c:673
#7 0x7f99699c1a5a in php_print_info (flag=32767) at
src/php5/php5-5.3.0/ext/standard/info.c:903
#8 0x7f99699c1e61 in zif_phpinfo (ht=1693677688,
return_value=0x130f858, return_value_ptr=0x7fff76a00228,
this_ptr=0x0, return_value_used=-16843009)
at src/php5/php5-5.3.0/ext/standard/info.c:1217
#9 0x7f9969ac1e5b in zend_do_fcall_common_helper_SPEC
(execute_data=0x7f996a17c580) at
src/php5/php5-5.3.0/Zend/zend_vm_execute.h:313
#10 0x7f9969a9b299 in execute (op_array=0x130eea8) at
src/php5/php5-5.3.0/Zend/zend_vm_execute.h:104
#11 0x7f9969a700c1 in zend_execute_scripts (type=0,
retval=0x7fff76a00770, file_count=3) at
src/php5/php5-5.3.0/Zend/zend.c:1188
#12 0x7f9969a1c805 in php_execute_script (primary_file=Cannot
access memory at address 0x8000769ff690
) at src/php5/php5-5.3.0/main/main.c:2196
#13 0x7f9969afa775 in php_handler (r=0x43c055) at
src/php5/php5-5.3.0/sapi/apache2handler/sapi_apache2.c:663
#14 0x0043b8d3 in ap_run_handler ()
#15 0x0043ee9f in ap_invoke_handler ()
#16 0x0044c11e in ap_process_request ()
#17 0x00449158 in ?? ()
#18 0x00442dd3 in ap_run_process_connection ()
#19 0x00450720 in ?? ()
#20 0x00450a38 in ?? ()
#21 0x00451050
#49191 [Bgs]: Unknown exception at 0x000006c5
ID: 49191 User updated by: bmhrules at hotmail dot com Reported By: bmhrules at hotmail dot com Status: Bogus Bug Type: IIS related Operating System: Windows Server 2003 Ent. X64 PHP Version: 5.2SVN-2009-08-07 (snap) New Comment: You have me very confused. I think there is a breakdown in communications somewhere. Perhaps I should just say that the C:\PHP\libmysql.dll is the one from the ZIP that you guys supply. I notice that MySQL installs their own libmysql.dll in their own directory "C:\Program Files\MySQL\MySQL Server 5.1\bin". Did you want me to copy the C:\PHP\libmysql.dll to the "C:\Program Files\MySQL\MySQL Server 5.1\bin" folder? Previous Comments: [2009-08-09 09:16:56] paj...@php.net "As was stated I am not using the libmysql.dll that MySQL supplies in my PHP directory. " You have to use libmysql.dll provided in the PHP directory. [2009-08-08 04:39:08] bmhrules at hotmail dot com As was stated I am not using the libmysql.dll that MySQL supplies in my PHP directory. I hope that this apparent misunderstanding is not the cause for this bug reports permanent closure. [2009-08-07 17:40:47] bmhrules at hotmail dot com As was stated, all files in the php directory are those that came in the ZIP. I was just making a note that there seems to be a file called libmysql.dll in the MySQL/bin folder. I believe that was placed there by the MySQL installer. I have no clue as of why there is one there or if it is even required. [2009-08-07 17:36:46] paj...@php.net Do not use mysql's libmysql with PHP but only the DLL provided in our releases. Add c:\php first in your PATH (or whatever is the path to PHP). [2009-08-07 17:33:07] bmhrules at hotmail dot com As of using the 5.2.11-dev(snap), MySQL has not been upgraded. Before the dev, I may have upgraded MySQL, but my memory fails me. All files in the PHP directory are those that came with the ZIP and nothing else. There is a libmysql.dll in the MySQL/bin folder though. I am currently running MySQL 5.1.36. 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/49191 -- Edit this bug report at http://bugs.php.net/?id=49191&edit=1
#49191 [Bgs]: Unknown exception at 0x000006c5
ID: 49191 Updated by: paj...@php.net Reported By: bmhrules at hotmail dot com Status: Bogus Bug Type: IIS related Operating System: Windows Server 2003 Ent. X64 PHP Version: 5.2SVN-2009-08-07 (snap) New Comment: No, you have to add C:\PHP\ to your system PATH. It has to be first in the list. Please ask further question in the php install mailing list or one of the numerous PHP forums. Previous Comments: [2009-08-09 13:34:30] bmhrules at hotmail dot com You have me very confused. I think there is a breakdown in communications somewhere. Perhaps I should just say that the C:\PHP\libmysql.dll is the one from the ZIP that you guys supply. I notice that MySQL installs their own libmysql.dll in their own directory "C:\Program Files\MySQL\MySQL Server 5.1\bin". Did you want me to copy the C:\PHP\libmysql.dll to the "C:\Program Files\MySQL\MySQL Server 5.1\bin" folder? [2009-08-09 09:16:56] paj...@php.net "As was stated I am not using the libmysql.dll that MySQL supplies in my PHP directory. " You have to use libmysql.dll provided in the PHP directory. [2009-08-08 04:39:08] bmhrules at hotmail dot com As was stated I am not using the libmysql.dll that MySQL supplies in my PHP directory. I hope that this apparent misunderstanding is not the cause for this bug reports permanent closure. [2009-08-07 17:40:47] bmhrules at hotmail dot com As was stated, all files in the php directory are those that came in the ZIP. I was just making a note that there seems to be a file called libmysql.dll in the MySQL/bin folder. I believe that was placed there by the MySQL installer. I have no clue as of why there is one there or if it is even required. [2009-08-07 17:36:46] paj...@php.net Do not use mysql's libmysql with PHP but only the DLL provided in our releases. Add c:\php first in your PATH (or whatever is the path to 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/49191 -- Edit this bug report at http://bugs.php.net/?id=49191&edit=1
#49199 [Opn->Fbk]: when i use microsoft ado to insert data ,there has a bug
ID: 49199
Updated by: j...@php.net
Reported By: lzt dot liang at tom dot com
-Status: Open
+Status: Feedback
Bug Type: COM related
Operating System: window xp and 2003
PHP Version: 5.2.10
New Comment:
I don't even know what language that might be. So what exactly is the
expected and what is the actual result you get?
Previous Comments:
[2009-08-09 04:05:10] lzt dot liang at tom dot com
Description:
microsoft com in ado has a bug
Reproduce code:
---
open("provider=sqloledb;data source=192.168.0.2,1433;User
ID=sa;pwd=123;Initial Catalog=tmp");
$rs=new COM("ADODB.Recordset");
$sql="SELECT * FROM [dbo].[tmp]";
$rs->open($sql,$conn,1,3);
$rs->addnew;
$rs["text"]="²âÊÔ¿´¿´";
$rs->update;
?>
Expected result:
please see this pic
http://www.gdlydf.com/longyan/Image/2009080717103050286.jpg
--
Edit this bug report at http://bugs.php.net/?id=49199&edit=1
#49196 [Opn->Bgs]: PHP could not understand multi files Web Forms 2.0 request
ID: 49196 Updated by: j...@php.net Reported By: mikhail dot v dot gavrilov at gmail dot com -Status: Open +Status: Bogus Bug Type: HTTP related Operating System: * PHP Version: 5.3.0 New Comment: Check the example 3 here: http://www.php.net/upload Previous Comments: [2009-08-08 08:39:57] mikhail dot v dot gavrilov at gmail dot com Expected that array $_FILES would be filled, but instead recieve all content in $_POST array, for example: Array ( [file] => WABJYWB4BD24HFXX0Tt6AT Content-Disposition: form-data; name="file"; filename="test.php" Content-Type: application/octet-stream Content of first file WABJYWB4BD24HFXX0Tt6AT Content-Disposition: form-data; name="file"; filename="SP092171.XML" Content-Type: text/xml Content of second file WABJYWB4BD24HFXX0Tt6AT-- [submit] => Upload ) [2009-08-08 07:53:02] mikhail dot v dot gavrilov at gmail dot com Description: Opera browser a support Web Forms 2.0, it allows easy build uploading multiple files form. Below given a fragment of html code demonstrates it. (In file open dialog you can select few files) Now the problem is that PHP does not understand http request from a browser with multiple file's selected. ($_FILES array is empty). Reproduce code: --- Upload to server a few files through Opera, by described above method. -- Edit this bug report at http://bugs.php.net/?id=49196&edit=1
#49196 [Bgs]: PHP could not understand multi files Web Forms 2.0 request
ID: 49196 Updated by: j...@php.net Reported By: mikhail dot v dot gavrilov at gmail dot com Status: Bogus Bug Type: HTTP related Operating System: * PHP Version: 5.3.0 New Comment: Wrong url, here's the complete page: http://www.php.net/manual/en/features.file-upload.multiple.php Previous Comments: [2009-08-09 14:51:22] j...@php.net Check the example 3 here: http://www.php.net/upload [2009-08-08 08:39:57] mikhail dot v dot gavrilov at gmail dot com Expected that array $_FILES would be filled, but instead recieve all content in $_POST array, for example: Array ( [file] => WABJYWB4BD24HFXX0Tt6AT Content-Disposition: form-data; name="file"; filename="test.php" Content-Type: application/octet-stream Content of first file WABJYWB4BD24HFXX0Tt6AT Content-Disposition: form-data; name="file"; filename="SP092171.XML" Content-Type: text/xml Content of second file WABJYWB4BD24HFXX0Tt6AT-- [submit] => Upload ) [2009-08-08 07:53:02] mikhail dot v dot gavrilov at gmail dot com Description: Opera browser a support Web Forms 2.0, it allows easy build uploading multiple files form. Below given a fragment of html code demonstrates it. (In file open dialog you can select few files) Now the problem is that PHP does not understand http request from a browser with multiple file's selected. ($_FILES array is empty). Reproduce code: --- Upload to server a few files through Opera, by described above method. -- Edit this bug report at http://bugs.php.net/?id=49196&edit=1
#49195 [Opn->Fbk]: cannot call mysql functions although mysql ext. installed
ID: 49195 Updated by: j...@php.net Reported By: sean dot everlast at gmail dot com -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: Fedora Core 9 2.6.25-14.fc9.i686 PHP Version: 5.2SVN-2009-08-08 (snap) 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: [2009-08-08 05:01:23] sean dot everlast at gmail dot com Description: Fatal error: Call to undefined function mysql_connect() in. mysql extension is installed properly. yes, I'm positively 100% sure it is. Reproduce code: --- http://bugs.php.net/?id=49195&edit=1
#48821 [Opn->Bgs]: mysql_fetch_array segfaults on second parameter
ID: 48821
Updated by: j...@php.net
Reported By: margus at zone dot ee
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: CentOS 4.7/x86_64
PHP Version: 5.3.0
New Comment:
GCC bugs are not PHP bugs.
Previous Comments:
[2009-07-22 15:30:11] erki at zone dot ee
Hello.
Actually, Margus was saying that CLI does not crash, that's why he
disabled CLI.
I tested this case a little further and discovered, that CLI also
crashes and this bug appears on x86_64 systems using GCC 3 and with GCC
optimization enabled.
Using GCC 4 or disabling GCC optimization fixes this bug.
These are my results on Debian (squeeze):
Configure lines:
---
CC=gcc-3.4 ./configure --disable-all --with-mysql [DOES
NOT WORK]
CC=gcc-3.4 CFLAGS=-O1 ./configure --disable-all --with-mysql[DOES
NOT WORK]
CC=gcc-3.4 CFLAGS=-O0 ./configure --disable-all --with-mysql
[WORKS]
CC=gcc-4.0 ./configure --disable-all --with-mysql
[WORKS]
Reproduce code:
---
sapi/cli/php -r "mysql_fetch_array (fopen ('php://stdin', 'r'),
MYSQL_BOTH);"
(I'm using fopen, because the first parameter must be some kind of
resource, but the actual value makes no difference)
Expected result:
Warning: mysql_fetch_array(): supplied resource is not a valid MySQL
result resource in Command line code on line 1
Actual result:
--
Segmentation fault
[2009-07-21 22:08:52] j...@php.net
Neither of the provided configure lines produce CLI binary, so how can
it crash?
[2009-07-16 08:18:24] margus at zone dot ee
Configure line for SAPI:
'./configure' '--prefix=/opt/zone'
'--with-config-file-path=/etc/opt/zone/php53-module'
'--with-apxs2=/opt/zone/sbin/apxs'
'--with-mysql=/opt/zone/x86_64/configure-for-mysql51'
'--with-pdo-mysql=/opt/zone/x86_64/configure-for-mysql51'
'--with-pdo-sqlite' '--disable-cli' '--with-openssl=/usr/x86_64'
'--enable-mbstring' '--with-curl=/usr/x86_64' '--with-gd'
'--enable-exif' '--with-zlib-dir=/usr/x86_64'
'--with-png-dir=/usr/x86_64' '--with-jpeg-dir=/usr/x86_64'
'--with-freetype-dir=/usr/x86_64' '--disable-sockets'
'--with-iconv=/opt/zone/x86_64' '--without-pear'
'--with-libxml-dir=/opt/zone/x86_64' '--disable-phar'
[2009-07-06 18:41:25] margus at zone dot ee
Configure line is quite traditional:
'./configure' '--prefix=/opt/zone'
'--with-config-file-path=/etc/opt/zone/php53-module'
'--with-apxs2=/opt/zone/sbin/apxs'
'--with-mysql=/opt/zone/x86_64/configure-for-mysql51'
'--with-pdo-mysql=/opt/zone/x86_64/configure-for-mysql51'
'--with-pdo-sqlite' '--disable-cli' '--with-openssl=/usr/x86_64'
'--enable-mbstring' '--with-curl=/usr/x86_64' '--with-gd'
'--enable-exif' '--with-zlib-dir=/usr/x86_64'
'--with-png-dir=/usr/x86_64' '--with-jpeg-dir=/usr/x86_64'
'--with-freetype-dir=/usr/x86_64' '--disable-sockets'
'--with-iconv=/opt/zone/x86_64' '--without-pear'
'--with-libxml-dir=/opt/zone/x86_64' '--disable-phar'
[2009-07-06 17:19:00] j...@php.net
What was the full configure line used to compile 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/48821
--
Edit this bug report at http://bugs.php.net/?id=48821&edit=1
#48778 [Com]: Files on NTFS Mounted Volumes (Junctions) inaccessible
ID: 48778
Comment by: tswsl1989 at sucs dot org
Reported By: cs at koch-aplsystems dot de
Status: Assigned
Bug Type: *General Issues
Operating System: win32 only - XP SP3
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Problem also occurs when trying to access a junction contained within
the DocumentRoot of Apache.
Apache/2.2.11 (Win32) PHP/5.3.0
NTFS 3.1 on both drives.
Error occurs accessing \igal, where \igal is a
junction to O:\
Previous Comments:
[2009-07-20 20:33:57] phpstuff at cresstone dot com
Reproduced, some things seem ok on previous versions.
Where the NTFS folder 'c:\mnt\drive1' is a mounted drive...
Using 5.3, is_dir('c:\mnt\drive1') returns false, and other filesystem
functions like scandir fail. However, using the 5.2.10 zip package,
is_dir returns true and scandir correctory enumerates the directory.
[2009-07-09 20:38:23] Steve at b-en-e dot com
Confirmed here. 5.2.8 does not have this problem, but 5.2.10 does, so
it was introduced in the previous versions.
Removing the junction from the picture solves the problem.
Note that it is not only the source files: if the error log is directed
to a junctioned folder apache ends the request with a connection reset
by peer.
[2009-07-02 15:18:33] cs at koch-aplsystems dot de
Description:
Apache 2.2 DocumentRoot is on a NTFS drive with a Mounted Volume (NTFS
Junction) Partition. All files the seem inaccessible to PHP 5.3.x (5.2.x
version do not show this problem)
Changing Apache DocumentRoot to a "real" directory on c: works around
the problem.
Reproduce code:
---
not needed
Expected result:
php script loading
Actual result:
--
Fatal error: Unknown: Failed opening required
'C:/Web/apache-root/my_file.php' (include_path='.') in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=48778&edit=1
#49197 [Bgs]: FILTER_VALIDATE_URL does not validate urls
ID: 49197 User updated by: matt dot farina at gmail dot com Reported By: matt dot farina at gmail dot com Status: Bogus Bug Type:Filter related PHP Version: 5.2.10 New Comment: The documentation at http://www.php.net/manual/en/filter.filters.validate.php states that it "Validates value as URL, optionally with required components." It does not validate it to be a url. I setup a simple test and it validated invalid urls. I may not have reported it properly through your process and it may not be the best solution but this is a bug. Either a documentation bug or a functionality bug. This is not proper validation! Previous Comments: [2009-08-09 12:56:51] il...@php.net 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 . [2009-08-08 14:32:15] matt dot farina at gmail dot com Description: FILTER_VALIDATE_URL doesn't actually validate a url. It passes the url through parse_url (which according to the documentation is not meant to validate a url). When tested against a test set this can be seen. Instead of this method PHP should use a regex or some other method to actually validate it. See http://api.drupal.org/api/function/valid_url/6 for an example that is to RFC 3986. I would hope for PHP 6 we can have it look for a valid IRL (with international characters) as well. -- Edit this bug report at http://bugs.php.net/?id=49197&edit=1
#49191 [Bgs]: Unknown exception at 0x000006c5
ID: 49191 User updated by: bmhrules at hotmail dot com Reported By: bmhrules at hotmail dot com Status: Bogus Bug Type: IIS related Operating System: Windows Server 2003 Ent. X64 PHP Version: 5.2SVN-2009-08-07 (snap) New Comment: The path is fine. PHP is installed correctly. Previous Comments: [2009-08-09 13:47:15] paj...@php.net No, you have to add C:\PHP\ to your system PATH. It has to be first in the list. Please ask further question in the php install mailing list or one of the numerous PHP forums. [2009-08-09 13:34:30] bmhrules at hotmail dot com You have me very confused. I think there is a breakdown in communications somewhere. Perhaps I should just say that the C:\PHP\libmysql.dll is the one from the ZIP that you guys supply. I notice that MySQL installs their own libmysql.dll in their own directory "C:\Program Files\MySQL\MySQL Server 5.1\bin". Did you want me to copy the C:\PHP\libmysql.dll to the "C:\Program Files\MySQL\MySQL Server 5.1\bin" folder? [2009-08-09 09:16:56] paj...@php.net "As was stated I am not using the libmysql.dll that MySQL supplies in my PHP directory. " You have to use libmysql.dll provided in the PHP directory. [2009-08-08 04:39:08] bmhrules at hotmail dot com As was stated I am not using the libmysql.dll that MySQL supplies in my PHP directory. I hope that this apparent misunderstanding is not the cause for this bug reports permanent closure. [2009-08-07 17:40:47] bmhrules at hotmail dot com As was stated, all files in the php directory are those that came in the ZIP. I was just making a note that there seems to be a file called libmysql.dll in the MySQL/bin folder. I believe that was placed there by the MySQL installer. I have no clue as of why there is one there or if it is even required. 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/49191 -- Edit this bug report at http://bugs.php.net/?id=49191&edit=1
#49196 [Bgs]: PHP could not understand multi files Web Forms 2.0 request
ID: 49196 User updated by: mikhail dot v dot gavrilov at gmail dot com Reported By: mikhail dot v dot gavrilov at gmail dot com Status: Bogus Bug Type: HTTP related Operating System: * PHP Version: 5.3.0 New Comment: Thanks for quick responce, but my example another. My code above on latest Opera browser allows select many files in one field! Please try example: 1) Create on your server index.html with next code: 2) Create in same directory upload.php 3) Dowload latest Opera 10 4) enter url index.html on your server. 5) Press "Add files" and select few files (not one!!!) 6) Press "Upload" and see php script result. Thanks for testing. -- Best Regards, Mike Gavrilov. Previous Comments: [2009-08-09 14:52:02] j...@php.net Wrong url, here's the complete page: http://www.php.net/manual/en/features.file-upload.multiple.php [2009-08-09 14:51:22] j...@php.net Check the example 3 here: http://www.php.net/upload [2009-08-08 08:39:57] mikhail dot v dot gavrilov at gmail dot com Expected that array $_FILES would be filled, but instead recieve all content in $_POST array, for example: Array ( [file] => WABJYWB4BD24HFXX0Tt6AT Content-Disposition: form-data; name="file"; filename="test.php" Content-Type: application/octet-stream Content of first file WABJYWB4BD24HFXX0Tt6AT Content-Disposition: form-data; name="file"; filename="SP092171.XML" Content-Type: text/xml Content of second file WABJYWB4BD24HFXX0Tt6AT-- [submit] => Upload ) [2009-08-08 07:53:02] mikhail dot v dot gavrilov at gmail dot com Description: Opera browser a support Web Forms 2.0, it allows easy build uploading multiple files form. Below given a fragment of html code demonstrates it. (In file open dialog you can select few files) Now the problem is that PHP does not understand http request from a browser with multiple file's selected. ($_FILES array is empty). Reproduce code: --- Upload to server a few files through Opera, by described above method. -- Edit this bug report at http://bugs.php.net/?id=49196&edit=1
#49203 [NEW]: call_user_func_array when calling a parent constructor not from a user class
From: magical...@php.net
Operating system: Linux x86_64
PHP version: 5.3.0
PHP Bug Type: Scripting Engine problem
Bug description: call_user_func_array when calling a parent constructor not
from a user class
Description:
When using:
call_user_func_array(array('parent', '__construct'), $var);
This works if the parent is a user-defined class, but not if it's an
extension-provided class (the extended constructor gets called twice).
This is not easy to explain, see attached reproduce code for more
details.
My initial code was (in a class extending mysqli):
private function __construct($params) {
call_user_func_array(array('parent', '__construct'),
$params);
$this->set_charset('utf8');
}
Using this instead awfully fixes the problem:
parent::__construct($params[0], $params[1], $params[2], $params[3]);
Note that this wasn't possible in PHP 5.2.x
Warning: call_user_func_array(): First argument is expected to be a valid
callback, 'parent::__construct' was given in foo.php on line 5
Reproduce code:
---
http://bugs.php.net/?id=49203&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49203&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49203&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49203&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49203&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49203&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49203&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49203&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49203&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49203&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49203&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49203&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49203&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49203&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49203&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49203&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49203&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49203&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49203&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49203&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49203&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49203&r=mysqlcfg
#46360 [Tbd->Csd]: [PATCH] TCP_NODELAY constant for socket_{get,set}_option
ID: 46360
User updated by: bugs at trick dot vanstaveren dot us
Reported By: bugs at trick dot vanstaveren dot us
-Status: To be documented
+Status: Closed
Bug Type: Sockets related
Operating System: *
PHP Version: 5.2.6
New Comment:
Was documented in r277584; thanks didou.
Previous Comments:
[2008-10-28 21:06:00] bugs at trick dot vanstaveren dot us
Thanks for accepting this so quickly :) Fortunate timing on my part
that this will make it into 5.2.7
I wouldn't mind doing the documentation bit as I've been wanting to
learn how the PHP documentation is built and thus how I can supply
patches. I've been writing PHP day in and day out for the last two
years, so I live on the PHP manual.
I'm going to give the Documentation HOWTO a read in the near future; if
anyone has any pointers beyond that, feel free to throw them my way.
[2008-10-23 21:31:05] fel...@php.net
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.
http://news.php.net/php.cvs/53681
[2008-10-22 19:00:01] lbarn...@php.net
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.
[2008-10-22 11:14:26] fel...@php.net
It exists on Windows, according to
http://msdn.microsoft.com/en-us/library/ms740476(VS.85).aspx
[2008-10-22 04:44:11] bugs at trick dot vanstaveren dot us
Description:
C-level TCP function setsockopt allows users of TCP sockets to set the
TCP_NODELAY flag. This flag disable's the typically default use of
Nagle's Algorithm[1] on a TCP socket.
1: http://en.wikipedia.org/wiki/Nagle%27s_algorithm
Nagle's Algorithm is bad for protocols like the extremely brief one
spoken by PHP/Java Bridge. This patch is inspired by my use of PJB on
FreeBSD which does not automatically set TCP_NODELAY on localhost
connections.
PHP does not expose this constant, although it is valid for the sockets
library as socket_set_option is a straightforward wrapper around
setsockopt.
Here is a trivial patch against PHP 5.2.5 to add the PHP constant
TCP_NODELAY. I have tested this on FreeBSD 7.0 + PHP 5.2.5. Patch is
quite simple so should apply fine against 5.3 / 6 with just a line
offset. Constant is the same on Linux so will work fine there; am not
sure about win32. Happy to test other versions and platforms if
necessary.
--- ext/sockets/sockets.c.orig 2008-10-21 22:53:07.0 +
+++ ext/sockets/sockets.c 2008-10-21 22:53:00.0 +
@@ -509,6 +509,7 @@
REGISTER_LONG_CONSTANT("SO_ERROR", SO_ERROR,
CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("SOL_SOCKET",SOL_SOCKET,
CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("SOMAXCONN", SOMAXCONN,
CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("TCP_NODELAY", TCP_NODELAY,CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("PHP_NORMAL_READ", PHP_NORMAL_READ, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("PHP_BINARY_READ", PHP_BINARY_READ, CONST_CS |
CONST_PERSISTENT);
Cheers,
Patrick van Staveren
--
Edit this bug report at http://bugs.php.net/?id=46360&edit=1
#49204 [NEW]: Late Static Binding class name problem
From: magical...@php.net Operating system: Linux x86_64 PHP version: 5.3.0 PHP Bug Type: Scripting Engine problem Bug description: Late Static Binding class name problem Description: In some cases the class name as returned by get_called_class() is incorrect. Can't explain this clearly without more sleep, but the following reproduction code should help understanding the problem. I tried to simplify the code, but the bug disappears in this case. Expected behaviour is to have class C constructed, then class B constructed, with a nice "Here is B\n" displayed. In reality the B::getInstance() static call done from C::__construct doesn't change the classname for LSB, meaning that when Singleton::getInstance() will call get_called_class() it will receive "C" (and letting us enter into an infinite recursion). Reproduce code: --- http://bugs.php.net/?id=49204&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49204&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49204&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49204&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49204&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49204&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49204&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49204&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49204&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49204&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49204&r=support Expected behavior: http://bugs.php.net/fix.php?id=49204&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49204&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49204&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49204&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49204&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49204&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49204&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49204&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49204&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49204&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49204&r=mysqlcfg
#49204 [Opn]: Late Static Binding class name problem
ID: 49204 Updated by: magical...@php.net Reported By: magical...@php.net Status: Open Bug Type: Scripting Engine problem Operating System: Linux x86_64 PHP Version: 5.3.0 New Comment: I tried duplicating the base "Singleton" class into "Singleton2", and make C extend Singleton2, and the problem still happens. Fatal error: Call to protected C::__construct() from context 'Singleton' in /home/magicaltux/foo.php on line 9 The right context is called (class "Singleton") but get_called_class() still returns "C" instead of "B". Previous Comments: [2009-08-10 06:14:07] magical...@php.net Description: In some cases the class name as returned by get_called_class() is incorrect. Can't explain this clearly without more sleep, but the following reproduction code should help understanding the problem. I tried to simplify the code, but the bug disappears in this case. Expected behaviour is to have class C constructed, then class B constructed, with a nice "Here is B\n" displayed. In reality the B::getInstance() static call done from C::__construct doesn't change the classname for LSB, meaning that when Singleton::getInstance() will call get_called_class() it will receive "C" (and letting us enter into an infinite recursion). Reproduce code: --- http://bugs.php.net/?id=49204&edit=1
