#40542 [Com]: "ORA-02248: invalid option for ALTER SESSION" on OCIPLogon
ID: 40542 Comment by: jmgonet at iware dot ch Reported By: marvin at chag dot net Status: Open Bug Type: OCI8 related Operating System: Linux PHP Version: 5.2.1 New Comment: I have just the same problem, executing a PHP script as a Windows' batch. I've set the NLS_LANG environment variable to 'NLS_LANG=FRENCH_SWITZERLAND.WE8PC850'. I'm using Oracle 10 light client. I've found in this (http://dbforums.com/t927204.html) and other forums, a possible explanation: 'NLS_LANG cannot be changed by alter session, NLS_LANGUAGE and NLS_TERRITORY can.' Previous Comments: [2007-02-22 07:13:19] marvin at chag dot net Hi Tony2001, Thank you very much for the kind offer. Unfortunately our companies security policies does not allow such an approach. But I will happily investigate the problem according to your requirements and send you the debugging information & results you need to isolate the problematic lines. [2007-02-20 10:03:38] [EMAIL PROTECTED] >So I kindly ask, wether you please can tell me what else >should cause this problem, if not PHP / OCI8? Sure. I'd look in Oracle or in the client library. With such an old version it's no wonder there are problems. Though, we can try do it this way: Please install 5.1.1 and make sure it does work fine. Then I'll need an unprivileged ssh account on your machine to install 5.2.1, reproduce the problem and investigate it. I'll also need Oracle connection details. [2007-02-20 07:52:53] marvin at chag dot net open again [2007-02-19 13:37:20] marvin at chag dot net Hi Tony2001, The only change to our systems is switching between PHP <= 5.1.1 and PHP >= 5.1.2 (today it was 5.2.1). The result is: for PHP <= 5.1.1 the database connections are working fine and for PHP >= 5.1.2 they are not. So I kindly ask, wether you please can tell me what else should cause this problem, if not PHP / OCI8? Sadly upgrading this databases in this special configuration is no option. PHP documentation http://de.php.net/manual/en/ref.oci8.php states that OCI8 can be used for Oracle 7 and 8 databases, though. [2007-02-19 13:14:41] [EMAIL PROTECTED] Not PHP problem. I'd also recommend upgrading the DB, 8i is not supported by Oracle for a long time. 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/40542 -- Edit this bug report at http://bugs.php.net/?id=40542&edit=1
#40592 [Fbk->Csd]: undeclared constant causes build failure. bug not present in v5.2.0
ID: 40592 User updated by: fluor_druid at hotmail dot com Reported By: fluor_druid at hotmail dot com -Status: Feedback +Status: Closed Bug Type: Compile Failure Operating System: OpenBSD 4.0 stable PHP Version: 5.2.1 New Comment: Builds perfectly. Thanks. Previous Comments: [2007-02-22 15:50:10] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2007-02-22 15:37:22] fluor_druid at hotmail dot com Description: I'm no wiz with this, so this output is the best I can supply to give you guys a hint of what's going on when I do make after configure. it was configured with only -- prefix=somepath, the exact same way I configured and compiled version 5.2.0 on the same system just some weeks earlier - no changes has been made to my system since i built 5.2.0. I suspect this problem is due OpenBSD not being 100% POSIX compliant. --- snip --- /bin/sh /usr/opt/php-5.2.1/libtool --silent --preserve-dup- deps --mode=compile gcc -Iext/posix/ -I/usr/opt/php-5.2.1/ ext/posix/ -DPHP_ATOM_INC -I/usr/opt/php-5.2.1/include -I/ usr/opt/php-5.2.1/main -I/usr/opt/php-5.2.1 -I/usr/local/ include/libxml2 -I/usr/opt/php-5.2.1/ext/date/lib -I/usr/ local/include -I/usr/opt/php-5.2.1/TSRM -I/usr/opt/ php-5.2.1/Zend-I/usr/local/include -g -O2 -c /usr/opt/ php-5.2.1/ext/posix/posix.c -o ext/posix/posix.lo /usr/opt/php-5.2.1/ext/posix/posix.c: In function `zif_posix_getgrgid': /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: `_SC_GETGR_R_SIZE_MAX' undeclared (first use in this function) /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: (Each undeclared identifier is reported only once /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: for each function it appears in.) *** Error code 1 Expected result: That the package would compile without problems, as the earlier 5.2.0 version did with identical configuration and same OS. Actual result: -- Failure as described above. [2007-02-22 15:33:21] fluor_druid at hotmail dot com Description: I'm no wiz with this, so this output is the best I can supply to give you guys a hint of what's going on when I do make after configure. it was configured with only -- prefix=..., the exact same way I configured and compiled version 5.2.0 on the same OS just some weeks earlier - no changes has been made to my system. /bin/sh /usr/opt/php-5.2.1/libtool --silent --preserve-dup- deps --mode=compile gcc -Iext/posix/ -I/usr/opt/php-5.2.1/ ext/posix/ -DPHP_ATOM_INC -I/usr/opt/php-5.2.1/include -I/ usr/opt/php-5.2.1/main -I/usr/opt/php-5.2.1 -I/usr/local/ include/libxml2 -I/usr/opt/php-5.2.1/ext/date/lib -I/usr/ local/include -I/usr/opt/php-5.2.1/TSRM -I/usr/opt/ php-5.2.1/Zend-I/usr/local/include -g -O2 -c /usr/opt/ php-5.2.1/ext/posix/posix.c -o ext/posix/posix.lo /usr/opt/php-5.2.1/ext/posix/posix.c: In function `zif_posix_getgrgid': /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: `_SC_GETGR_R_SIZE_MAX' undeclared (first use in this function) /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: (Each undeclared identifier is reported only once /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: for each function it appears in.) *** Error code 1 Expected result: That the package would compile without problems, as the earlier 5.2.0 version did with identical configuration and same OS. Actual result: -- Failure as described above. -- Edit this bug report at http://bugs.php.net/?id=40592&edit=1
#40601 [NEW]: imagesavealpha() has opposite effect on transparent color
From: seth at pricepages dot org Operating system: Mac 10.4 PHP version: 5.2.1 PHP Bug Type: GD related Bug description: imagesavealpha() has opposite effect on transparent color Description: The function imagesavealpha() has an opposite effect on the output image if the color is marked as transparent. For example, the code below should always create a clear image. But it renders as black. The interesting thing is that if you remove the imagesavealpha , the image renders as expected (clear). Reproduce code: --- Expected result: nothing (a clear image) Actual result: -- a solid black image -- Edit bug report at http://bugs.php.net/?id=40601&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40601&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40601&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40601&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40601&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40601&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40601&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40601&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40601&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40601&r=support Expected behavior:http://bugs.php.net/fix.php?id=40601&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40601&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40601&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40601&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40601&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40601&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40601&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40601&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40601&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40601&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40601&r=mysqlcfg
#40578 [Csd]: Thread safety issue with imagettftext
ID: 40578
User updated by: scottmacvicar at ntlworld dot com
Reported By: scottmacvicar at ntlworld dot com
Status: Closed
Bug Type: GD related
Operating System: RHEL 4
PHP Version: 5.2.1
Assigned To: pajoye
New Comment:
Antony backported the initial fix to PHP_4_4, can this be
backported too please.
Previous Comments:
[2007-02-23 01:04:17] [EMAIL PROTECTED]
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.
Fixed in 5.2 and HEAD.
Thanks for the tests
[2007-02-23 00:52:41] scottmacvicar at ntlworld dot com
Been going for almost 24 hours now without any more crashes,
the patch makes sense though. Since there was another race
condition on shutdown if one thread is accessing the cache
while another is trying to delete it.
[2007-02-22 01:48:56] scottmacvicar at ntlworld dot com
Applied now to one of our production boxes, When I'm back in
the office tomorrow I'll see if I can spend a little time
working out a test case to reproduce it.
[2007-02-22 00:57:19] [EMAIL PROTECTED]
It looks like something else.
Can you try:
http://pecl.php.net/~pierre/40568.txt
[2007-02-22 00:39:14] scottmacvicar at ntlworld dot com
Has this potentially caused a regression?
I applied the patch that was checked in CVS this afternoon
and recompiled PHP.
Had another segfault in GD, here is the backtrace.
Unfortunately it wasn't a debug build.
Thread 13 (process 27300):
#0 0x009457a2 in _dl_sysinfo_int80 () from /lib/ld-
linux.so.2
No symbol table info available.
#1 0x00985c46 in kill () from /lib/tls/libc.so.6
No symbol table info available.
#2 0x0807e646 in sig_coredump (sig=11) at mpm_common.c:1170
No locals.
#3
No symbol table info available.
#4 0x009bf652 in malloc_consolidate () from /lib/tls/
libc.so.6
No symbol table info available.
#5 0x009bfd30 in _int_free () from /lib/tls/libc.so.6
No symbol table info available.
#6 0x009c033a in free () from /lib/tls/libc.so.6
---Type to continue, or q to quit---
No symbol table info available.
#7 0x003d5b8a in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#8 0x9e418dc0 in ?? ()
No symbol table info available.
#9 0x00431b2c in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#10 0xa6629868 in ?? ()
No symbol table info available.
#11 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#12 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#13 0x003d88e9 in FT_GlyphLoader_Reset () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#14 0x003d8948 in FT_GlyphLoader_Done () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#15 0x003dc1de in FT_Remove_Module () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#16 0x003dc72b in FT_Done_Library () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#17 0x003d5ee0 in FT_Done_FreeType () from /usr/lib/
libfreetype.so.6
No symbol table info available.
---Type to continue, or q to quit---
#18 0x00fa4518 in php_gd_gdFontCacheShutdown ()
at /www/src/php-5.2.1/ext/gd/libgd/gdft.c:724
No locals.
#19 0x00f8c7eb in zm_deactivate_gd (type=1,
module_number=26,
tsrm_ls=0x94aea70) at /www/src/php-5.2.1/ext/gd/gd.c:
1303
No locals.
#20 0x0113434a in module_registry_cleanup (module=0x8b5d1b0,
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_API.c:1945
No locals.
#21 0x0113986c in zend_hash_apply (ht=0x14274e0,
apply_func=0x1134328 ,
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_hash.c:673
result = 0
p = (Bucket *) 0x8b5d180
#22 0x0112fb33 in zend_deactivate_modules
(tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend.c:839
__orig_bailout = (jmp_buf *) 0x0
__bailout = {{__jmpbuf = {144334232, 144334256,
19764252, -1503487368,
-1503487568, 18021115}, __mask_was_saved = 0,
__saved_mask = {__val = {
149310844, 10232833, 4294967294, 4294967295,
149310844, 165552858, 0,
0, 165552848, 165159443, 0, 0, 149809548, 0,
11036764, 24, 56, 88, 0,
11, 11536181, 144334232, 0, 2791479928, 17752220, 3,
165552848,
135009633, 2, 0, 165552808, 165552848
---Type to continue, or q to quit---
#23 0x010f19c5 in php_request_shutdown (dummy=0x0)
at /www/src/php-5.2.1/main/main.c:1293
__orig_bailout = Variable "__orig_bailout" is not
avai
#40578 [Opn->Csd]: Thread safety issue with imagettftext
ID: 40578
Updated by: [EMAIL PROTECTED]
Reported By: scottmacvicar at ntlworld dot com
-Status: Open
+Status: Closed
Bug Type: GD related
Operating System: RHEL 4
PHP Version: 5.2.1
Assigned To: pajoye
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.
Fixed in 5.2 and HEAD.
Thanks for the tests
Previous Comments:
[2007-02-23 00:52:41] scottmacvicar at ntlworld dot com
Been going for almost 24 hours now without any more crashes,
the patch makes sense though. Since there was another race
condition on shutdown if one thread is accessing the cache
while another is trying to delete it.
[2007-02-22 01:48:56] scottmacvicar at ntlworld dot com
Applied now to one of our production boxes, When I'm back in
the office tomorrow I'll see if I can spend a little time
working out a test case to reproduce it.
[2007-02-22 00:57:19] [EMAIL PROTECTED]
It looks like something else.
Can you try:
http://pecl.php.net/~pierre/40568.txt
[2007-02-22 00:39:14] scottmacvicar at ntlworld dot com
Has this potentially caused a regression?
I applied the patch that was checked in CVS this afternoon
and recompiled PHP.
Had another segfault in GD, here is the backtrace.
Unfortunately it wasn't a debug build.
Thread 13 (process 27300):
#0 0x009457a2 in _dl_sysinfo_int80 () from /lib/ld-
linux.so.2
No symbol table info available.
#1 0x00985c46 in kill () from /lib/tls/libc.so.6
No symbol table info available.
#2 0x0807e646 in sig_coredump (sig=11) at mpm_common.c:1170
No locals.
#3
No symbol table info available.
#4 0x009bf652 in malloc_consolidate () from /lib/tls/
libc.so.6
No symbol table info available.
#5 0x009bfd30 in _int_free () from /lib/tls/libc.so.6
No symbol table info available.
#6 0x009c033a in free () from /lib/tls/libc.so.6
---Type to continue, or q to quit---
No symbol table info available.
#7 0x003d5b8a in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#8 0x9e418dc0 in ?? ()
No symbol table info available.
#9 0x00431b2c in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#10 0xa6629868 in ?? ()
No symbol table info available.
#11 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#12 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#13 0x003d88e9 in FT_GlyphLoader_Reset () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#14 0x003d8948 in FT_GlyphLoader_Done () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#15 0x003dc1de in FT_Remove_Module () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#16 0x003dc72b in FT_Done_Library () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#17 0x003d5ee0 in FT_Done_FreeType () from /usr/lib/
libfreetype.so.6
No symbol table info available.
---Type to continue, or q to quit---
#18 0x00fa4518 in php_gd_gdFontCacheShutdown ()
at /www/src/php-5.2.1/ext/gd/libgd/gdft.c:724
No locals.
#19 0x00f8c7eb in zm_deactivate_gd (type=1,
module_number=26,
tsrm_ls=0x94aea70) at /www/src/php-5.2.1/ext/gd/gd.c:
1303
No locals.
#20 0x0113434a in module_registry_cleanup (module=0x8b5d1b0,
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_API.c:1945
No locals.
#21 0x0113986c in zend_hash_apply (ht=0x14274e0,
apply_func=0x1134328 ,
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_hash.c:673
result = 0
p = (Bucket *) 0x8b5d180
#22 0x0112fb33 in zend_deactivate_modules
(tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend.c:839
__orig_bailout = (jmp_buf *) 0x0
__bailout = {{__jmpbuf = {144334232, 144334256,
19764252, -1503487368,
-1503487568, 18021115}, __mask_was_saved = 0,
__saved_mask = {__val = {
149310844, 10232833, 4294967294, 4294967295,
149310844, 165552858, 0,
0, 165552848, 165159443, 0, 0, 149809548, 0,
11036764, 24, 56, 88, 0,
11, 11536181, 144334232, 0, 2791479928, 17752220, 3,
165552848,
135009633, 2, 0, 165552808, 165552848
---Type to continue, or q to quit---
#23 0x010f19c5 in php_request_shutdown (dummy=0x0)
at /www/src/php-5.2.1/main/main.c:1293
__orig_bailout = Variable "__orig_bailout" is not
available.
I can try a debug build but the segfaults are occuring less
frequently now.
[2007-02-21 18:41:56] [EMAIL P
#40578 [Fbk->Opn]: Thread safety issue with imagettftext
ID: 40578
User updated by: scottmacvicar at ntlworld dot com
Reported By: scottmacvicar at ntlworld dot com
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: RHEL 4
PHP Version: 5.2.1
Assigned To: pajoye
New Comment:
Been going for almost 24 hours now without any more crashes,
the patch makes sense though. Since there was another race
condition on shutdown if one thread is accessing the cache
while another is trying to delete it.
Previous Comments:
[2007-02-22 01:48:56] scottmacvicar at ntlworld dot com
Applied now to one of our production boxes, When I'm back in
the office tomorrow I'll see if I can spend a little time
working out a test case to reproduce it.
[2007-02-22 00:57:19] [EMAIL PROTECTED]
It looks like something else.
Can you try:
http://pecl.php.net/~pierre/40568.txt
[2007-02-22 00:39:14] scottmacvicar at ntlworld dot com
Has this potentially caused a regression?
I applied the patch that was checked in CVS this afternoon
and recompiled PHP.
Had another segfault in GD, here is the backtrace.
Unfortunately it wasn't a debug build.
Thread 13 (process 27300):
#0 0x009457a2 in _dl_sysinfo_int80 () from /lib/ld-
linux.so.2
No symbol table info available.
#1 0x00985c46 in kill () from /lib/tls/libc.so.6
No symbol table info available.
#2 0x0807e646 in sig_coredump (sig=11) at mpm_common.c:1170
No locals.
#3
No symbol table info available.
#4 0x009bf652 in malloc_consolidate () from /lib/tls/
libc.so.6
No symbol table info available.
#5 0x009bfd30 in _int_free () from /lib/tls/libc.so.6
No symbol table info available.
#6 0x009c033a in free () from /lib/tls/libc.so.6
---Type to continue, or q to quit---
No symbol table info available.
#7 0x003d5b8a in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#8 0x9e418dc0 in ?? ()
No symbol table info available.
#9 0x00431b2c in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#10 0xa6629868 in ?? ()
No symbol table info available.
#11 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#12 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#13 0x003d88e9 in FT_GlyphLoader_Reset () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#14 0x003d8948 in FT_GlyphLoader_Done () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#15 0x003dc1de in FT_Remove_Module () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#16 0x003dc72b in FT_Done_Library () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#17 0x003d5ee0 in FT_Done_FreeType () from /usr/lib/
libfreetype.so.6
No symbol table info available.
---Type to continue, or q to quit---
#18 0x00fa4518 in php_gd_gdFontCacheShutdown ()
at /www/src/php-5.2.1/ext/gd/libgd/gdft.c:724
No locals.
#19 0x00f8c7eb in zm_deactivate_gd (type=1,
module_number=26,
tsrm_ls=0x94aea70) at /www/src/php-5.2.1/ext/gd/gd.c:
1303
No locals.
#20 0x0113434a in module_registry_cleanup (module=0x8b5d1b0,
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_API.c:1945
No locals.
#21 0x0113986c in zend_hash_apply (ht=0x14274e0,
apply_func=0x1134328 ,
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_hash.c:673
result = 0
p = (Bucket *) 0x8b5d180
#22 0x0112fb33 in zend_deactivate_modules
(tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend.c:839
__orig_bailout = (jmp_buf *) 0x0
__bailout = {{__jmpbuf = {144334232, 144334256,
19764252, -1503487368,
-1503487568, 18021115}, __mask_was_saved = 0,
__saved_mask = {__val = {
149310844, 10232833, 4294967294, 4294967295,
149310844, 165552858, 0,
0, 165552848, 165159443, 0, 0, 149809548, 0,
11036764, 24, 56, 88, 0,
11, 11536181, 144334232, 0, 2791479928, 17752220, 3,
165552848,
135009633, 2, 0, 165552808, 165552848
---Type to continue, or q to quit---
#23 0x010f19c5 in php_request_shutdown (dummy=0x0)
at /www/src/php-5.2.1/main/main.c:1293
__orig_bailout = Variable "__orig_bailout" is not
available.
I can try a debug build but the segfaults are occuring less
frequently now.
[2007-02-21 18:41:56] [EMAIL PROTECTED]
Also backported to 4_4.
[2007-02-21 18:24:27] scottmacvicar at ntlworld dot com
Any chance of having this backported to the PHP_4_4 branch? It's a
fairly minor patch to apply.
The remainder of the comments for this report are too long. To view
th
#40572 [Opn->Asn]: Alpha composite allows color to bleed through
ID: 40572
Updated by: [EMAIL PROTECTED]
Reported By: seth at pricepages dot org
-Status: Open
+Status: Assigned
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5.2.1
Assigned To: pajoye
New Comment:
Yes, it will work the same way in php as in 2.0.34.
But you can already have the same result by disabling the alpha
blending:
$img = imagecreatetruecolor(100, 100);
imagealphablending($img, false); // <<< Here
$trans = imagecolorresolvealpha($img,255,0,0, 127);
imagefill($img, 0,0, $trans);
$pTrans = imagecolorresolvealpha($img, 0,0,0, 64);
imagefilledrectangle($img, 10, 10, 50, 50, $pTrans);
imagesavealpha($img,true);
imagepng($img);
Previous Comments:
[2007-02-23 00:38:10] seth at pricepages dot org
Well, I ran the following code against the newly released C
library, and things seem to work as expected. GD 2.0.33 seg
faults for some reason, but 2.0.34 fixes that. So, the bug
will be fixed when you sync with PHP's code?
gdImagePtr img;
int trans, pTrans;
FILE *fp;
img = gdImageCreateTrueColor(100, 100);
gdImageAlphaBlending(img, 1);
trans = gdImageColorResolveAlpha(img,255,0,0, 127);
gdImageFill(img, 0,0, trans);
pTrans = gdImageColorResolveAlpha(img, 0,0,0, 64);
gdImageFilledRectangle(img, 10, 10, 50, 50, pTrans);
gdImageAlphaBlending(img, 0);
gdImageSaveAlpha(img,1);
fp = fopen("test.png", "w");
gdImagePng(img, fp);
fclose(fp);
gdImageDestroy(img);
[2007-02-21 10:03:06] [EMAIL PROTECTED]
imagefill does not care about alpha blending but when you use a tiled
color (as it is actually an image/pattern filling).
"$trans = imagecolorresolvealpha($img,255,0,0, 127);"
Will always fill the area with red and a 100% transparent alpha.
"imagealphablending($img, true);" enables the blending mode. Set it to
false will store the alpha in the image.
You set it to true, that's why you get a "red/black" rectangle instead
of a gray semi transparent area.
However I agree that the behavior is not user friendly. The GD 2.0.34
behaves differently in a more logic way when the dst pixel is either
fully transparent or opaque.
OS X Fink already have 2.0.34, you can try to compile php against it.
Or you can see the different implementation in the GD sources (function
gdAlphaBlend):
http://cvs.php.net/viewvc.cgi/gd/libgd/gd.c
I will try to sync php gdAlphaBlend as soon as possible. I have to
check that it will not break BC in one way or another (I do not think
it will, but still need to test).
Do you get what you expect using the 2.0.34's gdAlphaBlend?
[2007-02-21 05:01:04] seth at pricepages dot org
Description:
I am filling the background of an image with a transparent red
(it shouldn't have an effect on the rest of the drawing). Over
it, I'm drawing a black, semi-transparent, square.
Reproduce code:
---
$img = imagecreatetruecolor(100, 100);
imagealphablending($img, true);
$trans = imagecolorresolvealpha($img,255,0,0, 127);
imagefill($img, 0,0, $trans);
$pTrans = imagecolorresolvealpha($img, 0,0,0, 64);
imagefilledrectangle($img, 10, 10, 50, 50, $pTrans);
imagealphablending($img, false);
imagesavealpha($img,true);
header('Content-Type: image/png');
imagepng($img);
Expected result:
I would expect the resulting image to be 100% transparent,
except for a grey, 50% transparent square.
Actual result:
--
Instead, the black is mixed with the red to form a dark-red
semi-transparent square. The red color should not be there,
because it was 100% transparent.
--
Edit this bug report at http://bugs.php.net/?id=40572&edit=1
#40599 [Opn->Fbk]: "make test" results in segmentation fault
ID: 40599 Updated by: [EMAIL PROTECTED] Reported By: lyle dot pritchett at dri dot edu -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Solaris 9, 10 PHP Version: 5CVS-2007-02-22 (snap) New Comment: Try with GCC 4.1.2, it's working fine here on Solaris 9. Previous Comments: [2007-02-23 00:36:07] lyle dot pritchett at dri dot edu gcc 4.1.1, built from scratch a couple of days ago. [2007-02-23 00:34:20] [EMAIL PROTECTED] What kind of GCC did you use? [2007-02-23 00:31:33] lyle dot pritchett at dri dot edu make test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Segmentation Fault make: [test] Error 139 (ignored) trapdoor:/opt/src/php/php5.2-20070130 # gdb ./sapi/cli/php GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10"... (gdb) set args run-tests.php (gdb) run Starting program: /opt/src/php/php5.2-20070130/sapi/cli/php run-tests.php warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libdl.so.1 is .dynamic at 0094 Program received signal SIGSEGV, Segmentation fault. _zval_ptr_dtor (zval_ptr=0x3d6748) at /opt/src/php/php5.2-20070130/Zend/zend_execute_API.c:412 412 (*zval_ptr)->refcount--; (gdb) bt #0 _zval_ptr_dtor (zval_ptr=0x3d6748) at /opt/src/php/php5.2-20070130/Zend/zend_execute_API.c:412 #1 0x002892e0 in zend_do_fcall_common_helper_SPEC (execute_data=0xffbfbb4c) at zend_execute.h:155 #2 0x002791f0 in execute (op_array=0xffbff110) at zend_vm_execute.h:92 #3 0x00259780 in zend_execute_scripts (type=-2115502080, retval=Variable "retval" is not available. ) at /opt/src/php/php5.2-20070130/Zend/zend.c:1135 #4 0x00214d14 in php_execute_script (primary_file=0x81e8) at /opt/src/php/php5.2-20070130/main/main.c:1787 #5 0x002e51b0 in main (argc=-2115502080, argv=0x91d0203a) at /opt/src/php/php5.2-20070130/sapi/cli/php_cli.c:1127 (gdb) quit [2007-02-22 23:24:54] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2007-02-22 23:18:26] lyle dot pritchett at dri dot edu Description: Per advice in bug #40565, picked up latest version: php5.2-20070130. Ran configure with options --with-apxs2=/opt/apache/bin/apxs \ --with-config-file-path=/opt/apache/conf \ --localstatedir=/var/run \ --enable-force-cgi-redirect \ --enable-magic-quotes \ --with-openssl=/opt \ --with-libxml-dir=/opt \ --enable-calendar \ --with-pgsql=/opt \ --with-readline=/opt \ --disable-ipv6 \ --with-exec-dir=/opt/php/bin \ --enable-libgcc apxs, openssl, libxml, Postgres, gcc, and readline are all latest available versions. Compile finishes successfully. make test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Segmentation Fault make: [test] Error 139 (ignored) Reproduce code: --- N/A Expected result: A series of successful tests Actual result: -- immediate segmentation fault on "make test" Interestingly, "php --version" works fine -- Edit this bug report at http://bugs.php.net/?id=40599&edit=1
#40572 [Fbk->Opn]: Alpha composite allows color to bleed through
ID: 40572
User updated by: seth at pricepages dot org
Reported By: seth at pricepages dot org
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5.2.1
Assigned To: pajoye
New Comment:
Well, I ran the following code against the newly released C
library, and things seem to work as expected. GD 2.0.33 seg
faults for some reason, but 2.0.34 fixes that. So, the bug
will be fixed when you sync with PHP's code?
gdImagePtr img;
int trans, pTrans;
FILE *fp;
img = gdImageCreateTrueColor(100, 100);
gdImageAlphaBlending(img, 1);
trans = gdImageColorResolveAlpha(img,255,0,0, 127);
gdImageFill(img, 0,0, trans);
pTrans = gdImageColorResolveAlpha(img, 0,0,0, 64);
gdImageFilledRectangle(img, 10, 10, 50, 50, pTrans);
gdImageAlphaBlending(img, 0);
gdImageSaveAlpha(img,1);
fp = fopen("test.png", "w");
gdImagePng(img, fp);
fclose(fp);
gdImageDestroy(img);
Previous Comments:
[2007-02-21 10:03:06] [EMAIL PROTECTED]
imagefill does not care about alpha blending but when you use a tiled
color (as it is actually an image/pattern filling).
"$trans = imagecolorresolvealpha($img,255,0,0, 127);"
Will always fill the area with red and a 100% transparent alpha.
"imagealphablending($img, true);" enables the blending mode. Set it to
false will store the alpha in the image.
You set it to true, that's why you get a "red/black" rectangle instead
of a gray semi transparent area.
However I agree that the behavior is not user friendly. The GD 2.0.34
behaves differently in a more logic way when the dst pixel is either
fully transparent or opaque.
OS X Fink already have 2.0.34, you can try to compile php against it.
Or you can see the different implementation in the GD sources (function
gdAlphaBlend):
http://cvs.php.net/viewvc.cgi/gd/libgd/gd.c
I will try to sync php gdAlphaBlend as soon as possible. I have to
check that it will not break BC in one way or another (I do not think
it will, but still need to test).
Do you get what you expect using the 2.0.34's gdAlphaBlend?
[2007-02-21 05:01:04] seth at pricepages dot org
Description:
I am filling the background of an image with a transparent red
(it shouldn't have an effect on the rest of the drawing). Over
it, I'm drawing a black, semi-transparent, square.
Reproduce code:
---
$img = imagecreatetruecolor(100, 100);
imagealphablending($img, true);
$trans = imagecolorresolvealpha($img,255,0,0, 127);
imagefill($img, 0,0, $trans);
$pTrans = imagecolorresolvealpha($img, 0,0,0, 64);
imagefilledrectangle($img, 10, 10, 50, 50, $pTrans);
imagealphablending($img, false);
imagesavealpha($img,true);
header('Content-Type: image/png');
imagepng($img);
Expected result:
I would expect the resulting image to be 100% transparent,
except for a grey, 50% transparent square.
Actual result:
--
Instead, the black is mixed with the red to form a dark-red
semi-transparent square. The red color should not be there,
because it was 100% transparent.
--
Edit this bug report at http://bugs.php.net/?id=40572&edit=1
#40599 [Fbk->Opn]: "make test" results in segmentation fault
ID: 40599 User updated by: lyle dot pritchett at dri dot edu Reported By: lyle dot pritchett at dri dot edu -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Solaris 9, 10 PHP Version: 5CVS-2007-02-22 (snap) New Comment: gcc 4.1.1, built from scratch a couple of days ago. Previous Comments: [2007-02-23 00:34:20] [EMAIL PROTECTED] What kind of GCC did you use? [2007-02-23 00:31:33] lyle dot pritchett at dri dot edu make test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Segmentation Fault make: [test] Error 139 (ignored) trapdoor:/opt/src/php/php5.2-20070130 # gdb ./sapi/cli/php GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10"... (gdb) set args run-tests.php (gdb) run Starting program: /opt/src/php/php5.2-20070130/sapi/cli/php run-tests.php warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libdl.so.1 is .dynamic at 0094 Program received signal SIGSEGV, Segmentation fault. _zval_ptr_dtor (zval_ptr=0x3d6748) at /opt/src/php/php5.2-20070130/Zend/zend_execute_API.c:412 412 (*zval_ptr)->refcount--; (gdb) bt #0 _zval_ptr_dtor (zval_ptr=0x3d6748) at /opt/src/php/php5.2-20070130/Zend/zend_execute_API.c:412 #1 0x002892e0 in zend_do_fcall_common_helper_SPEC (execute_data=0xffbfbb4c) at zend_execute.h:155 #2 0x002791f0 in execute (op_array=0xffbff110) at zend_vm_execute.h:92 #3 0x00259780 in zend_execute_scripts (type=-2115502080, retval=Variable "retval" is not available. ) at /opt/src/php/php5.2-20070130/Zend/zend.c:1135 #4 0x00214d14 in php_execute_script (primary_file=0x81e8) at /opt/src/php/php5.2-20070130/main/main.c:1787 #5 0x002e51b0 in main (argc=-2115502080, argv=0x91d0203a) at /opt/src/php/php5.2-20070130/sapi/cli/php_cli.c:1127 (gdb) quit [2007-02-22 23:24:54] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2007-02-22 23:18:26] lyle dot pritchett at dri dot edu Description: Per advice in bug #40565, picked up latest version: php5.2-20070130. Ran configure with options --with-apxs2=/opt/apache/bin/apxs \ --with-config-file-path=/opt/apache/conf \ --localstatedir=/var/run \ --enable-force-cgi-redirect \ --enable-magic-quotes \ --with-openssl=/opt \ --with-libxml-dir=/opt \ --enable-calendar \ --with-pgsql=/opt \ --with-readline=/opt \ --disable-ipv6 \ --with-exec-dir=/opt/php/bin \ --enable-libgcc apxs, openssl, libxml, Postgres, gcc, and readline are all latest available versions. Compile finishes successfully. make test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Segmentation Fault make: [test] Error 139 (ignored) Reproduce code: --- N/A Expected result: A series of successful tests Actual result: -- immediate segmentation fault on "make test" Interestingly, "php --version" works fine -- Edit this bug report at http://bugs.php.net/?id=40599&edit=1
#40599 [Opn->Fbk]: "make test" results in segmentation fault
ID: 40599 Updated by: [EMAIL PROTECTED] Reported By: lyle dot pritchett at dri dot edu -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Solaris 9, 10 PHP Version: 5CVS-2007-02-22 (snap) New Comment: What kind of GCC did you use? Previous Comments: [2007-02-23 00:31:33] lyle dot pritchett at dri dot edu make test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Segmentation Fault make: [test] Error 139 (ignored) trapdoor:/opt/src/php/php5.2-20070130 # gdb ./sapi/cli/php GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10"... (gdb) set args run-tests.php (gdb) run Starting program: /opt/src/php/php5.2-20070130/sapi/cli/php run-tests.php warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libdl.so.1 is .dynamic at 0094 Program received signal SIGSEGV, Segmentation fault. _zval_ptr_dtor (zval_ptr=0x3d6748) at /opt/src/php/php5.2-20070130/Zend/zend_execute_API.c:412 412 (*zval_ptr)->refcount--; (gdb) bt #0 _zval_ptr_dtor (zval_ptr=0x3d6748) at /opt/src/php/php5.2-20070130/Zend/zend_execute_API.c:412 #1 0x002892e0 in zend_do_fcall_common_helper_SPEC (execute_data=0xffbfbb4c) at zend_execute.h:155 #2 0x002791f0 in execute (op_array=0xffbff110) at zend_vm_execute.h:92 #3 0x00259780 in zend_execute_scripts (type=-2115502080, retval=Variable "retval" is not available. ) at /opt/src/php/php5.2-20070130/Zend/zend.c:1135 #4 0x00214d14 in php_execute_script (primary_file=0x81e8) at /opt/src/php/php5.2-20070130/main/main.c:1787 #5 0x002e51b0 in main (argc=-2115502080, argv=0x91d0203a) at /opt/src/php/php5.2-20070130/sapi/cli/php_cli.c:1127 (gdb) quit [2007-02-22 23:24:54] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2007-02-22 23:18:26] lyle dot pritchett at dri dot edu Description: Per advice in bug #40565, picked up latest version: php5.2-20070130. Ran configure with options --with-apxs2=/opt/apache/bin/apxs \ --with-config-file-path=/opt/apache/conf \ --localstatedir=/var/run \ --enable-force-cgi-redirect \ --enable-magic-quotes \ --with-openssl=/opt \ --with-libxml-dir=/opt \ --enable-calendar \ --with-pgsql=/opt \ --with-readline=/opt \ --disable-ipv6 \ --with-exec-dir=/opt/php/bin \ --enable-libgcc apxs, openssl, libxml, Postgres, gcc, and readline are all latest available versions. Compile finishes successfully. make test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Segmentation Fault make: [test] Error 139 (ignored) Reproduce code: --- N/A Expected result: A series of successful tests Actual result: -- immediate segmentation fault on "make test" Interestingly, "php --version" works fine -- Edit this bug report at http://bugs.php.net/?id=40599&edit=1
#40599 [Fbk->Opn]: "make test" results in segmentation fault
ID: 40599 User updated by: lyle dot pritchett at dri dot edu Reported By: lyle dot pritchett at dri dot edu -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Solaris 9, 10 PHP Version: 5CVS-2007-02-22 (snap) New Comment: make test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Segmentation Fault make: [test] Error 139 (ignored) trapdoor:/opt/src/php/php5.2-20070130 # gdb ./sapi/cli/php GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10"... (gdb) set args run-tests.php (gdb) run Starting program: /opt/src/php/php5.2-20070130/sapi/cli/php run-tests.php warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libdl.so.1 is .dynamic at 0094 Program received signal SIGSEGV, Segmentation fault. _zval_ptr_dtor (zval_ptr=0x3d6748) at /opt/src/php/php5.2-20070130/Zend/zend_execute_API.c:412 412 (*zval_ptr)->refcount--; (gdb) bt #0 _zval_ptr_dtor (zval_ptr=0x3d6748) at /opt/src/php/php5.2-20070130/Zend/zend_execute_API.c:412 #1 0x002892e0 in zend_do_fcall_common_helper_SPEC (execute_data=0xffbfbb4c) at zend_execute.h:155 #2 0x002791f0 in execute (op_array=0xffbff110) at zend_vm_execute.h:92 #3 0x00259780 in zend_execute_scripts (type=-2115502080, retval=Variable "retval" is not available. ) at /opt/src/php/php5.2-20070130/Zend/zend.c:1135 #4 0x00214d14 in php_execute_script (primary_file=0x81e8) at /opt/src/php/php5.2-20070130/main/main.c:1787 #5 0x002e51b0 in main (argc=-2115502080, argv=0x91d0203a) at /opt/src/php/php5.2-20070130/sapi/cli/php_cli.c:1127 (gdb) quit Previous Comments: [2007-02-22 23:24:54] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2007-02-22 23:18:26] lyle dot pritchett at dri dot edu Description: Per advice in bug #40565, picked up latest version: php5.2-20070130. Ran configure with options --with-apxs2=/opt/apache/bin/apxs \ --with-config-file-path=/opt/apache/conf \ --localstatedir=/var/run \ --enable-force-cgi-redirect \ --enable-magic-quotes \ --with-openssl=/opt \ --with-libxml-dir=/opt \ --enable-calendar \ --with-pgsql=/opt \ --with-readline=/opt \ --disable-ipv6 \ --with-exec-dir=/opt/php/bin \ --enable-libgcc apxs, openssl, libxml, Postgres, gcc, and readline are all latest available versions. Compile finishes successfully. make test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Segmentation Fault make: [test] Error 139 (ignored) Reproduce code: --- N/A Expected result: A series of successful tests Actual result: -- immediate segmentation fault on "make test" Interestingly, "php --version" works fine -- Edit this bug report at http://bugs.php.net/?id=40599&edit=1
#40600 [Opn->Fbk]: [PATCH]:getgrgid_r, getgrnam_r etc functions regression(crash)
ID: 40600
Updated by: [EMAIL PROTECTED]
Reported By: stas at FreeBSD dot org
-Status: Open
+Status: Feedback
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
New Comment:
+ if (grbuflen < 0)
+ grbuflen = 1024;
I definitely agree with this part of the patch.
But other parts look to me as a "workaround" for FreeBSD problems.
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
It might be safe to do it on FreeBSD when you know for sure that this
functionality is missing and it's safe to use 1K buffer, but other
systems might behave differently.
Previous Comments:
[2007-02-22 23:34:54] stas at FreeBSD dot org
The patch itself:
--- posix.c.origFri Jan 12 04:46:11 2007
+++ posix.c Thu Feb 22 14:56:56 2007
@@ -837,9 +837,8 @@
#if defined(ZTS) && defined(HAVE_GETGRNAM_R) &&
defined(_SC_GETGR_R_SIZE_MAX)
buflen = sysconf(_SC_GETGR_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
buf = emalloc(buflen);
g = &gbuf;
@@ -887,6 +886,8 @@
#ifdef HAVE_GETGRGID_R
grbuflen = sysconf(_SC_GETGR_R_SIZE_MAX);
+ if (grbuflen < 0)
+ grbuflen = 1024;
grbuf = emalloc(grbuflen);
ret = getgrgid_r(gid, &_g, grbuf, grbuflen, &retgrptr);
@@ -950,9 +951,9 @@
#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWNAM_R)
buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
+
buf = emalloc(buflen);
pw = &pwbuf;
@@ -999,9 +1000,8 @@
}
#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWUID_R)
pwbuflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (pwbuflen < 1) {
- RETURN_FALSE;
- }
+ if (pwbuflen < 0)
+ pwbuflen = 1024;
pwbuf = emalloc(pwbuflen);
ret = getpwuid_r(uid, &_pw, pwbuf, pwbuflen, &retpwptr);
--
[2007-02-22 23:32:39] stas at FreeBSD dot org
Description:
This module has problems with functions like getgrgid_r etc. It tries
to find out limits using sysconf, but FreeBSD doesn't have, e.g.
_SC_GETPW_R_SIZE_MAX. Since it does't try to check the return value it
effectively leads to attempt to allocate (size_t)-1 bytes, which
obviously fails, since trying to allocate (size_t)-1 bytes exceeds any
limits.
Reproduce code:
---
$groupinfo = posix_getgrgid(0);
print_r($groupinfo);
Expected result:
something meaningful
--
Edit this bug report at http://bugs.php.net/?id=40600&edit=1
#40600 [Opn]: [PATCH]:getgrgid_r, getgrnam_r etc functions regression(crash)
ID: 40600
User updated by: stas at FreeBSD dot org
Reported By: stas at FreeBSD dot org
Status: Open
Bug Type: POSIX related
Operating System: FreeBSD
PHP Version: 5.2.1
New Comment:
The patch itself:
--- posix.c.origFri Jan 12 04:46:11 2007
+++ posix.c Thu Feb 22 14:56:56 2007
@@ -837,9 +837,8 @@
#if defined(ZTS) && defined(HAVE_GETGRNAM_R) &&
defined(_SC_GETGR_R_SIZE_MAX)
buflen = sysconf(_SC_GETGR_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
buf = emalloc(buflen);
g = &gbuf;
@@ -887,6 +886,8 @@
#ifdef HAVE_GETGRGID_R
grbuflen = sysconf(_SC_GETGR_R_SIZE_MAX);
+ if (grbuflen < 0)
+ grbuflen = 1024;
grbuf = emalloc(grbuflen);
ret = getgrgid_r(gid, &_g, grbuf, grbuflen, &retgrptr);
@@ -950,9 +951,9 @@
#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWNAM_R)
buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (buflen < 1) {
- RETURN_FALSE;
- }
+ if (buflen < 0)
+ buflen = 1024;
+
buf = emalloc(buflen);
pw = &pwbuf;
@@ -999,9 +1000,8 @@
}
#if defined(ZTS) && defined(_SC_GETPW_R_SIZE_MAX) &&
defined(HAVE_GETPWUID_R)
pwbuflen = sysconf(_SC_GETPW_R_SIZE_MAX);
- if (pwbuflen < 1) {
- RETURN_FALSE;
- }
+ if (pwbuflen < 0)
+ pwbuflen = 1024;
pwbuf = emalloc(pwbuflen);
ret = getpwuid_r(uid, &_pw, pwbuf, pwbuflen, &retpwptr);
--
Previous Comments:
[2007-02-22 23:32:39] stas at FreeBSD dot org
Description:
This module has problems with functions like getgrgid_r etc. It tries
to find out limits using sysconf, but FreeBSD doesn't have, e.g.
_SC_GETPW_R_SIZE_MAX. Since it does't try to check the return value it
effectively leads to attempt to allocate (size_t)-1 bytes, which
obviously fails, since trying to allocate (size_t)-1 bytes exceeds any
limits.
Reproduce code:
---
$groupinfo = posix_getgrgid(0);
print_r($groupinfo);
Expected result:
something meaningful
--
Edit this bug report at http://bugs.php.net/?id=40600&edit=1
#40595 [Bgs->Csd]: IMAP extension: utf8_mime2text() has wrong parameters
ID: 40595 User updated by: perske at uni-muenster dot de Reported By: perske at uni-muenster dot de -Status: Bogus +Status: Closed Bug Type: Compile Failure -Operating System: Independent +Operating System: AIX PHP Version: 5.2.1 New Comment: Sorry! My mistake! configure detected this wrong. Because my system (AIX with IBM compiler) is explicitly unsupported, this is not a bug of PHP. (When checking for utf8_mime2text signature, compiling with "cc_r -c -I/www/imap/include conftest.c" ended with exit code zero although there was an error message. This misdirectored configure that only looks at the exit code, and misdirected me, too. Please apologize.) Previous Comments: [2007-02-22 18:55:46] [EMAIL PROTECTED] >But with the current imap2006e.tar.Z, U8T_CANONICAL is >defined and utf8_mime2text() takes only two parameters. That's not true. See imap-2006e/src/c-client/utf8aux.c, line 116: long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT *dst,long flags) [2007-02-22 18:26:52] perske at uni-muenster dot de Description: Bug 37948 should be reopened: The bugfix assumes that U8T_CANONICAL is not defined when the old parameter count of utf8_mime2text() is valid. But with the current imap2006e.tar.Z, U8T_CANONICAL is defined and utf8_mime2text() takes only two parameters. Thus configure fails with "this cannot happen". Supposed correction: Simple do not check for existence of U8T_CANONICAL in configure if the old parameter count is detected. (I'm trying to compile PHP 5.2.1 with imap2006e.) (After replacing all U8T_CANONICAL with XYXYXY in configure, compilation finishes successful.) Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/?id=40595&edit=1
#40600 [NEW]: [PATCH]:getgrgid_r, getgrnam_r etc functions regression(crash)
From: stas at FreeBSD dot org Operating system: FreeBSD PHP version: 5.2.1 PHP Bug Type: POSIX related Bug description: [PATCH]:getgrgid_r, getgrnam_r etc functions regression(crash) Description: This module has problems with functions like getgrgid_r etc. It tries to find out limits using sysconf, but FreeBSD doesn't have, e.g. _SC_GETPW_R_SIZE_MAX. Since it does't try to check the return value it effectively leads to attempt to allocate (size_t)-1 bytes, which obviously fails, since trying to allocate (size_t)-1 bytes exceeds any limits. Reproduce code: --- $groupinfo = posix_getgrgid(0); print_r($groupinfo); Expected result: something meaningful -- Edit bug report at http://bugs.php.net/?id=40600&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40600&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40600&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40600&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40600&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40600&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40600&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40600&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40600&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40600&r=support Expected behavior:http://bugs.php.net/fix.php?id=40600&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40600&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40600&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40600&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40600&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40600&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40600&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40600&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40600&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40600&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40600&r=mysqlcfg
#40599 [Opn->Fbk]: "make test" results in segmentation fault
ID: 40599 Updated by: [EMAIL PROTECTED] Reported By: lyle dot pritchett at dri dot edu -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Solaris 9, 10 PHP Version: 5CVS-2007-02-22 (snap) New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2007-02-22 23:18:26] lyle dot pritchett at dri dot edu Description: Per advice in bug #40565, picked up latest version: php5.2-20070130. Ran configure with options --with-apxs2=/opt/apache/bin/apxs \ --with-config-file-path=/opt/apache/conf \ --localstatedir=/var/run \ --enable-force-cgi-redirect \ --enable-magic-quotes \ --with-openssl=/opt \ --with-libxml-dir=/opt \ --enable-calendar \ --with-pgsql=/opt \ --with-readline=/opt \ --disable-ipv6 \ --with-exec-dir=/opt/php/bin \ --enable-libgcc apxs, openssl, libxml, Postgres, gcc, and readline are all latest available versions. Compile finishes successfully. make test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Segmentation Fault make: [test] Error 139 (ignored) Reproduce code: --- N/A Expected result: A series of successful tests Actual result: -- immediate segmentation fault on "make test" Interestingly, "php --version" works fine -- Edit this bug report at http://bugs.php.net/?id=40599&edit=1
#40599 [NEW]: "make test" results in segmentation fault
From: lyle dot pritchett at dri dot edu Operating system: Solaris 9, 10 PHP version: 5CVS-2007-02-22 (snap) PHP Bug Type: Reproducible crash Bug description: "make test" results in segmentation fault Description: Per advice in bug #40565, picked up latest version: php5.2-20070130. Ran configure with options --with-apxs2=/opt/apache/bin/apxs \ --with-config-file-path=/opt/apache/conf \ --localstatedir=/var/run \ --enable-force-cgi-redirect \ --enable-magic-quotes \ --with-openssl=/opt \ --with-libxml-dir=/opt \ --enable-calendar \ --with-pgsql=/opt \ --with-readline=/opt \ --disable-ipv6 \ --with-exec-dir=/opt/php/bin \ --enable-libgcc apxs, openssl, libxml, Postgres, gcc, and readline are all latest available versions. Compile finishes successfully. make test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Segmentation Fault make: [test] Error 139 (ignored) Reproduce code: --- N/A Expected result: A series of successful tests Actual result: -- immediate segmentation fault on "make test" Interestingly, "php --version" works fine -- Edit bug report at http://bugs.php.net/?id=40599&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40599&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40599&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40599&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40599&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40599&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40599&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40599&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40599&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40599&r=support Expected behavior:http://bugs.php.net/fix.php?id=40599&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40599&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40599&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40599&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40599&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40599&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40599&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40599&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40599&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40599&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40599&r=mysqlcfg
#40596 [Bgs]: Running two PHP scripts causes Apache freeze
ID: 40596 User updated by: karldray at interchange dot ubc dot ca Reported By: karldray at interchange dot ubc dot ca Status: Bogus Bug Type: Apache2 related Operating System: Windows XP SP2 PHP Version: 5.2.1 New Comment: P.S. Thanks for the responses and sorry about the bogus bug. :) Previous Comments: [2007-02-22 23:12:01] karldray at interchange dot ubc dot ca Yeah, the limit is implemented in the browser (Firefox does it too). Here's an article on it (and how to change it): http://www.oreillynet.com/xml/blog/2006/10/what_i_didnt_know_about_xhr.html [2007-02-22 22:45:35] [EMAIL PROTECTED] Not PHP problem. [2007-02-22 22:37:51] [EMAIL PROTECTED] I Think this is an IE problem and has nothing to do with PHP or Apache. Try the same thing in Firefox and you will not see this problem. IE seams to have a limit of two connections to the same server at any time. [2007-02-22 22:36:49] karldray at interchange dot ubc dot ca Bug closed: I just noticed that while the first two scripts are running, Apache still responds fine to requests coming from other clients. There must simply be a limit of two simultaneous requests per client that Apache is enforcing. Now I just need to figure out how to change this. [2007-02-22 22:31:21] [EMAIL PROTECTED] Please make sure you have a clean system. I.e. no firewalls, no third-party applications that might affect it. It would be good if try it on another machine. Personally I do not believe an issue like this might come unnoticed, so it looks like your local problem. 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/40596 -- Edit this bug report at http://bugs.php.net/?id=40596&edit=1
#40596 [Bgs]: Running two PHP scripts causes Apache freeze
ID: 40596 User updated by: karldray at interchange dot ubc dot ca Reported By: karldray at interchange dot ubc dot ca Status: Bogus Bug Type: Apache2 related Operating System: Windows XP SP2 PHP Version: 5.2.1 New Comment: Yeah, the limit is implemented in the browser (Firefox does it too). Here's an article on it (and how to change it): http://www.oreillynet.com/xml/blog/2006/10/what_i_didnt_know_about_xhr.html Previous Comments: [2007-02-22 22:45:35] [EMAIL PROTECTED] Not PHP problem. [2007-02-22 22:37:51] [EMAIL PROTECTED] I Think this is an IE problem and has nothing to do with PHP or Apache. Try the same thing in Firefox and you will not see this problem. IE seams to have a limit of two connections to the same server at any time. [2007-02-22 22:36:49] karldray at interchange dot ubc dot ca Bug closed: I just noticed that while the first two scripts are running, Apache still responds fine to requests coming from other clients. There must simply be a limit of two simultaneous requests per client that Apache is enforcing. Now I just need to figure out how to change this. [2007-02-22 22:31:21] [EMAIL PROTECTED] Please make sure you have a clean system. I.e. no firewalls, no third-party applications that might affect it. It would be good if try it on another machine. Personally I do not believe an issue like this might come unnoticed, so it looks like your local problem. [2007-02-22 22:20:50] karldray at interchange dot ubc dot ca Description: While two PHP scripts (or two instances of the same script) are running, Apache (2.2.4) stops responding to any new requests (even for non-php pages) until one of them finishes. It doesn't seem to matter what the scripts are actually doing; the same problem occurs when they're doing any of the following: -performing calculations (e.g. counting from 1 to 1000) -blocking on socket functions -sleep() ing Reproduce code: --- wait.php: 1. Open two browser windows and point them both to wait.php so that they're running at the same time. 2. Before they finish, open a third browser window and point it to any other URI on the server (even a non-php page). Expected result: The third window should load immediately. Actual result: -- The third window does not load until one of the two PHP scripts finshes. Note: If the third request is for a PHP page containing an error_log() at the very beginning, then the logfile output is not generated as long as the first two pages are running (suggesting that Apache isn't getting around to starting PHP during this time). -- Edit this bug report at http://bugs.php.net/?id=40596&edit=1
#40598 [NEW]: libxml segfault
From: incastrix at yahoo dot it
Operating system: debian etch
PHP version: 5CVS-2007-02-22 (CVS)
PHP Bug Type: XML related
Bug description: libxml segfault
Description:
libxml segfaults when xml document was loaded with LIBXML_COMPACT flag
and try to remove a node.
libxml 2.6.27
Reproduce code:
---
$doc = DOMDocument::loadXML('', LIBXML_COMPACT);
$node = $doc->getElementByID('remove');
$node->parentNode->removeChild( $node );
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210758944 (LWP 27086)]
php_libxml_node_free_list (node=0x70706970) at
/usr/local/src/php5.2-20070130/ext/libxml/libxml.c:236
236 switch (node->type) {
(gdb) bt
#0 php_libxml_node_free_list (node=0x70706970) at
/usr/local/src/php5.2-20070130/ext/libxml/libxml.c:236
#1 0xb7a310b0 in php_libxml_node_free_list (node=)
at /usr/local/src/php5.2-20070130/ext/libxml/libxml.c:253
#2 0xb7a310f9 in php_libxml_node_free_list (node=)
at /usr/local/src/php5.2-20070130/ext/libxml/libxml.c:249
#3 0xb7a3115b in php_libxml_node_free_resource (node=0x82247c0)
at /usr/local/src/php5.2-20070130/ext/libxml/libxml.c:1005
#4 0xb7a311f8 in php_libxml_node_decrement_resource (object=0xb7799708)
at /usr/local/src/php5.2-20070130/ext/libxml/libxml.c:1028
#5 0xb7a65864 in dom_objects_free_storage (object=0xb7799708) at
/usr/local/src/php5.2-20070130/ext/dom/php_dom.c:974
#6 0xb7c298a7 in zend_objects_store_del_ref_by_handle (handle=2)
at /usr/local/src/php5.2-20070130/Zend/zend_objects_API.c:206
#7 0xb7c298e7 in zend_objects_store_del_ref (zobject=0xb7799848)
at /usr/local/src/php5.2-20070130/Zend/zend_objects_API.c:168
#8 0xb7c02199 in _zval_ptr_dtor (zval_ptr=0xb7796f60) at
/usr/local/src/php5.2-20070130/Zend/zend_variables.h:35
#9 0xb7c17667 in zend_hash_apply_deleter (ht=0xb7d53990, p=0xb7796f54)
at /usr/local/src/php5.2-20070130/Zend/zend_hash.c:611
#10 0xb7c17768 in zend_hash_reverse_apply (ht=0xb7d53990,
apply_func=0xb7c018d0 )
at /usr/local/src/php5.2-20070130/Zend/zend_hash.c:760
#11 0xb7c020fe in shutdown_destructors () at
/usr/local/src/php5.2-20070130/Zend/zend_execute_API.c:211
#12 0xb7c0e300 in zend_call_destructors () at
/usr/local/src/php5.2-20070130/Zend/zend.c:846
#13 0xb7bcfd88 in php_request_shutdown (dummy=0x0) at
/usr/local/src/php5.2-20070130/main/main.c:1279
#14 0xb7c8642d in php_handler (r=0x821d578) at
/usr/local/src/php5.2-20070130/sapi/apache2handler/sapi_apache2.c:463
#15 0x08074617 in ap_run_handler (r=0x821d578) at config.c:157
#16 0x08077707 in ap_invoke_handler (r=0x821d578) at config.c:372
#17 0x0808deb8 in ap_process_request (r=0x821d578) at http_request.c:258
#18 0x0808b15e in ap_process_http_connection (c=0x8219558) at
http_core.c:184
#19 0x0807b4d7 in ap_run_process_connection (c=0x8219558) at
connection.c:43
#20 0x080a10a4 in child_main (child_num_arg=) at
prefork.c:640
#21 0x080a1304 in make_child (s=0x80ccc80, slot=0) at prefork.c:680
#22 0x080a20ca in ap_mpm_run (_pconf=0x80c80a8, plog=0x81061a0,
s=0x80ccc80) at prefork.c:956
#23 0x0806222f in main (argc=135029024, argv=0x0) at main.c:717
--
Edit bug report at http://bugs.php.net/?id=40598&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40598&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40598&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40598&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40598&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40598&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40598&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40598&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40598&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40598&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40598&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40598&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40598&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40598&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40598&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40598&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40598&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40598&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40598&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40598&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40598&r=mysqlcfg
#40597 [Opn->Bgs]: FILTER_VALIDATE_INT limited to system's signed integer size
ID: 40597
Updated by: [EMAIL PROTECTED]
Reported By: mail957253 at lemurtastic dot com
-Status: Open
+Status: Bogus
-Bug Type: Feature/Change Request
+Bug Type: Filter related
Operating System: Windows XP SP2
PHP Version: 5.2.1
-Assigned To:
+Assigned To: pajoye
New Comment:
It returns a PHP integer which is limited to 32bits.
If you like to get a string containing a big integer, you can use the
sanitize rule.
Once PHP has 64bits integer support, it will be available in filter as
well.
Not a bug > bogus.
Previous Comments:
[2007-02-22 22:36:02] mail957253 at lemurtastic dot com
Description:
FILTER_VALIDATE_INT should validate anything that normal people
consider an integer as such, rather than being limited to what my
computer can store in 32 bits.
Reproduce code:
---
filter_var('2147483648', FILTER_VALIDATE_INT);
Expected result:
returns '2147483648'
Actual result:
--
returns FALSE
--
Edit this bug report at http://bugs.php.net/?id=40597&edit=1
#40596 [Fbk->Bgs]: Running two PHP scripts causes Apache freeze
ID: 40596 Updated by: [EMAIL PROTECTED] Reported By: karldray at interchange dot ubc dot ca -Status: Feedback +Status: Bogus Bug Type: Apache2 related Operating System: Windows XP SP2 PHP Version: 5.2.1 New Comment: Not PHP problem. Previous Comments: [2007-02-22 22:37:51] [EMAIL PROTECTED] I Think this is an IE problem and has nothing to do with PHP or Apache. Try the same thing in Firefox and you will not see this problem. IE seams to have a limit of two connections to the same server at any time. [2007-02-22 22:36:49] karldray at interchange dot ubc dot ca Bug closed: I just noticed that while the first two scripts are running, Apache still responds fine to requests coming from other clients. There must simply be a limit of two simultaneous requests per client that Apache is enforcing. Now I just need to figure out how to change this. [2007-02-22 22:31:21] [EMAIL PROTECTED] Please make sure you have a clean system. I.e. no firewalls, no third-party applications that might affect it. It would be good if try it on another machine. Personally I do not believe an issue like this might come unnoticed, so it looks like your local problem. [2007-02-22 22:20:50] karldray at interchange dot ubc dot ca Description: While two PHP scripts (or two instances of the same script) are running, Apache (2.2.4) stops responding to any new requests (even for non-php pages) until one of them finishes. It doesn't seem to matter what the scripts are actually doing; the same problem occurs when they're doing any of the following: -performing calculations (e.g. counting from 1 to 1000) -blocking on socket functions -sleep() ing Reproduce code: --- wait.php: 1. Open two browser windows and point them both to wait.php so that they're running at the same time. 2. Before they finish, open a third browser window and point it to any other URI on the server (even a non-php page). Expected result: The third window should load immediately. Actual result: -- The third window does not load until one of the two PHP scripts finshes. Note: If the third request is for a PHP page containing an error_log() at the very beginning, then the logfile output is not generated as long as the first two pages are running (suggesting that Apache isn't getting around to starting PHP during this time). -- Edit this bug report at http://bugs.php.net/?id=40596&edit=1
#40596 [Csd->Fbk]: Running two PHP scripts causes Apache freeze
ID: 40596 Updated by: [EMAIL PROTECTED] Reported By: karldray at interchange dot ubc dot ca -Status: Closed +Status: Feedback Bug Type: Apache2 related Operating System: Windows XP SP2 PHP Version: 5.2.1 New Comment: I Think this is an IE problem and has nothing to do with PHP or Apache. Try the same thing in Firefox and you will not see this problem. IE seams to have a limit of two connections to the same server at any time. Previous Comments: [2007-02-22 22:36:49] karldray at interchange dot ubc dot ca Bug closed: I just noticed that while the first two scripts are running, Apache still responds fine to requests coming from other clients. There must simply be a limit of two simultaneous requests per client that Apache is enforcing. Now I just need to figure out how to change this. [2007-02-22 22:31:21] [EMAIL PROTECTED] Please make sure you have a clean system. I.e. no firewalls, no third-party applications that might affect it. It would be good if try it on another machine. Personally I do not believe an issue like this might come unnoticed, so it looks like your local problem. [2007-02-22 22:20:50] karldray at interchange dot ubc dot ca Description: While two PHP scripts (or two instances of the same script) are running, Apache (2.2.4) stops responding to any new requests (even for non-php pages) until one of them finishes. It doesn't seem to matter what the scripts are actually doing; the same problem occurs when they're doing any of the following: -performing calculations (e.g. counting from 1 to 1000) -blocking on socket functions -sleep() ing Reproduce code: --- wait.php: 1. Open two browser windows and point them both to wait.php so that they're running at the same time. 2. Before they finish, open a third browser window and point it to any other URI on the server (even a non-php page). Expected result: The third window should load immediately. Actual result: -- The third window does not load until one of the two PHP scripts finshes. Note: If the third request is for a PHP page containing an error_log() at the very beginning, then the logfile output is not generated as long as the first two pages are running (suggesting that Apache isn't getting around to starting PHP during this time). -- Edit this bug report at http://bugs.php.net/?id=40596&edit=1
#40596 [Fbk->Csd]: Running two PHP scripts causes Apache freeze
ID: 40596 User updated by: karldray at interchange dot ubc dot ca Reported By: karldray at interchange dot ubc dot ca -Status: Feedback +Status: Closed Bug Type: Apache2 related Operating System: Windows XP SP2 PHP Version: 5.2.1 New Comment: Bug closed: I just noticed that while the first two scripts are running, Apache still responds fine to requests coming from other clients. There must simply be a limit of two simultaneous requests per client that Apache is enforcing. Now I just need to figure out how to change this. Previous Comments: [2007-02-22 22:31:21] [EMAIL PROTECTED] Please make sure you have a clean system. I.e. no firewalls, no third-party applications that might affect it. It would be good if try it on another machine. Personally I do not believe an issue like this might come unnoticed, so it looks like your local problem. [2007-02-22 22:20:50] karldray at interchange dot ubc dot ca Description: While two PHP scripts (or two instances of the same script) are running, Apache (2.2.4) stops responding to any new requests (even for non-php pages) until one of them finishes. It doesn't seem to matter what the scripts are actually doing; the same problem occurs when they're doing any of the following: -performing calculations (e.g. counting from 1 to 1000) -blocking on socket functions -sleep() ing Reproduce code: --- wait.php: 1. Open two browser windows and point them both to wait.php so that they're running at the same time. 2. Before they finish, open a third browser window and point it to any other URI on the server (even a non-php page). Expected result: The third window should load immediately. Actual result: -- The third window does not load until one of the two PHP scripts finshes. Note: If the third request is for a PHP page containing an error_log() at the very beginning, then the logfile output is not generated as long as the first two pages are running (suggesting that Apache isn't getting around to starting PHP during this time). -- Edit this bug report at http://bugs.php.net/?id=40596&edit=1
#40597 [NEW]: FILTER_VALIDATE_INT limited to system's signed integer size
From: mail957253 at lemurtastic dot com
Operating system: Windows XP SP2
PHP version: 5.2.1
PHP Bug Type: Filter related
Bug description: FILTER_VALIDATE_INT limited to system's signed integer size
Description:
FILTER_VALIDATE_INT should validate anything that normal people consider
an integer as such, rather than being limited to what my computer can
store in 32 bits.
Reproduce code:
---
filter_var('2147483648', FILTER_VALIDATE_INT);
Expected result:
returns '2147483648'
Actual result:
--
returns FALSE
--
Edit bug report at http://bugs.php.net/?id=40597&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40597&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40597&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40597&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40597&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40597&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40597&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40597&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40597&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40597&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40597&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40597&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40597&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40597&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40597&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40597&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40597&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40597&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40597&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40597&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40597&r=mysqlcfg
#40596 [Opn->Fbk]: Running two PHP scripts causes Apache freeze
ID: 40596 Updated by: [EMAIL PROTECTED] Reported By: karldray at interchange dot ubc dot ca -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows XP SP2 PHP Version: 5.2.1 New Comment: Please make sure you have a clean system. I.e. no firewalls, no third-party applications that might affect it. It would be good if try it on another machine. Personally I do not believe an issue like this might come unnoticed, so it looks like your local problem. Previous Comments: [2007-02-22 22:20:50] karldray at interchange dot ubc dot ca Description: While two PHP scripts (or two instances of the same script) are running, Apache (2.2.4) stops responding to any new requests (even for non-php pages) until one of them finishes. It doesn't seem to matter what the scripts are actually doing; the same problem occurs when they're doing any of the following: -performing calculations (e.g. counting from 1 to 1000) -blocking on socket functions -sleep() ing Reproduce code: --- wait.php: 1. Open two browser windows and point them both to wait.php so that they're running at the same time. 2. Before they finish, open a third browser window and point it to any other URI on the server (even a non-php page). Expected result: The third window should load immediately. Actual result: -- The third window does not load until one of the two PHP scripts finshes. Note: If the third request is for a PHP page containing an error_log() at the very beginning, then the logfile output is not generated as long as the first two pages are running (suggesting that Apache isn't getting around to starting PHP during this time). -- Edit this bug report at http://bugs.php.net/?id=40596&edit=1
#40596 [NEW]: Running two PHP scripts causes Apache freeze
From: karldray at interchange dot ubc dot ca Operating system: Windows XP SP2 PHP version: 5.2.1 PHP Bug Type: Apache2 related Bug description: Running two PHP scripts causes Apache freeze Description: While two PHP scripts (or two instances of the same script) are running, Apache (2.2.4) stops responding to any new requests (even for non-php pages) until one of them finishes. It doesn't seem to matter what the scripts are actually doing; the same problem occurs when they're doing any of the following: -performing calculations (e.g. counting from 1 to 1000) -blocking on socket functions -sleep() ing Reproduce code: --- wait.php: 1. Open two browser windows and point them both to wait.php so that they're running at the same time. 2. Before they finish, open a third browser window and point it to any other URI on the server (even a non-php page). Expected result: The third window should load immediately. Actual result: -- The third window does not load until one of the two PHP scripts finshes. Note: If the third request is for a PHP page containing an error_log() at the very beginning, then the logfile output is not generated as long as the first two pages are running (suggesting that Apache isn't getting around to starting PHP during this time). -- Edit bug report at http://bugs.php.net/?id=40596&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40596&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40596&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40596&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40596&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40596&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40596&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40596&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40596&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40596&r=support Expected behavior:http://bugs.php.net/fix.php?id=40596&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40596&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40596&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40596&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40596&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40596&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40596&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40596&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40596&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40596&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40596&r=mysqlcfg
#40588 [Bgs]: mysqli_connect_error() == "" on error
ID: 40588
User updated by: frankpw at fw2s dot com
Reported By: frankpw at fw2s dot com
Status: Bogus
Bug Type: MySQLi related
Operating System: Win XP Pro
PHP Version: 5.2.1
New Comment:
As promised I'm not attempting to continue, therfore I didn't change
status to open. And you don't have to answer this. It would be much
easier for me to accept a statement: "I like it the way it is so don't
bother to report this as an error.". It doesn't matter if
mysqli_connect() attempts a connection or not. This attempt is made by
a developer, programmer or whoever is using this function, and,
according to documentation, expecting to get a promised response - if
connection was made then no error, if connection wasn't made, then
error is being reported, like any other. If your arguments are valid
then why do we need error handling at all. I think we are from totally
different schools of logic. Your logic allows three values: false,
true, and something in between.
Best regards,
Frank P. Walentynowicz
Previous Comments:
[2007-02-22 20:27:40] [EMAIL PROTECTED]
That's easy - "3306" and "10" are numeric strings, but "abcd" is not.
>Isn't it logical to assume that if connection fails
That's the point. Connection doesn't fail.
The function is called with wrong parameters, so it doesn't even _try_
to connect, because we already know the parameters are wrong.
You can see the same with mysqli_connect() without any parameters.
[2007-02-22 20:19:25] frankpw at fw2s dot com
I promise to end this discussion if you tell me that passing port
number as "3306" or "10" (notice quotes) is correct. Port is declared
as int not a string. With above values "3306" will make connection
(assuming that server is set to listen on port 3306) and with "10" will
fail with proper values returned by mysqli_connect_errno and
mysqli_connect_error. Isn't it logical to assume that if connection
fails (for whatever reason) this reason should be consistently stated
in responses from mysqli_connect_errno() and mysqli_connect_error()?
[2007-02-22 19:55:18] [EMAIL PROTECTED]
>This check fails in this particular case
This check should be used when you pass correct parameters to the
function.
>Are you insisting that this is not connection error and
>that it shoud be handled differently?
Yes, I do.
You're passing wrong parameters to the function.
[2007-02-22 19:42:42] frankpw at fw2s dot com
That is not a point. Even the manual shows how connection errors should
be handled:
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
This check fails in this particular case because mysqli_connect_error()
is empty and mysqli_connect_errno is 0. Are you insisting that this is
not connection error and that it shoud be handled differently?
[2007-02-22 19:02:51] [EMAIL PROTECTED]
Remove the @, you'll see the error.
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/40588
--
Edit this bug report at http://bugs.php.net/?id=40588&edit=1
#40594 [Csd->Bgs]: Blocking socket functions cause Apache freeze
ID: 40594
Updated by: [EMAIL PROTECTED]
Reported By: karldray at interchange dot ubc dot ca
-Status: Closed
+Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.1
Previous Comments:
[2007-02-22 21:57:02] karldray at interchange dot ubc dot ca
I'm resubmitting this bug as a performance problem. (See previous
comment.)
[2007-02-22 21:53:47] karldray at interchange dot ubc dot ca
This turns out not to be specific to sockets or even to blocking
functions! I just realized that if I replace udp_recv.php with a
one-line script like
sleep(10);
or something like
for($i=0;$i<1;$i++);
then the same problem occurs: while two of them are running, apache
won't handle any new requests.
[2007-02-22 16:39:34] karldray at interchange dot ubc dot ca
Description:
I have a PHP page that opens a UDP socket and listens for data
(blocking on socket_recvfrom). When the socket recieves a packet, the
script echoes a message and finishes. This works fine, but when two
instances of this page are running (both blocking on socket_recvfrom),
Apache (2.2.4) stops responding to any new requests (even for non-php
pages) until one of them gets unblocked. The same problem occurs with
other blocking socket functions (such as socket_accept and socket_read
with TCP sockets).
Reproduction instructions:
1. open a browser window to udp_recv.php?port=1. it sits there
"loading" since PHP is waiting for socket data.
2. open another browser window to udp_recv.php?port=2.
3 (the problem). open another browser window and point it to index.html
or any other url on the server. it just sits there "loading".
4. in a command prompt, type "perl udp_send.pl 1" to send 'hello'
to the first php script's udp socket, causing it to finish. Suddenly,
the third request completes.
Reproduce code:
---
udp_recv.php:
udp_send.pl:
use strict; use Socket;
socket(SOCKET, PF_INET, SOCK_DGRAM, getprotobyname('udp')) or die
"socket: $!";
send(SOCKET, 'hello', 0, sockaddr_in(shift, inet_aton('localhost'))) or
die "send: $!";
Expected result:
I expect Apache to continue to accept and handle new web page requests
while the two PHP pages are blocking on socket functions.
Actual result:
--
Once there are two PHP pages blocking on socket functions, all
subsequent requests (even for non-php URIs) appear as "loading" in the
browser until one of the PHP scripts unblocks.
Note: If the third request is for a PHP page containing an error_log()
at the very beginning, then the logfile output is not generated as long
as the first two pages are blocking (suggesting that Apache isn't
getting around to starting PHP during this time).
--
Edit this bug report at http://bugs.php.net/?id=40594&edit=1
#40594 [Opn->Csd]: Blocking socket functions cause Apache freeze
ID: 40594
User updated by: karldray at interchange dot ubc dot ca
Reported By: karldray at interchange dot ubc dot ca
-Status: Open
+Status: Closed
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.1
New Comment:
I'm resubmitting this bug as a performance problem. (See previous
comment.)
Previous Comments:
[2007-02-22 21:53:47] karldray at interchange dot ubc dot ca
This turns out not to be specific to sockets or even to blocking
functions! I just realized that if I replace udp_recv.php with a
one-line script like
sleep(10);
or something like
for($i=0;$i<1;$i++);
then the same problem occurs: while two of them are running, apache
won't handle any new requests.
[2007-02-22 16:39:34] karldray at interchange dot ubc dot ca
Description:
I have a PHP page that opens a UDP socket and listens for data
(blocking on socket_recvfrom). When the socket recieves a packet, the
script echoes a message and finishes. This works fine, but when two
instances of this page are running (both blocking on socket_recvfrom),
Apache (2.2.4) stops responding to any new requests (even for non-php
pages) until one of them gets unblocked. The same problem occurs with
other blocking socket functions (such as socket_accept and socket_read
with TCP sockets).
Reproduction instructions:
1. open a browser window to udp_recv.php?port=1. it sits there
"loading" since PHP is waiting for socket data.
2. open another browser window to udp_recv.php?port=2.
3 (the problem). open another browser window and point it to index.html
or any other url on the server. it just sits there "loading".
4. in a command prompt, type "perl udp_send.pl 1" to send 'hello'
to the first php script's udp socket, causing it to finish. Suddenly,
the third request completes.
Reproduce code:
---
udp_recv.php:
udp_send.pl:
use strict; use Socket;
socket(SOCKET, PF_INET, SOCK_DGRAM, getprotobyname('udp')) or die
"socket: $!";
send(SOCKET, 'hello', 0, sockaddr_in(shift, inet_aton('localhost'))) or
die "send: $!";
Expected result:
I expect Apache to continue to accept and handle new web page requests
while the two PHP pages are blocking on socket functions.
Actual result:
--
Once there are two PHP pages blocking on socket functions, all
subsequent requests (even for non-php URIs) appear as "loading" in the
browser until one of the PHP scripts unblocks.
Note: If the third request is for a PHP page containing an error_log()
at the very beginning, then the logfile output is not generated as long
as the first two pages are blocking (suggesting that Apache isn't
getting around to starting PHP during this time).
--
Edit this bug report at http://bugs.php.net/?id=40594&edit=1
#40594 [Opn]: Blocking socket functions cause Apache freeze
ID: 40594
User updated by: karldray at interchange dot ubc dot ca
Reported By: karldray at interchange dot ubc dot ca
Status: Open
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.1
New Comment:
This turns out not to be specific to sockets or even to blocking
functions! I just realized that if I replace udp_recv.php with a
one-line script like
sleep(10);
or something like
for($i=0;$i<1;$i++);
then the same problem occurs: while two of them are running, apache
won't handle any new requests.
Previous Comments:
[2007-02-22 16:39:34] karldray at interchange dot ubc dot ca
Description:
I have a PHP page that opens a UDP socket and listens for data
(blocking on socket_recvfrom). When the socket recieves a packet, the
script echoes a message and finishes. This works fine, but when two
instances of this page are running (both blocking on socket_recvfrom),
Apache (2.2.4) stops responding to any new requests (even for non-php
pages) until one of them gets unblocked. The same problem occurs with
other blocking socket functions (such as socket_accept and socket_read
with TCP sockets).
Reproduction instructions:
1. open a browser window to udp_recv.php?port=1. it sits there
"loading" since PHP is waiting for socket data.
2. open another browser window to udp_recv.php?port=2.
3 (the problem). open another browser window and point it to index.html
or any other url on the server. it just sits there "loading".
4. in a command prompt, type "perl udp_send.pl 1" to send 'hello'
to the first php script's udp socket, causing it to finish. Suddenly,
the third request completes.
Reproduce code:
---
udp_recv.php:
udp_send.pl:
use strict; use Socket;
socket(SOCKET, PF_INET, SOCK_DGRAM, getprotobyname('udp')) or die
"socket: $!";
send(SOCKET, 'hello', 0, sockaddr_in(shift, inet_aton('localhost'))) or
die "send: $!";
Expected result:
I expect Apache to continue to accept and handle new web page requests
while the two PHP pages are blocking on socket functions.
Actual result:
--
Once there are two PHP pages blocking on socket functions, all
subsequent requests (even for non-php URIs) appear as "loading" in the
browser until one of the PHP scripts unblocks.
Note: If the third request is for a PHP page containing an error_log()
at the very beginning, then the logfile output is not generated as long
as the first two pages are blocking (suggesting that Apache isn't
getting around to starting PHP during this time).
--
Edit this bug report at http://bugs.php.net/?id=40594&edit=1
#40588 [Opn->Bgs]: mysqli_connect_error() == "" on error
ID: 40588
Updated by: [EMAIL PROTECTED]
Reported By: frankpw at fw2s dot com
-Status: Open
+Status: Bogus
Bug Type: MySQLi related
Operating System: Win XP Pro
PHP Version: 5.2.1
New Comment:
That's easy - "3306" and "10" are numeric strings, but "abcd" is not.
>Isn't it logical to assume that if connection fails
That's the point. Connection doesn't fail.
The function is called with wrong parameters, so it doesn't even _try_
to connect, because we already know the parameters are wrong.
You can see the same with mysqli_connect() without any parameters.
Previous Comments:
[2007-02-22 20:19:25] frankpw at fw2s dot com
I promise to end this discussion if you tell me that passing port
number as "3306" or "10" (notice quotes) is correct. Port is declared
as int not a string. With above values "3306" will make connection
(assuming that server is set to listen on port 3306) and with "10" will
fail with proper values returned by mysqli_connect_errno and
mysqli_connect_error. Isn't it logical to assume that if connection
fails (for whatever reason) this reason should be consistently stated
in responses from mysqli_connect_errno() and mysqli_connect_error()?
[2007-02-22 19:55:18] [EMAIL PROTECTED]
>This check fails in this particular case
This check should be used when you pass correct parameters to the
function.
>Are you insisting that this is not connection error and
>that it shoud be handled differently?
Yes, I do.
You're passing wrong parameters to the function.
[2007-02-22 19:42:42] frankpw at fw2s dot com
That is not a point. Even the manual shows how connection errors should
be handled:
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
This check fails in this particular case because mysqli_connect_error()
is empty and mysqli_connect_errno is 0. Are you insisting that this is
not connection error and that it shoud be handled differently?
[2007-02-22 19:02:51] [EMAIL PROTECTED]
Remove the @, you'll see the error.
[2007-02-22 18:34:44] frankpw at fw2s dot com
Additional info:
Server info: 5.0.27-community-max-nt
Client info: 5.0.22
That's as close to match server and client versions as it gets. I've
downloaded php_mysql.dll and php_mysqli.dll for server version 5.0.27
directly from MySQL. Please try the code below:
\n");
echo "Connected!\n";
echo "Host info: " . mysqli_get_host_info($mysqli) . "\n";
echo "Client info: " . mysqli_get_client_info() . "\n";
echo "Server info: " . mysqli_get_server_info($mysqli) . "\n";
echo "Protocol version: " . mysqli_get_proto_info($mysqli) . "\n";
?>
For test purposes make sure that first four parameters are correct and
use fifth as is. Repeat the test with "@" removed from the call to
mysqli_connect(). You'll see that warning is being displayed but
mysqli_connect_error() is empty and mysqli_connect_errno() == 0.
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/40588
--
Edit this bug report at http://bugs.php.net/?id=40588&edit=1
#40588 [Bgs->Opn]: mysqli_connect_error() == "" on error
ID: 40588
User updated by: frankpw at fw2s dot com
Reported By: frankpw at fw2s dot com
-Status: Bogus
+Status: Open
Bug Type: MySQLi related
Operating System: Win XP Pro
PHP Version: 5.2.1
New Comment:
I promise to end this discussion if you tell me that passing port
number as "3306" or "10" (notice quotes) is correct. Port is declared
as int not a string. With above values "3306" will make connection
(assuming that server is set to listen on port 3306) and with "10" will
fail with proper values returned by mysqli_connect_errno and
mysqli_connect_error. Isn't it logical to assume that if connection
fails (for whatever reason) this reason should be consistently stated
in responses from mysqli_connect_errno() and mysqli_connect_error()?
Previous Comments:
[2007-02-22 19:55:18] [EMAIL PROTECTED]
>This check fails in this particular case
This check should be used when you pass correct parameters to the
function.
>Are you insisting that this is not connection error and
>that it shoud be handled differently?
Yes, I do.
You're passing wrong parameters to the function.
[2007-02-22 19:42:42] frankpw at fw2s dot com
That is not a point. Even the manual shows how connection errors should
be handled:
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
This check fails in this particular case because mysqli_connect_error()
is empty and mysqli_connect_errno is 0. Are you insisting that this is
not connection error and that it shoud be handled differently?
[2007-02-22 19:02:51] [EMAIL PROTECTED]
Remove the @, you'll see the error.
[2007-02-22 18:34:44] frankpw at fw2s dot com
Additional info:
Server info: 5.0.27-community-max-nt
Client info: 5.0.22
That's as close to match server and client versions as it gets. I've
downloaded php_mysql.dll and php_mysqli.dll for server version 5.0.27
directly from MySQL. Please try the code below:
\n");
echo "Connected!\n";
echo "Host info: " . mysqli_get_host_info($mysqli) . "\n";
echo "Client info: " . mysqli_get_client_info() . "\n";
echo "Server info: " . mysqli_get_server_info($mysqli) . "\n";
echo "Protocol version: " . mysqli_get_proto_info($mysqli) . "\n";
?>
For test purposes make sure that first four parameters are correct and
use fifth as is. Repeat the test with "@" removed from the call to
mysqli_connect(). You'll see that warning is being displayed but
mysqli_connect_error() is empty and mysqli_connect_errno() == 0.
[2007-02-22 10:59:27] [EMAIL PROTECTED]
Cannot reproduce.
Make sure the client library is of the same version is the MySQL
server.
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/40588
--
Edit this bug report at http://bugs.php.net/?id=40588&edit=1
#40588 [Opn->Bgs]: mysqli_connect_error() == "" on error
ID: 40588
Updated by: [EMAIL PROTECTED]
Reported By: frankpw at fw2s dot com
-Status: Open
+Status: Bogus
Bug Type: MySQLi related
Operating System: Win XP Pro
PHP Version: 5.2.1
New Comment:
>This check fails in this particular case
This check should be used when you pass correct parameters to the
function.
>Are you insisting that this is not connection error and
>that it shoud be handled differently?
Yes, I do.
You're passing wrong parameters to the function.
Previous Comments:
[2007-02-22 19:42:42] frankpw at fw2s dot com
That is not a point. Even the manual shows how connection errors should
be handled:
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
This check fails in this particular case because mysqli_connect_error()
is empty and mysqli_connect_errno is 0. Are you insisting that this is
not connection error and that it shoud be handled differently?
[2007-02-22 19:02:51] [EMAIL PROTECTED]
Remove the @, you'll see the error.
[2007-02-22 18:34:44] frankpw at fw2s dot com
Additional info:
Server info: 5.0.27-community-max-nt
Client info: 5.0.22
That's as close to match server and client versions as it gets. I've
downloaded php_mysql.dll and php_mysqli.dll for server version 5.0.27
directly from MySQL. Please try the code below:
\n");
echo "Connected!\n";
echo "Host info: " . mysqli_get_host_info($mysqli) . "\n";
echo "Client info: " . mysqli_get_client_info() . "\n";
echo "Server info: " . mysqli_get_server_info($mysqli) . "\n";
echo "Protocol version: " . mysqli_get_proto_info($mysqli) . "\n";
?>
For test purposes make sure that first four parameters are correct and
use fifth as is. Repeat the test with "@" removed from the call to
mysqli_connect(). You'll see that warning is being displayed but
mysqli_connect_error() is empty and mysqli_connect_errno() == 0.
[2007-02-22 10:59:27] [EMAIL PROTECTED]
Cannot reproduce.
Make sure the client library is of the same version is the MySQL
server.
[2007-02-22 04:45:41] frankpw at fw2s dot com
Description:
In my class I'm opening a connection with mysqli_connect().
mysqli_connect_error() returns description of any error except one. If
one parameter is of wrong type (i.e port as string rather than
numeric).
Reproduce code:
---
public function OpenConnection($host, $user, $pass, $name = null,
$port = null, $sock = null, $chrs = null)
{
$this->mysqli = @mysqli_connect($host, $user, $pass, $name, $port,
$sock);
if (empty($this->mysqli)) die ("Execution stopped! " .
mysqli_connect_error() . "\n");
if (!empty($chrs)) $this->DefaultCharacterSet($chrs);
}
Expected result:
"Execution stopped! mysqli_connect expects parameter 5 to be long,
string given"
Actual result:
--
"Execution stopped!"
--
Edit this bug report at http://bugs.php.net/?id=40588&edit=1
#40588 [Bgs->Opn]: mysqli_connect_error() == "" on error
ID: 40588
User updated by: frankpw at fw2s dot com
Reported By: frankpw at fw2s dot com
-Status: Bogus
+Status: Open
Bug Type: MySQLi related
Operating System: Win XP Pro
PHP Version: 5.2.1
New Comment:
That is not a point. Even the manual shows how connection errors should
be handled:
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
This check fails in this particular case because mysqli_connect_error()
is empty and mysqli_connect_errno is 0. Are you insisting that this is
not connection error and that it shoud be handled differently?
Previous Comments:
[2007-02-22 19:02:51] [EMAIL PROTECTED]
Remove the @, you'll see the error.
[2007-02-22 18:34:44] frankpw at fw2s dot com
Additional info:
Server info: 5.0.27-community-max-nt
Client info: 5.0.22
That's as close to match server and client versions as it gets. I've
downloaded php_mysql.dll and php_mysqli.dll for server version 5.0.27
directly from MySQL. Please try the code below:
\n");
echo "Connected!\n";
echo "Host info: " . mysqli_get_host_info($mysqli) . "\n";
echo "Client info: " . mysqli_get_client_info() . "\n";
echo "Server info: " . mysqli_get_server_info($mysqli) . "\n";
echo "Protocol version: " . mysqli_get_proto_info($mysqli) . "\n";
?>
For test purposes make sure that first four parameters are correct and
use fifth as is. Repeat the test with "@" removed from the call to
mysqli_connect(). You'll see that warning is being displayed but
mysqli_connect_error() is empty and mysqli_connect_errno() == 0.
[2007-02-22 10:59:27] [EMAIL PROTECTED]
Cannot reproduce.
Make sure the client library is of the same version is the MySQL
server.
[2007-02-22 04:45:41] frankpw at fw2s dot com
Description:
In my class I'm opening a connection with mysqli_connect().
mysqli_connect_error() returns description of any error except one. If
one parameter is of wrong type (i.e port as string rather than
numeric).
Reproduce code:
---
public function OpenConnection($host, $user, $pass, $name = null,
$port = null, $sock = null, $chrs = null)
{
$this->mysqli = @mysqli_connect($host, $user, $pass, $name, $port,
$sock);
if (empty($this->mysqli)) die ("Execution stopped! " .
mysqli_connect_error() . "\n");
if (!empty($chrs)) $this->DefaultCharacterSet($chrs);
}
Expected result:
"Execution stopped! mysqli_connect expects parameter 5 to be long,
string given"
Actual result:
--
"Execution stopped!"
--
Edit this bug report at http://bugs.php.net/?id=40588&edit=1
#40588 [Opn->Bgs]: mysqli_connect_error() == "" on error
ID: 40588
Updated by: [EMAIL PROTECTED]
Reported By: frankpw at fw2s dot com
-Status: Open
+Status: Bogus
Bug Type: MySQLi related
Operating System: Win XP Pro
PHP Version: 5.2.1
New Comment:
Remove the @, you'll see the error.
Previous Comments:
[2007-02-22 18:34:44] frankpw at fw2s dot com
Additional info:
Server info: 5.0.27-community-max-nt
Client info: 5.0.22
That's as close to match server and client versions as it gets. I've
downloaded php_mysql.dll and php_mysqli.dll for server version 5.0.27
directly from MySQL. Please try the code below:
\n");
echo "Connected!\n";
echo "Host info: " . mysqli_get_host_info($mysqli) . "\n";
echo "Client info: " . mysqli_get_client_info() . "\n";
echo "Server info: " . mysqli_get_server_info($mysqli) . "\n";
echo "Protocol version: " . mysqli_get_proto_info($mysqli) . "\n";
?>
For test purposes make sure that first four parameters are correct and
use fifth as is. Repeat the test with "@" removed from the call to
mysqli_connect(). You'll see that warning is being displayed but
mysqli_connect_error() is empty and mysqli_connect_errno() == 0.
[2007-02-22 10:59:27] [EMAIL PROTECTED]
Cannot reproduce.
Make sure the client library is of the same version is the MySQL
server.
[2007-02-22 04:45:41] frankpw at fw2s dot com
Description:
In my class I'm opening a connection with mysqli_connect().
mysqli_connect_error() returns description of any error except one. If
one parameter is of wrong type (i.e port as string rather than
numeric).
Reproduce code:
---
public function OpenConnection($host, $user, $pass, $name = null,
$port = null, $sock = null, $chrs = null)
{
$this->mysqli = @mysqli_connect($host, $user, $pass, $name, $port,
$sock);
if (empty($this->mysqli)) die ("Execution stopped! " .
mysqli_connect_error() . "\n");
if (!empty($chrs)) $this->DefaultCharacterSet($chrs);
}
Expected result:
"Execution stopped! mysqli_connect expects parameter 5 to be long,
string given"
Actual result:
--
"Execution stopped!"
--
Edit this bug report at http://bugs.php.net/?id=40588&edit=1
#40595 [Opn->Bgs]: IMAP extension: utf8_mime2text() has wrong parameters
ID: 40595 Updated by: [EMAIL PROTECTED] Reported By: perske at uni-muenster dot de -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Independent PHP Version: 5.2.1 New Comment: >But with the current imap2006e.tar.Z, U8T_CANONICAL is >defined and utf8_mime2text() takes only two parameters. That's not true. See imap-2006e/src/c-client/utf8aux.c, line 116: long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT *dst,long flags) Previous Comments: [2007-02-22 18:26:52] perske at uni-muenster dot de Description: Bug 37948 should be reopened: The bugfix assumes that U8T_CANONICAL is not defined when the old parameter count of utf8_mime2text() is valid. But with the current imap2006e.tar.Z, U8T_CANONICAL is defined and utf8_mime2text() takes only two parameters. Thus configure fails with "this cannot happen". Supposed correction: Simple do not check for existence of U8T_CANONICAL in configure if the old parameter count is detected. (I'm trying to compile PHP 5.2.1 with imap2006e.) (After replacing all U8T_CANONICAL with XYXYXY in configure, compilation finishes successful.) Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/?id=40595&edit=1
#40588 [Fbk->Opn]: mysqli_connect_error() == "" on error
ID: 40588
User updated by: frankpw at fw2s dot com
Reported By: frankpw at fw2s dot com
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: Win XP Pro
PHP Version: 5.2.1
New Comment:
Additional info:
Server info: 5.0.27-community-max-nt
Client info: 5.0.22
That's as close to match server and client versions as it gets. I've
downloaded php_mysql.dll and php_mysqli.dll for server version 5.0.27
directly from MySQL. Please try the code below:
\n");
echo "Connected!\n";
echo "Host info: " . mysqli_get_host_info($mysqli) . "\n";
echo "Client info: " . mysqli_get_client_info() . "\n";
echo "Server info: " . mysqli_get_server_info($mysqli) . "\n";
echo "Protocol version: " . mysqli_get_proto_info($mysqli) . "\n";
?>
For test purposes make sure that first four parameters are correct and
use fifth as is. Repeat the test with "@" removed from the call to
mysqli_connect(). You'll see that warning is being displayed but
mysqli_connect_error() is empty and mysqli_connect_errno() == 0.
Previous Comments:
[2007-02-22 10:59:27] [EMAIL PROTECTED]
Cannot reproduce.
Make sure the client library is of the same version is the MySQL
server.
[2007-02-22 04:45:41] frankpw at fw2s dot com
Description:
In my class I'm opening a connection with mysqli_connect().
mysqli_connect_error() returns description of any error except one. If
one parameter is of wrong type (i.e port as string rather than
numeric).
Reproduce code:
---
public function OpenConnection($host, $user, $pass, $name = null,
$port = null, $sock = null, $chrs = null)
{
$this->mysqli = @mysqli_connect($host, $user, $pass, $name, $port,
$sock);
if (empty($this->mysqli)) die ("Execution stopped! " .
mysqli_connect_error() . "\n");
if (!empty($chrs)) $this->DefaultCharacterSet($chrs);
}
Expected result:
"Execution stopped! mysqli_connect expects parameter 5 to be long,
string given"
Actual result:
--
"Execution stopped!"
--
Edit this bug report at http://bugs.php.net/?id=40588&edit=1
#40595 [NEW]: IMAP extension: utf8_mime2text() has wrong parameters
From: perske at uni-muenster dot de Operating system: Independent PHP version: 5.2.1 PHP Bug Type: Compile Failure Bug description: IMAP extension: utf8_mime2text() has wrong parameters Description: Bug 37948 should be reopened: The bugfix assumes that U8T_CANONICAL is not defined when the old parameter count of utf8_mime2text() is valid. But with the current imap2006e.tar.Z, U8T_CANONICAL is defined and utf8_mime2text() takes only two parameters. Thus configure fails with "this cannot happen". Supposed correction: Simple do not check for existence of U8T_CANONICAL in configure if the old parameter count is detected. (I'm trying to compile PHP 5.2.1 with imap2006e.) (After replacing all U8T_CANONICAL with XYXYXY in configure, compilation finishes successful.) Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit bug report at http://bugs.php.net/?id=40595&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40595&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40595&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40595&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40595&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40595&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40595&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40595&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40595&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40595&r=support Expected behavior:http://bugs.php.net/fix.php?id=40595&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40595&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40595&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40595&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40595&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40595&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40595&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40595&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40595&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40595&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40595&r=mysqlcfg
#40594 [NEW]: Blocking socket functions cause Apache freeze
From: karldray at interchange dot ubc dot ca
Operating system: Windows XP
PHP version: 5.2.1
PHP Bug Type: Sockets related
Bug description: Blocking socket functions cause Apache freeze
Description:
I have a PHP page that opens a UDP socket and listens for data (blocking
on socket_recvfrom). When the socket recieves a packet, the script echoes
a message and finishes. This works fine, but when two instances of this
page are running (both blocking on socket_recvfrom), Apache (2.2.4) stops
responding to any new requests (even for non-php pages) until one of them
gets unblocked. The same problem occurs with other blocking socket
functions (such as socket_accept and socket_read with TCP sockets).
Reproduction instructions:
1. open a browser window to udp_recv.php?port=1. it sits there
"loading" since PHP is waiting for socket data.
2. open another browser window to udp_recv.php?port=2.
3 (the problem). open another browser window and point it to index.html or
any other url on the server. it just sits there "loading".
4. in a command prompt, type "perl udp_send.pl 1" to send 'hello' to
the first php script's udp socket, causing it to finish. Suddenly, the
third request completes.
Reproduce code:
---
udp_recv.php:
udp_send.pl:
use strict; use Socket;
socket(SOCKET, PF_INET, SOCK_DGRAM, getprotobyname('udp')) or die "socket:
$!";
send(SOCKET, 'hello', 0, sockaddr_in(shift, inet_aton('localhost'))) or
die "send: $!";
Expected result:
I expect Apache to continue to accept and handle new web page requests
while the two PHP pages are blocking on socket functions.
Actual result:
--
Once there are two PHP pages blocking on socket functions, all subsequent
requests (even for non-php URIs) appear as "loading" in the browser until
one of the PHP scripts unblocks.
Note: If the third request is for a PHP page containing an error_log() at
the very beginning, then the logfile output is not generated as long as
the first two pages are blocking (suggesting that Apache isn't getting
around to starting PHP during this time).
--
Edit bug report at http://bugs.php.net/?id=40594&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40594&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40594&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40594&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40594&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40594&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40594&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40594&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40594&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40594&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40594&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40594&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40594&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40594&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40594&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40594&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40594&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40594&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40594&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40594&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40594&r=mysqlcfg
#40593 [Opn->Bgs]: imagecreatefrompng memory using
ID: 40593 Updated by: [EMAIL PROTECTED] Reported By: alebec at sita dot fr -Status: Open +Status: Bogus Bug Type: Performance problem Operating System: WIN2000 PHP Version: 5.2.1 New Comment: GD library converts all images into the internal format. Yes, this format is quite memory consuming. But that's something not PHP related. Previous Comments: [2007-02-22 16:05:23] alebec at sita dot fr Description: Hello, i just update PHP from V4.4.? to V5.2.1 on W2000 iis . I use GD2 to convert png image file, since PHP5, i need to set memory_limit=50M to load a png file with imagecreatefrompng . With php4 there is no pb with memory_limit=20M My png file is http://www.fairtec.fr/bug.png Any explication ? Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=40593&edit=1
#40593 [NEW]: imagecreatefrompng memory using
From: alebec at sita dot fr Operating system: WIN2000 PHP version: 5.2.1 PHP Bug Type: Performance problem Bug description: imagecreatefrompng memory using Description: Hello, i just update PHP from V4.4.? to V5.2.1 on W2000 iis . I use GD2 to convert png image file, since PHP5, i need to set memory_limit=50M to load a png file with imagecreatefrompng . With php4 there is no pb with memory_limit=20M My png file is http://www.fairtec.fr/bug.png Any explication ? Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=40593&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40593&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40593&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40593&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40593&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40593&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40593&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40593&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40593&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40593&r=support Expected behavior:http://bugs.php.net/fix.php?id=40593&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40593&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40593&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40593&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40593&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40593&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40593&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40593&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40593&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40593&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40593&r=mysqlcfg
#40556 [Opn->Asn]: Browser abort causes server hang with FastCGI
ID: 40556
Updated by: [EMAIL PROTECTED]
Reported By: unreal at slashorg dot net
-Status: Open
+Status: Assigned
Bug Type: CGI related
Operating System: Linux 2.6.18
PHP Version: 5.2.1
Assigned To: dmitry
Previous Comments:
[2007-02-22 12:01:19] unreal at slashorg dot net
OK, I've done quite a lot more testing, and here are the results
(Apache 2.0.59/mod_fastcgi 2.4.2/PHP 5.2.1):
- I cannot reproduce the bug with your code either.
- The following code causes PHP workers to lock up if you abort during
download (and only if you abort):
http://www.slashorg.net/ex/crash.txt
Note: notice the "session_start();" line
- If I remove the "session_start();" line, PHP doesn't crash anymore,
even when I abort the download.
It seems this bug is more complicated than I thought, I hope you'll be
able to reproduce it.
Thanks for your help.
[2007-02-21 15:18:30] [EMAIL PROTECTED]
I am not able to reproduce the problem.
I tried to abort downloading from IE and download part of file running
the following PHP script from command line:
http://127.0.0.1/test/bug40556.php";, "r");
$s = fread($f, 1024*1024);
var_dump($s);
fclose($f);
?>
both cases work fine (Apache-1.3.28 with mod_fastcgi or ZendEnabler on
Linux 2.6.19)
[2007-02-20 12:48:13] unreal at slashorg dot net
I've just upgraded to 5.2.2-dev as you suggested, and that hasn't fixed
the problem.
My server is still dying as soon as a connection gets aborted.
[2007-02-20 12:14:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2007-02-20 12:10:10] unreal at slashorg dot net
Description:
PHP doesn't handle browser abort correctly.
- Use PHP to serve a file, using the code below
- Start downloading the file, and then abort.
Reproduce code:
---
header('Pragma: public');
header('Expires: 0');
header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
header('Cache-Control: public');
header('Content-Type: application/force-download');
header('Content-Type: application/octet-stream');
header('Content-Type: application/download');
header('Content-Disposition: attachment; filename="' . basename($path)
. '";');
header('Content-Transfer-Encoding: binary');
header('Content-Length: ' . filesize($path));
$handle = fopen($path, 'rb');
do {
$data = fread($handle, 8192);
if (strlen($data) == 0) {
break;
}
echo($data);
} while (true);
fclose($handle);
Expected result:
After browser abord, the server should remain responsive.
Actual result:
--
* Lots of errors in error_log:
'FastCGI: comm with server "/usr/local/www/cgi/php-cgi/php5.fcgi"
aborted: idle timeout (30 sec)'
'FastCGI: incomplete headers (0 bytes) received from server
"/usr/local/www/cgi/php-cgi/php5.fcgi"'
* Server stops responding, then after some time (maybe 5 mins), starts
responding again.
--
Edit this bug report at http://bugs.php.net/?id=40556&edit=1
#40578 [Opn->Fbk]: Thread safety issue with imagettftext
ID: 40578
Updated by: [EMAIL PROTECTED]
Reported By: scottmacvicar at ntlworld dot com
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: RHEL 4
PHP Version: 5.2.1
Assigned To: pajoye
Previous Comments:
[2007-02-22 01:48:56] scottmacvicar at ntlworld dot com
Applied now to one of our production boxes, When I'm back in
the office tomorrow I'll see if I can spend a little time
working out a test case to reproduce it.
[2007-02-22 00:57:19] [EMAIL PROTECTED]
It looks like something else.
Can you try:
http://pecl.php.net/~pierre/40568.txt
[2007-02-22 00:39:14] scottmacvicar at ntlworld dot com
Has this potentially caused a regression?
I applied the patch that was checked in CVS this afternoon
and recompiled PHP.
Had another segfault in GD, here is the backtrace.
Unfortunately it wasn't a debug build.
Thread 13 (process 27300):
#0 0x009457a2 in _dl_sysinfo_int80 () from /lib/ld-
linux.so.2
No symbol table info available.
#1 0x00985c46 in kill () from /lib/tls/libc.so.6
No symbol table info available.
#2 0x0807e646 in sig_coredump (sig=11) at mpm_common.c:1170
No locals.
#3
No symbol table info available.
#4 0x009bf652 in malloc_consolidate () from /lib/tls/
libc.so.6
No symbol table info available.
#5 0x009bfd30 in _int_free () from /lib/tls/libc.so.6
No symbol table info available.
#6 0x009c033a in free () from /lib/tls/libc.so.6
---Type to continue, or q to quit---
No symbol table info available.
#7 0x003d5b8a in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#8 0x9e418dc0 in ?? ()
No symbol table info available.
#9 0x00431b2c in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#10 0xa6629868 in ?? ()
No symbol table info available.
#11 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#12 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#13 0x003d88e9 in FT_GlyphLoader_Reset () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#14 0x003d8948 in FT_GlyphLoader_Done () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#15 0x003dc1de in FT_Remove_Module () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#16 0x003dc72b in FT_Done_Library () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#17 0x003d5ee0 in FT_Done_FreeType () from /usr/lib/
libfreetype.so.6
No symbol table info available.
---Type to continue, or q to quit---
#18 0x00fa4518 in php_gd_gdFontCacheShutdown ()
at /www/src/php-5.2.1/ext/gd/libgd/gdft.c:724
No locals.
#19 0x00f8c7eb in zm_deactivate_gd (type=1,
module_number=26,
tsrm_ls=0x94aea70) at /www/src/php-5.2.1/ext/gd/gd.c:
1303
No locals.
#20 0x0113434a in module_registry_cleanup (module=0x8b5d1b0,
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_API.c:1945
No locals.
#21 0x0113986c in zend_hash_apply (ht=0x14274e0,
apply_func=0x1134328 ,
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_hash.c:673
result = 0
p = (Bucket *) 0x8b5d180
#22 0x0112fb33 in zend_deactivate_modules
(tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend.c:839
__orig_bailout = (jmp_buf *) 0x0
__bailout = {{__jmpbuf = {144334232, 144334256,
19764252, -1503487368,
-1503487568, 18021115}, __mask_was_saved = 0,
__saved_mask = {__val = {
149310844, 10232833, 4294967294, 4294967295,
149310844, 165552858, 0,
0, 165552848, 165159443, 0, 0, 149809548, 0,
11036764, 24, 56, 88, 0,
11, 11536181, 144334232, 0, 2791479928, 17752220, 3,
165552848,
135009633, 2, 0, 165552808, 165552848
---Type to continue, or q to quit---
#23 0x010f19c5 in php_request_shutdown (dummy=0x0)
at /www/src/php-5.2.1/main/main.c:1293
__orig_bailout = Variable "__orig_bailout" is not
available.
I can try a debug build but the segfaults are occuring less
frequently now.
[2007-02-21 18:41:56] [EMAIL PROTECTED]
Also backported to 4_4.
[2007-02-21 18:24:27] scottmacvicar at ntlworld dot com
Any chance of having this backported to the PHP_4_4 branch? It's a
fairly minor patch to apply.
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/40578
--
Edit this bug report at http://bugs.php.net/?id=40578&edit=1
#40592 [Opn->Fbk]: undeclared constant causes build failure. bug not present in v5.2.0
ID: 40592 Updated by: [EMAIL PROTECTED] Reported By: fluor_druid at hotmail dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: OpenBSD 4.0 stable PHP Version: 5.2.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2007-02-22 15:37:22] fluor_druid at hotmail dot com Description: I'm no wiz with this, so this output is the best I can supply to give you guys a hint of what's going on when I do make after configure. it was configured with only -- prefix=somepath, the exact same way I configured and compiled version 5.2.0 on the same system just some weeks earlier - no changes has been made to my system since i built 5.2.0. I suspect this problem is due OpenBSD not being 100% POSIX compliant. --- snip --- /bin/sh /usr/opt/php-5.2.1/libtool --silent --preserve-dup- deps --mode=compile gcc -Iext/posix/ -I/usr/opt/php-5.2.1/ ext/posix/ -DPHP_ATOM_INC -I/usr/opt/php-5.2.1/include -I/ usr/opt/php-5.2.1/main -I/usr/opt/php-5.2.1 -I/usr/local/ include/libxml2 -I/usr/opt/php-5.2.1/ext/date/lib -I/usr/ local/include -I/usr/opt/php-5.2.1/TSRM -I/usr/opt/ php-5.2.1/Zend-I/usr/local/include -g -O2 -c /usr/opt/ php-5.2.1/ext/posix/posix.c -o ext/posix/posix.lo /usr/opt/php-5.2.1/ext/posix/posix.c: In function `zif_posix_getgrgid': /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: `_SC_GETGR_R_SIZE_MAX' undeclared (first use in this function) /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: (Each undeclared identifier is reported only once /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: for each function it appears in.) *** Error code 1 Expected result: That the package would compile without problems, as the earlier 5.2.0 version did with identical configuration and same OS. Actual result: -- Failure as described above. [2007-02-22 15:33:21] fluor_druid at hotmail dot com Description: I'm no wiz with this, so this output is the best I can supply to give you guys a hint of what's going on when I do make after configure. it was configured with only -- prefix=..., the exact same way I configured and compiled version 5.2.0 on the same OS just some weeks earlier - no changes has been made to my system. /bin/sh /usr/opt/php-5.2.1/libtool --silent --preserve-dup- deps --mode=compile gcc -Iext/posix/ -I/usr/opt/php-5.2.1/ ext/posix/ -DPHP_ATOM_INC -I/usr/opt/php-5.2.1/include -I/ usr/opt/php-5.2.1/main -I/usr/opt/php-5.2.1 -I/usr/local/ include/libxml2 -I/usr/opt/php-5.2.1/ext/date/lib -I/usr/ local/include -I/usr/opt/php-5.2.1/TSRM -I/usr/opt/ php-5.2.1/Zend-I/usr/local/include -g -O2 -c /usr/opt/ php-5.2.1/ext/posix/posix.c -o ext/posix/posix.lo /usr/opt/php-5.2.1/ext/posix/posix.c: In function `zif_posix_getgrgid': /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: `_SC_GETGR_R_SIZE_MAX' undeclared (first use in this function) /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: (Each undeclared identifier is reported only once /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: for each function it appears in.) *** Error code 1 Expected result: That the package would compile without problems, as the earlier 5.2.0 version did with identical configuration and same OS. Actual result: -- Failure as described above. -- Edit this bug report at http://bugs.php.net/?id=40592&edit=1
#40592 [Opn]: undeclared constant causes build failure. bug not present in v5.2.0
ID: 40592 User updated by: fluor_druid at hotmail dot com Reported By: fluor_druid at hotmail dot com Status: Open Bug Type: Compile Failure Operating System: OpenBSD 4.0 stable PHP Version: 5.2.1 New Comment: Description: I'm no wiz with this, so this output is the best I can supply to give you guys a hint of what's going on when I do make after configure. it was configured with only -- prefix=somepath, the exact same way I configured and compiled version 5.2.0 on the same system just some weeks earlier - no changes has been made to my system since i built 5.2.0. I suspect this problem is due OpenBSD not being 100% POSIX compliant. --- snip --- /bin/sh /usr/opt/php-5.2.1/libtool --silent --preserve-dup- deps --mode=compile gcc -Iext/posix/ -I/usr/opt/php-5.2.1/ ext/posix/ -DPHP_ATOM_INC -I/usr/opt/php-5.2.1/include -I/ usr/opt/php-5.2.1/main -I/usr/opt/php-5.2.1 -I/usr/local/ include/libxml2 -I/usr/opt/php-5.2.1/ext/date/lib -I/usr/ local/include -I/usr/opt/php-5.2.1/TSRM -I/usr/opt/ php-5.2.1/Zend-I/usr/local/include -g -O2 -c /usr/opt/ php-5.2.1/ext/posix/posix.c -o ext/posix/posix.lo /usr/opt/php-5.2.1/ext/posix/posix.c: In function `zif_posix_getgrgid': /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: `_SC_GETGR_R_SIZE_MAX' undeclared (first use in this function) /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: (Each undeclared identifier is reported only once /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: for each function it appears in.) *** Error code 1 Expected result: That the package would compile without problems, as the earlier 5.2.0 version did with identical configuration and same OS. Actual result: -- Failure as described above. Previous Comments: [2007-02-22 15:33:21] fluor_druid at hotmail dot com Description: I'm no wiz with this, so this output is the best I can supply to give you guys a hint of what's going on when I do make after configure. it was configured with only -- prefix=..., the exact same way I configured and compiled version 5.2.0 on the same OS just some weeks earlier - no changes has been made to my system. /bin/sh /usr/opt/php-5.2.1/libtool --silent --preserve-dup- deps --mode=compile gcc -Iext/posix/ -I/usr/opt/php-5.2.1/ ext/posix/ -DPHP_ATOM_INC -I/usr/opt/php-5.2.1/include -I/ usr/opt/php-5.2.1/main -I/usr/opt/php-5.2.1 -I/usr/local/ include/libxml2 -I/usr/opt/php-5.2.1/ext/date/lib -I/usr/ local/include -I/usr/opt/php-5.2.1/TSRM -I/usr/opt/ php-5.2.1/Zend-I/usr/local/include -g -O2 -c /usr/opt/ php-5.2.1/ext/posix/posix.c -o ext/posix/posix.lo /usr/opt/php-5.2.1/ext/posix/posix.c: In function `zif_posix_getgrgid': /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: `_SC_GETGR_R_SIZE_MAX' undeclared (first use in this function) /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: (Each undeclared identifier is reported only once /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: for each function it appears in.) *** Error code 1 Expected result: That the package would compile without problems, as the earlier 5.2.0 version did with identical configuration and same OS. Actual result: -- Failure as described above. -- Edit this bug report at http://bugs.php.net/?id=40592&edit=1
#40592 [NEW]: undeclared constant causes build failure. bug not present in v5.2.0
From: fluor_druid at hotmail dot com Operating system: OpenBSD 4.0 stable PHP version: 5.2.1 PHP Bug Type: Compile Failure Bug description: undeclared constant causes build failure. bug not present in v5.2.0 Description: I'm no wiz with this, so this output is the best I can supply to give you guys a hint of what's going on when I do make after configure. it was configured with only -- prefix=..., the exact same way I configured and compiled version 5.2.0 on the same OS just some weeks earlier - no changes has been made to my system. /bin/sh /usr/opt/php-5.2.1/libtool --silent --preserve-dup- deps --mode=compile gcc -Iext/posix/ -I/usr/opt/php-5.2.1/ ext/posix/ -DPHP_ATOM_INC -I/usr/opt/php-5.2.1/include -I/ usr/opt/php-5.2.1/main -I/usr/opt/php-5.2.1 -I/usr/local/ include/libxml2 -I/usr/opt/php-5.2.1/ext/date/lib -I/usr/ local/include -I/usr/opt/php-5.2.1/TSRM -I/usr/opt/ php-5.2.1/Zend-I/usr/local/include -g -O2 -c /usr/opt/ php-5.2.1/ext/posix/posix.c -o ext/posix/posix.lo /usr/opt/php-5.2.1/ext/posix/posix.c: In function `zif_posix_getgrgid': /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: `_SC_GETGR_R_SIZE_MAX' undeclared (first use in this function) /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: (Each undeclared identifier is reported only once /usr/opt/php-5.2.1/ext/posix/posix.c:889: error: for each function it appears in.) *** Error code 1 Expected result: That the package would compile without problems, as the earlier 5.2.0 version did with identical configuration and same OS. Actual result: -- Failure as described above. -- Edit bug report at http://bugs.php.net/?id=40592&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40592&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40592&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40592&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40592&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40592&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40592&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40592&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40592&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40592&r=support Expected behavior:http://bugs.php.net/fix.php?id=40592&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40592&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40592&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40592&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40592&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40592&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40592&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40592&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40592&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40592&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40592&r=mysqlcfg
#38233 [Com]: Random Fatal SoapFault errors
ID: 38233
Comment by: a-wu at gmx dot net
Reported By: khalid at pixelcraze dot com
Status: No Feedback
Bug Type: SOAP related
Operating System: FC 4
PHP Version: 5.1.4
New Comment:
Hi,
i've got the same bug, unfortunately.
my code (of the client)
$task = new SoapClient(...wsdlpath...);
$sec = $task->securityCheck($Username, $Password);
$id = $task->login($sec, process_id);
$bool = $task->logout($sec, $id);
Expected results:
boolean, if the action was successful or not.
Actual result:
Sometimes the process is not able to logout. I catch the exception and
get the message "Error fetching http headers" and I don't know why.
I use php 5.1.4 and apache 2.0.59.
Is there a solution to this.
Thanks,
Andre
Previous Comments:
[2006-10-20 04:03:45] ottophobia at yahoo dot com
I am receiving these errors and have no idea what they mean or
how to solve the problem. Can anyone help?
"Fatal error: main(): Failed opening required '/p/
prep.inc' (include_path='.:/usr/local/lib/php') in /home/
content/s/h/i/shir13/html/gallery/zoom/index.php on line 2"
Johnny
[2006-09-28 12:38:57] horaci at gmail dot com
We are having the exact same problem, randomly, when trying to access
webservices from our SAP servers business connectors.
As far as we know, it has been working flawlesly for at least 2 months
until 3 days ago.
Any help is appreciated,
Thanks
[2006-08-05 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2006-07-28 10:53:17] [EMAIL PROTECTED]
Please provide SHORT and COMPLETE reproduce script, just to be sure
that it's not a PEAR issue.
[2006-07-28 10:47:23] khalid at pixelcraze dot com
Script requires Pear://Services_Google and a google API Key from
www.google.com/api/
queryOptions['limit'] = 1000;
$google->search('"page '.$i.'"');
$googleRes = $google->numResults();
echo "$i: $googleRes\n";
}
?>
THe issue is that sometimes this script will run fine. Another time,
the script will die at random intervals...
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/38233
--
Edit this bug report at http://bugs.php.net/?id=38233&edit=1
#22427 [Com]: Missing Form Post Data
ID: 22427 Comment by: elio at tondo dot it Reported By: jroland at uow dot edu dot au Status: No Feedback Bug Type: *General Issues Operating System: Windows XP / 2000 PHP Version: 4.2.3 New Comment: I am experiencing the same problem reported on 29 Aug 2006 by "egil at egil dot net". I can add some more details: - I confirm that it happens only with IE; - it is triggered when a character between 0x80 and 0x9f is used in a form field (e.g. the "Word" quotation marks, but also the Euro symbol) -- please note that these are the transposition in the "high half" part of extended ASCII of the 32 "control characters" of ASCII (0x00 - 0x1f); - it has some relationship with character encoding; - I can reproduce it on Linux with Apache 2 on Fedora 4 - 6 if I don't force "AddDefaultCharset UTF-8" in httpd.conf (the default in Fedora); with this directive the problem dies not happen, but the "strange" characters are interpreted incorrectly (because the file is not UTF8); - I cannot reproduce it on Linux Mandrake 10 / Apache 2; - I cannot reproduce it on Windows XP / XAMPP (Apache 2). A further interesting detail: it happens only if the file containing the form has the .php extension; if it has the .htm extension it does not happen! (please note that I am using plain HTML for the form and some PHP to show the results). >From all of the above, it looks like it is not a PHP bug, but instead a IE6 bug that is triggered by some combination of MIME types and character encodings. I am going to prepare a simpler test case (I am currently using a rather complicated page with a multi part form that I extracted from an application that was working on Mandrake and ceased to work on Fedora, and worked again by adding a dummy hidden field as the first one in the form...). When it will be ready I will post it here. In the meantime, does anyone know if a similar problem has been reported elsewhere? Previous Comments: [2007-02-19 15:27:27] arek_felinczak at o2 dot pl I had the same problem with empty $_POST table. In my case solution was to remove post_max_size line from php.ini. In php.ini i had post_max_size = 16000 instead of default post_max_size = 8M [2006-12-07 22:30:59] celtic at sairyx dot org I'm experiencing the same problem. Server's running Apache 2 on a Windows Server 2003 machine. IE 6.0, Windows XP SP 2, and about 90% of the time, POST data never reaches my PHP script. Firefox 1.5 in the same conditions, and it runs perfectly. It does seem suspiciously like an IE bug, but this seems too big to be a coincidence that IE never sends POST data to only these PHP applications. [2006-10-18 08:15:50] thisisrobg at gmail dot com Not sure if it exactly the same problem but POST related. - PHP5.2.0RC6-dev - Apache 2.2.3 - IE6 Code SQL : SQL2 : SQL3 : /*sqlprocess.php */ $query = $_REQUEST["sqlstring"]; $query2 = $_REQUEST["sqlstring2"]; $query3 = $_REQUEST["sqlstring3"]; print "Query: " . $query . ""; print "Query2: " . $query2 . ""; print "Query3: " . $query3 . ""; - Problem: None of the field show up when request. Experiments 1. Change form method to GET and it work perfectly. 2. Add/Remove fields make no different, still get nothing. 3. Change $_REQUEST to $_POST or $HTTP_POST_VARS make no different, still get nothing. 4. Change browser to Firefox 2.0b1 and it works fine. 5. Change browser to Opera 9.01 builds 8552 and it works fine. Expecting the problem to be incompatibility between PHP5.2 and IE6. I was using PHP5.1.6 and IIS and POST method works. [2006-10-07 04:29:05] zero at tilt dot eu dot org Same prob, PHP5 in cgi, Apache and env REQUEST_METHOD is POST, there is a content length, but $_POST is empty... This is not a prob with my browser. Tested with Opera 9 and Firefox 1.5. And oh, no prob with an other server :/ Weird. [2006-09-14 13:06:50] emil dot hall at gamereactor dot se We must be talking about several different bugs here. But the bug where some fields are missing from $_POST is NOT a PHP bug, it's all Internet Explorer's fault. This HTML reproduces the bug in IE6: The weird character in the second input field will mess up IE's submit. Characters that confuse IE include: three-dots-as-one-char aka chr(133) the long dash aka chr(150) and the double quotation mark aka chr(147) All very common when you copy&paste from MS Word, just like Egil said. A packet sniffer reveals the broken POST request: (some irrelevant headers have been removed) POST /whatever HTTP/1.1 Content-Type: multipart/form-data; boundary=---7d6399243401fe
#40591 [Opn->Asn]: list()="string"; gives invalid opcode
ID: 40591 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type:Scripting Engine problem PHP Version: 5CVS-2007-02-22 (snap) -Assigned To: +Assigned To: dmitry Previous Comments: [2007-02-22 15:13:32] [EMAIL PROTECTED] Description: . Reproduce code: --- list($a,$b,$c)="abc"; -- Edit this bug report at http://bugs.php.net/?id=40591&edit=1
#40591 [NEW]: list()="string"; gives invalid opcode
From: [EMAIL PROTECTED] Operating system: PHP version: 5CVS-2007-02-22 (snap) PHP Bug Type: Scripting Engine problem Bug description: list()="string"; gives invalid opcode Description: . Reproduce code: --- list($a,$b,$c)="abc"; -- Edit bug report at http://bugs.php.net/?id=40591&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40591&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40591&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40591&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40591&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40591&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40591&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40591&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40591&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40591&r=support Expected behavior:http://bugs.php.net/fix.php?id=40591&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40591&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40591&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40591&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40591&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40591&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40591&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40591&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40591&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40591&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40591&r=mysqlcfg
#40590 [NEW]: list($k,$v) = $v; gives unexpected output
From: black at scene-si dot org
Operating system: linux
PHP version: 5.2.1
PHP Bug Type: Variables related
Bug description: list($k,$v) = $v; gives unexpected output
Description:
list() overwriting variable, unexpected result (different from php4).
Reproduce code:
---
$v = array("00","-- Day --");
list($k,$v) = $v;
var_dump(array($k,$v));
Expected result:
Var dump should return:
array(2) {
[0]=> string(2) "00"
[1]=> string(11) "-- Day -- "
}
Actual result:
--
Var dump returns:
array(2) {
[0]=> string(1) "-"
[1]=> string(11) "-- Day -- "
}
--
Edit bug report at http://bugs.php.net/?id=40590&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40590&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40590&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40590&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40590&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40590&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40590&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40590&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40590&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40590&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40590&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40590&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40590&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40590&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40590&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40590&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40590&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40590&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40590&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40590&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40590&r=mysqlcfg
#39858 [Com]: Lost connection to MySQL server during query by a repeated call stored proced
ID: 39858
Comment by: james dot cordon at btinternet dot com
Reported By: develar at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.0
Assigned To: wez
New Comment:
AHH
My bodge-it above doesn't work correctly, it just opens but doesn't
close many connections.
This does work (tried several times on 200 consec' queries)
added closeCursor().
$i=100;
while($i>0){
echo 'LOOP NUM:'.$i.'';
try{
$stmt=$pdodl_1->query("call testMany()");
$stmt->setFetchMode(PDO::FETCH_ASSOC);
echo 'PDODL OBJ: ';
var_dump($pdodl_1);
echo 'PDO::STATEMENT OBJ: ';
var_dump($stmt);
echo '';
while ($row= $stmt->fetch()) {
echo '';
var_dump($row);
echo '';
}
$i--;
}catch(PDOException $e){
if($e->getCode()=='HY000'){
$stmt->closeCursor();
$pdodl_1->connect();
$i--;
} else {
throw $e;
}
}
}
Previous Comments:
[2007-02-22 11:37:01] james dot cordon at btinternet dot com
php 5.2.1
win xp pro
mysql 5x
apache 2x
I also built a project assuming stored procedures would work
as they are mentioned in the php docs, anyway.
to cut a long story short, I extended PDO with methods that included
not connectimg to DB until actually needed.
public function connect(){
try{
parent::__construct($this->connect_a['DSN'], $this->connect_a['U'],
$this->connect_a['P']);
} catch (Exception $e) {
throw($e);
}
### always use exception error handling
$this->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$this->connected=1;
}//
When calling a 2nd query (after a stored procedure) I get the
"SQLSTATE[HY000]:
General error: 2013 Lost connection to MySQL server during query" every
time.
I discovered calling "$pdoextended->connect();" after each use of a
stored procedure revived the connection (without instantiating another
PDOextended obj) with no errors.
This is ONLY a bodge-it but it is a very lightweight one.
[2007-02-20 14:24:37] barney dot hanlon at markettiers4dc dot com
That would technically be a workaround rather then a fix. The issue is
still there, and switching to ODBC is not necessarily a good or
acceptable solution. Also as we have taken onboard the Zend Framework
prior to beginning work on Zend Platform, creating non-standard
solutions doesn't sound like a forward step.
However, until the PHP team pull their fingers out and assess PDO to
work with Windows properly, I may have to implement it. Thank goodness
that the partnership with Microsoft will force PHP to stop treating IIS
as a perochial platform and get proper support.
[2007-02-19 18:45:52] denis dot podgurskiy at cofelab dot ru
Hi once again.
Step by step instruction how to work with MySQL sp/transaction under
Win XP SP 2
1. Install MySQL ODBC driver.
2. Create database with tables in InnoDB format (to support transaction
- see my.cnf).
3. Create DSN with connection to your database (see Admin
tools->ODBC).
4. Enable pdo_odbc within php.ini file.
5. Use this to create connection
if(strstr($_SERVER['SERVER_SOFTWARE'],'Win')){
$this -> Db = new PDO("odbc:DSN=MY_MySQL_ODBC;", user,
password);
} else {
$this -> Db = Zend_Db::factory( PDO_MYSQL);
6. When the sp has been executed do not forget to fetch the statement:
$command -> execute();
do {
$rows = $command->fetchAll();
} while ($command -> nextRowset());
That's all. This code will work under win/nix without any diffireneces
- checked by me.
If you still have any problems - just email me and I'll contact you by
ICQ/Skype to help (I spent four weeks to solve it).
Regards, Denis
[2007-02-15 13:56:39] mike at we11er dot co dot uk
Thanks for the help Denis, although I can't personally implement this
workaround...
For the time being I have hacked in lines of code to create a new
database connection before calling certain stored procedures.
Now, PLEASE could a developer or someone RESPOND and acknowledge this
bug, and let us know
#40556 [Fbk->Opn]: Browser abort causes server hang with FastCGI
ID: 40556
User updated by: unreal at slashorg dot net
Reported By: unreal at slashorg dot net
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Linux 2.6.18
PHP Version: 5.2.1
Assigned To: dmitry
New Comment:
OK, I've done quite a lot more testing, and here are the results
(Apache 2.0.59/mod_fastcgi 2.4.2/PHP 5.2.1):
- I cannot reproduce the bug with your code either.
- The following code causes PHP workers to lock up if you abort during
download (and only if you abort):
http://www.slashorg.net/ex/crash.txt
Note: notice the "session_start();" line
- If I remove the "session_start();" line, PHP doesn't crash anymore,
even when I abort the download.
It seems this bug is more complicated than I thought, I hope you'll be
able to reproduce it.
Thanks for your help.
Previous Comments:
[2007-02-21 15:18:30] [EMAIL PROTECTED]
I am not able to reproduce the problem.
I tried to abort downloading from IE and download part of file running
the following PHP script from command line:
http://127.0.0.1/test/bug40556.php";, "r");
$s = fread($f, 1024*1024);
var_dump($s);
fclose($f);
?>
both cases work fine (Apache-1.3.28 with mod_fastcgi or ZendEnabler on
Linux 2.6.19)
[2007-02-20 12:48:13] unreal at slashorg dot net
I've just upgraded to 5.2.2-dev as you suggested, and that hasn't fixed
the problem.
My server is still dying as soon as a connection gets aborted.
[2007-02-20 12:14:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2007-02-20 12:10:10] unreal at slashorg dot net
Description:
PHP doesn't handle browser abort correctly.
- Use PHP to serve a file, using the code below
- Start downloading the file, and then abort.
Reproduce code:
---
header('Pragma: public');
header('Expires: 0');
header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
header('Cache-Control: public');
header('Content-Type: application/force-download');
header('Content-Type: application/octet-stream');
header('Content-Type: application/download');
header('Content-Disposition: attachment; filename="' . basename($path)
. '";');
header('Content-Transfer-Encoding: binary');
header('Content-Length: ' . filesize($path));
$handle = fopen($path, 'rb');
do {
$data = fread($handle, 8192);
if (strlen($data) == 0) {
break;
}
echo($data);
} while (true);
fclose($handle);
Expected result:
After browser abord, the server should remain responsive.
Actual result:
--
* Lots of errors in error_log:
'FastCGI: comm with server "/usr/local/www/cgi/php-cgi/php5.fcgi"
aborted: idle timeout (30 sec)'
'FastCGI: incomplete headers (0 bytes) received from server
"/usr/local/www/cgi/php-cgi/php5.fcgi"'
* Server stops responding, then after some time (maybe 5 mins), starts
responding again.
--
Edit this bug report at http://bugs.php.net/?id=40556&edit=1
#39858 [Com]: Lost connection to MySQL server during query by a repeated call stored proced
ID: 39858
Comment by: james dot cordon at btinternet dot com
Reported By: develar at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.0
Assigned To: wez
New Comment:
php 5.2.1
win xp pro
mysql 5x
apache 2x
I also built a project assuming stored procedures would work
as they are mentioned in the php docs, anyway.
to cut a long story short, I extended PDO with methods that included
not connectimg to DB until actually needed.
public function connect(){
try{
parent::__construct($this->connect_a['DSN'], $this->connect_a['U'],
$this->connect_a['P']);
} catch (Exception $e) {
throw($e);
}
### always use exception error handling
$this->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$this->connected=1;
}//
When calling a 2nd query (after a stored procedure) I get the
"SQLSTATE[HY000]:
General error: 2013 Lost connection to MySQL server during query" every
time.
I discovered calling "$pdoextended->connect();" after each use of a
stored procedure revived the connection (without instantiating another
PDOextended obj) with no errors.
This is ONLY a bodge-it but it is a very lightweight one.
Previous Comments:
[2007-02-20 14:24:37] barney dot hanlon at markettiers4dc dot com
That would technically be a workaround rather then a fix. The issue is
still there, and switching to ODBC is not necessarily a good or
acceptable solution. Also as we have taken onboard the Zend Framework
prior to beginning work on Zend Platform, creating non-standard
solutions doesn't sound like a forward step.
However, until the PHP team pull their fingers out and assess PDO to
work with Windows properly, I may have to implement it. Thank goodness
that the partnership with Microsoft will force PHP to stop treating IIS
as a perochial platform and get proper support.
[2007-02-19 18:45:52] denis dot podgurskiy at cofelab dot ru
Hi once again.
Step by step instruction how to work with MySQL sp/transaction under
Win XP SP 2
1. Install MySQL ODBC driver.
2. Create database with tables in InnoDB format (to support transaction
- see my.cnf).
3. Create DSN with connection to your database (see Admin
tools->ODBC).
4. Enable pdo_odbc within php.ini file.
5. Use this to create connection
if(strstr($_SERVER['SERVER_SOFTWARE'],'Win')){
$this -> Db = new PDO("odbc:DSN=MY_MySQL_ODBC;", user,
password);
} else {
$this -> Db = Zend_Db::factory( PDO_MYSQL);
6. When the sp has been executed do not forget to fetch the statement:
$command -> execute();
do {
$rows = $command->fetchAll();
} while ($command -> nextRowset());
That's all. This code will work under win/nix without any diffireneces
- checked by me.
If you still have any problems - just email me and I'll contact you by
ICQ/Skype to help (I spent four weeks to solve it).
Regards, Denis
[2007-02-15 13:56:39] mike at we11er dot co dot uk
Thanks for the help Denis, although I can't personally implement this
workaround...
For the time being I have hacked in lines of code to create a new
database connection before calling certain stored procedures.
Now, PLEASE could a developer or someone RESPOND and acknowledge this
bug, and let us know what is going on!?
I've been stuck with this bug for months and months with no help
whatsoever from the PHP guys.
[2007-02-07 09:25:31] denis dot podgurskiy at cofelab dot ru
It works under Nix as well. So, good luck.
[2007-02-06 17:13:57] denis dot podgurskiy at cofelab dot ru
One more thing - you need to install MySQL ODBC driver to work with
MySQL in this example: see dsn string. I use named DSN - XMS_MySQL
based on MySQL ODBC 3.51.12 Win driver.
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/39858
--
Edit this bug report at http://bugs.php.net/?id=39858&edit=1
#40554 [Opn->Bgs]: DomElement->set_attribute() for french characters
ID: 40554 Updated by: [EMAIL PROTECTED] Reported By: vijijvs at yahoo dot co dot in -Status: Open +Status: Bogus Bug Type: DOM XML related Operating System: Mandrake linux PHP Version: 4.3.9 New Comment: We can't fix something that was released years ago. Previous Comments: [2007-02-22 11:30:50] vijijvs at yahoo dot co dot in Any workaround for this? [2007-02-22 11:25:09] vijijvs at yahoo dot co dot in Wants to fix with this version itself. Updating to latest version leads to problem in our environment and it is quite risk. [2007-02-20 10:48:51] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2007-02-20 10:42:27] vijijvs at yahoo dot co dot in Description: When "/home/viji/Endroit de protection de caractères spéciaux" is passed as argument to DomElement->set_attribute() function, the french letters è and é get converted into 貥 and 飩. Php version im using is 4.3.9 and Apache 1.33. Note: = Tried by using utf8_encode() and utf8_decode() before setting value for the attribute. Reproduce code: --- DomElement->set_attribute(Name, "/home/viji/Endroit de protection de caractères spéciaux"); Expected result: Actual result: -- -- Edit this bug report at http://bugs.php.net/?id=40554&edit=1
#40554 [Opn]: DomElement->set_attribute() for french characters
ID: 40554 User updated by: vijijvs at yahoo dot co dot in Reported By: vijijvs at yahoo dot co dot in Status: Open Bug Type: DOM XML related Operating System: Mandrake linux -PHP Version: 4.4.5 +PHP Version: 4.3.9 New Comment: Any workaround for this? Previous Comments: [2007-02-22 11:25:09] vijijvs at yahoo dot co dot in Wants to fix with this version itself. Updating to latest version leads to problem in our environment and it is quite risk. [2007-02-20 10:48:51] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2007-02-20 10:42:27] vijijvs at yahoo dot co dot in Description: When "/home/viji/Endroit de protection de caractères spéciaux" is passed as argument to DomElement->set_attribute() function, the french letters è and é get converted into 貥 and 飩. Php version im using is 4.3.9 and Apache 1.33. Note: = Tried by using utf8_encode() and utf8_decode() before setting value for the attribute. Reproduce code: --- DomElement->set_attribute(Name, "/home/viji/Endroit de protection de caractères spéciaux"); Expected result: Actual result: -- -- Edit this bug report at http://bugs.php.net/?id=40554&edit=1
#40554 [Bgs->Opn]: DomElement->set_attribute() for french characters
ID: 40554 User updated by: vijijvs at yahoo dot co dot in Reported By: vijijvs at yahoo dot co dot in -Status: Bogus +Status: Open Bug Type: DOM XML related Operating System: Mandrake linux PHP Version: 4.4.5 New Comment: Wants to fix with this version itself. Updating to latest version leads to problem in our environment and it is quite risk. Previous Comments: [2007-02-20 10:48:51] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2007-02-20 10:42:27] vijijvs at yahoo dot co dot in Description: When "/home/viji/Endroit de protection de caractères spéciaux" is passed as argument to DomElement->set_attribute() function, the french letters è and é get converted into 貥 and 飩. Php version im using is 4.3.9 and Apache 1.33. Note: = Tried by using utf8_encode() and utf8_decode() before setting value for the attribute. Reproduce code: --- DomElement->set_attribute(Name, "/home/viji/Endroit de protection de caractères spéciaux"); Expected result: Actual result: -- -- Edit this bug report at http://bugs.php.net/?id=40554&edit=1
#40588 [Opn->Fbk]: mysqli_connect_error() == "" on error
ID: 40588
Updated by: [EMAIL PROTECTED]
Reported By: frankpw at fw2s dot com
-Status: Open
+Status: Feedback
Bug Type: MySQLi related
Operating System: Win XP Pro
PHP Version: 5.2.1
New Comment:
Cannot reproduce.
Make sure the client library is of the same version is the MySQL
server.
Previous Comments:
[2007-02-22 04:45:41] frankpw at fw2s dot com
Description:
In my class I'm opening a connection with mysqli_connect().
mysqli_connect_error() returns description of any error except one. If
one parameter is of wrong type (i.e port as string rather than
numeric).
Reproduce code:
---
public function OpenConnection($host, $user, $pass, $name = null,
$port = null, $sock = null, $chrs = null)
{
$this->mysqli = @mysqli_connect($host, $user, $pass, $name, $port,
$sock);
if (empty($this->mysqli)) die ("Execution stopped! " .
mysqli_connect_error() . "\n");
if (!empty($chrs)) $this->DefaultCharacterSet($chrs);
}
Expected result:
"Execution stopped! mysqli_connect expects parameter 5 to be long,
string given"
Actual result:
--
"Execution stopped!"
--
Edit this bug report at http://bugs.php.net/?id=40588&edit=1
#40589 [Opn->Fbk]: mysqli can't handle a reconnect, crashes
ID: 40589 Updated by: [EMAIL PROTECTED] Reported By: pegasus at nerv dot eu dot org -Status: Open +Status: Feedback -Bug Type: Reproducible crash +Bug Type: MySQLi related Operating System: Linux PHP Version: 5.2.1 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 the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2007-02-22 09:42:16] pegasus at nerv dot eu dot org Forgot to mention that this only happens when using prepared statements. [2007-02-22 08:55:01] pegasus at nerv dot eu dot org Description: If you set mysql timeouts (in my.cnf) to some short times, like: set-variable = connect_timeout=3 set-variable = interactive_timeout=5 set-variable = wait_timeout=10 And then have a script, that opens mysql connection via mysqli, sleeps for 20 seconds and then tries to do something with that connection, php crashes. Reproduce code: --- Simple enough to reproduce from the comment above Actual result: -- Segfault: #0 0xb7638542 in net_clear () from /usr/lib/./libmysqlclient.so.15 #1 0xb7613df3 in cli_stmt_execute () from /usr/lib/./libmysqlclient.so.15 #2 0xb76142b3 in mysql_stmt_execute () from /usr/lib/./libmysqlclient.so.15 #3 0x081e806c in zif_mysqli_stmt_execute () #4 0x0842a8ea in execute () #5 0x0842ada6 in execute () #6 0x0842a516 in execute () #7 0x0840c9da in zend_execute_scripts () #8 0x083ca2f4 in php_execute_script () #9 0x0846c701 in main () -- Edit this bug report at http://bugs.php.net/?id=40589&edit=1
#40567 [Opn->Bgs]: DOMDocument->createElement()
ID: 40567
Updated by: [EMAIL PROTECTED]
Reported By: bpipe at mail dot ru
-Status: Open
+Status: Bogus
Bug Type:Feature/Change Request
PHP Version: 5.2.1
New Comment:
>i'm not sayng that you shouldn't allow to use it i'm sayng
>that you should generate a notice about it,
It's a valid character, so no notice would make sense.
Previous Comments:
[2007-02-22 08:32:48] bpipe at mail dot ru
I; not sayng this is bug, i marked this as feature request
[2007-02-22 08:28:41] bpipe at mail dot ru
"element names are already validated and cause an error to be issued.
The
":" char is a valid character in an element name"
Yes ":" is valid character for element name, i'm not sayng that you
shouldn't allow to use it i'm sayng that you should generate a notice
about it, it;s lika casting float value to int value in C++ (cimpiler
generate a notice about possible loss of data), same here, when user
creates Element with ":" after document is saved the reslut will be not
what he expect (this is lost of data) the part before ":" becomes
NameSpace.
[2007-02-21 17:16:17] [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
element names are already validated and cause an error to be issued.
The ":" char is a valid character in an element name
[2007-02-20 22:07:26] bpipe at mail dot ru
Description:
DomDocument->CreateElement()
I have a feature request, i think you should add a waring or notice
when someone is calling CreateElement with ':' in node name.
Like this one:
$xsl->createElement('xsl:import');
instead of CreateElementNS, because this problem is hard to detect
(document look like it should when you output it)
I made this mistake myself and it took me 2 days to find out the
problem, and only when i found the problem i managed to find any
information about this in bugzilla.
A notice when you create XML node with ':' in name could save 2 days of
my life )
Really very hard to detect this mistake, i was googling, sitting in IRC
and asking everyone for 48 hours without any result. And i think I'm not
alone who "stepped on this rake"
--
Edit this bug report at http://bugs.php.net/?id=40567&edit=1
#40159 [NoF->Bgs]: Cannot access protected property
ID: 40159
Updated by: [EMAIL PROTECTED]
Reported By: dominik dot bulaj at gmail dot com
-Status: No Feedback
+Status: Bogus
Bug Type: Class/Object related
Operating System: Debian
PHP Version: 5.2.0
New Comment:
Do not file bugs when you have Zend extensions (zend_extension=)
loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache,
APC, Xdebug and ionCube loader. These extensions often modify engine
behavior which is not related to PHP itself.
Previous Comments:
[2007-02-22 06:21:48] bugs dot php at mobocracy dot net
BTW, this appears to be fixed with eaccelerator svn snapshot 301.
-Blake
[2007-02-22 06:16:58] bugs dot php at mobocracy dot net
I am getting a similar issue with PHP 5.2.1, Linux, with eAccelerator.
I have two classes like:
class Foo {
protected $item;
function __construct()
{
$this->item = 'Foo';
}
}
class Bar extends Foo {}
When I do:
$c = new Bar();
I get the same fatal error as described in the original report. When I
disable eaccelerator, this goes away. I will submit a bug to
eaccelerator.
[2007-01-26 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-01-18 11:22:32] [EMAIL PROTECTED]
Cannot reproduce.
[2007-01-18 11:20:19] dominik dot bulaj at gmail dot com
Description:
I got 3 classes:
abstract class BlogApi
{
protected $blogUrl = false;
// other properties
public function setup($blogUrl, $username, $password, $blogId = 1)
{
$this->blogUrl = $blogUrl;
$this->username = $username;
$this->password = $password;
$this->blogId = $blogId;
return $this;
}
// rest of methods
}
abstract class BloggerApi extends BlogApi
{
// some methods specyfic for BloggerApi
}
class WordPress extends BloggerApi
{
// some methods
public function publish()
{
return $this->publishToBlog(rtrim($this->blogUrl,
'/').'/xmlrpc.php');
}
}
Now when I start with:
$wp = new WordPress;
$wp->setup('some_url', 'usr_name', 'pwd', 1);
// another method to set-up post subject & body
$wp->publish();
I got error:
Fatal error: Cannot access protected property WordPress::$blogUrl in
Strange is, that code worked well in PHP 5.1.6-5 on Debian.
Actual result:
--
Fatal error: Cannot access protected property WordPress::$blogUrl in
...
--
Edit this bug report at http://bugs.php.net/?id=40159&edit=1
#37120 [Opn->Fbk]: mod_php5 + apache2 + mail() = hung process
ID: 37120 Updated by: [EMAIL PROTECTED] Reported By: brlcad at mac dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: FreeBSD 5.2.1 PHP Version: 5.1.2 New Comment: Do not touch the production Apache, setup an Apache instance in your $HOME dir, listening on a different port. Previous Comments: [2007-02-22 04:59:45] brlcad at mac dot com Yes, but such a pain in the arse to set up as it's a live production system...where's the magical intuition and devine insight?? :-) I'll see if I can get an updated backtrace. Cheers! [2007-02-21 23:16:17] [EMAIL PROTECTED] >Now with whatever change was made in mail() since 5.2.1, > it crashes the httpd. A gdb backtrace is worth of thousand words. [2007-02-21 23:10:23] brlcad at mac dot com For what it's worth, I don't believe the problem (at least as I've reported) is so much related to the previous poster's freebsd bug report link. It may very well be specific to FreeBSD and even this version of the OS, but it also seems to be rather isolated to PHP5. I've tested with other Apache modules and none of them have trouble sending mail like PHP seems to be having, and sending mail directly works like a charm. What's perhaps useful to note, and that I perhaps didn't emphasize enough, is that with version 5.1.2 it would just hang the httpd process and the web page request would simply never terminate. Now with whatever change was made in mail () since 5.2.1, it crashes the httpd. It's curious that httpd is dying via signal 6 (SIGABRT, abort()) and not a usual segv or bus error, etc. [2007-02-21 21:53:48] [EMAIL PROTECTED] Doesn't look like PHP problem to me, more like FreeBSD bug. [2007-02-21 21:20:32] brlcad at mac dot com To hopefully revive this issue, I'm using the latest release 5.2.1 version of php (from FreeBSD ports), with the same setup and constraints as mentioned before in this report and still see the same crashes (httpd exits on signal 6) during a mail() call from mod_php5. 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/37120 -- Edit this bug report at http://bugs.php.net/?id=37120&edit=1
#40589 [Opn]: mysqli can't handle a reconnect, crashes
ID: 40589 User updated by: pegasus at nerv dot eu dot org Reported By: pegasus at nerv dot eu dot org Status: Open Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.2.1 New Comment: Forgot to mention that this only happens when using prepared statements. Previous Comments: [2007-02-22 08:55:01] pegasus at nerv dot eu dot org Description: If you set mysql timeouts (in my.cnf) to some short times, like: set-variable = connect_timeout=3 set-variable = interactive_timeout=5 set-variable = wait_timeout=10 And then have a script, that opens mysql connection via mysqli, sleeps for 20 seconds and then tries to do something with that connection, php crashes. Reproduce code: --- Simple enough to reproduce from the comment above Actual result: -- Segfault: #0 0xb7638542 in net_clear () from /usr/lib/./libmysqlclient.so.15 #1 0xb7613df3 in cli_stmt_execute () from /usr/lib/./libmysqlclient.so.15 #2 0xb76142b3 in mysql_stmt_execute () from /usr/lib/./libmysqlclient.so.15 #3 0x081e806c in zif_mysqli_stmt_execute () #4 0x0842a8ea in execute () #5 0x0842ada6 in execute () #6 0x0842a516 in execute () #7 0x0840c9da in zend_execute_scripts () #8 0x083ca2f4 in php_execute_script () #9 0x0846c701 in main () -- Edit this bug report at http://bugs.php.net/?id=40589&edit=1
#40571 [Fbk->Csd]: FastCGI ignores GET-parameters
ID: 40571
Updated by: [EMAIL PROTECTED]
Reported By: demiurg at gmail dot com
-Status: Feedback
+Status: Closed
Bug Type: CGI related
Operating System: Linux
PHP Version: 6CVS-2007-02-21 (CVS)
Previous Comments:
[2007-02-21 08:35:01] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php6.0-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php6.0-win32-latest.zip
[2007-02-21 01:43:15] demiurg at gmail dot com
Description:
This problem has already been reported with #39370
PHP installed as a standalone FastCGI server, completely ignores all
GET parameters passed to a script.
Please, correct a typo at sapi/cgi/cgi_main.c:936
There should be sizeof("QUERY_STRING")
not sizeof("REQUEST_METHOD").
--
Edit this bug report at http://bugs.php.net/?id=40571&edit=1
#40589 [NEW]: mysqli can't handle a reconnect, crashes
From: pegasus at nerv dot eu dot org Operating system: Linux PHP version: 5.2.1 PHP Bug Type: Reproducible crash Bug description: mysqli can't handle a reconnect, crashes Description: If you set mysql timeouts (in my.cnf) to some short times, like: set-variable = connect_timeout=3 set-variable = interactive_timeout=5 set-variable = wait_timeout=10 And then have a script, that opens mysql connection via mysqli, sleeps for 20 seconds and then tries to do something with that connection, php crashes. Reproduce code: --- Simple enough to reproduce from the comment above Actual result: -- Segfault: #0 0xb7638542 in net_clear () from /usr/lib/./libmysqlclient.so.15 #1 0xb7613df3 in cli_stmt_execute () from /usr/lib/./libmysqlclient.so.15 #2 0xb76142b3 in mysql_stmt_execute () from /usr/lib/./libmysqlclient.so.15 #3 0x081e806c in zif_mysqli_stmt_execute () #4 0x0842a8ea in execute () #5 0x0842ada6 in execute () #6 0x0842a516 in execute () #7 0x0840c9da in zend_execute_scripts () #8 0x083ca2f4 in php_execute_script () #9 0x0846c701 in main () -- Edit bug report at http://bugs.php.net/?id=40589&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40589&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40589&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40589&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40589&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40589&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40589&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40589&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40589&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40589&r=support Expected behavior:http://bugs.php.net/fix.php?id=40589&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40589&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40589&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40589&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40589&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40589&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40589&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40589&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40589&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40589&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40589&r=mysqlcfg
#40567 [Bgs->Opn]: DOMDocument->createElement()
ID: 40567
User updated by: bpipe at mail dot ru
Reported By: bpipe at mail dot ru
-Status: Bogus
+Status: Open
Bug Type:Feature/Change Request
PHP Version: 5.2.1
New Comment:
I; not sayng this is bug, i marked this as feature request
Previous Comments:
[2007-02-22 08:28:41] bpipe at mail dot ru
"element names are already validated and cause an error to be issued.
The
":" char is a valid character in an element name"
Yes ":" is valid character for element name, i'm not sayng that you
shouldn't allow to use it i'm sayng that you should generate a notice
about it, it;s lika casting float value to int value in C++ (cimpiler
generate a notice about possible loss of data), same here, when user
creates Element with ":" after document is saved the reslut will be not
what he expect (this is lost of data) the part before ":" becomes
NameSpace.
[2007-02-21 17:16:17] [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
element names are already validated and cause an error to be issued.
The ":" char is a valid character in an element name
[2007-02-20 22:07:26] bpipe at mail dot ru
Description:
DomDocument->CreateElement()
I have a feature request, i think you should add a waring or notice
when someone is calling CreateElement with ':' in node name.
Like this one:
$xsl->createElement('xsl:import');
instead of CreateElementNS, because this problem is hard to detect
(document look like it should when you output it)
I made this mistake myself and it took me 2 days to find out the
problem, and only when i found the problem i managed to find any
information about this in bugzilla.
A notice when you create XML node with ':' in name could save 2 days of
my life )
Really very hard to detect this mistake, i was googling, sitting in IRC
and asking everyone for 48 hours without any result. And i think I'm not
alone who "stepped on this rake"
--
Edit this bug report at http://bugs.php.net/?id=40567&edit=1
#40567 [Bgs]: DOMDocument->createElement()
ID: 40567
User updated by: bpipe at mail dot ru
Reported By: bpipe at mail dot ru
Status: Bogus
Bug Type:Feature/Change Request
PHP Version: 5.2.1
New Comment:
"element names are already validated and cause an error to be issued.
The
":" char is a valid character in an element name"
Yes ":" is valid character for element name, i'm not sayng that you
shouldn't allow to use it i'm sayng that you should generate a notice
about it, it;s lika casting float value to int value in C++ (cimpiler
generate a notice about possible loss of data), same here, when user
creates Element with ":" after document is saved the reslut will be not
what he expect (this is lost of data) the part before ":" becomes
NameSpace.
Previous Comments:
[2007-02-21 17:16:17] [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
element names are already validated and cause an error to be issued.
The ":" char is a valid character in an element name
[2007-02-20 22:07:26] bpipe at mail dot ru
Description:
DomDocument->CreateElement()
I have a feature request, i think you should add a waring or notice
when someone is calling CreateElement with ':' in node name.
Like this one:
$xsl->createElement('xsl:import');
instead of CreateElementNS, because this problem is hard to detect
(document look like it should when you output it)
I made this mistake myself and it took me 2 days to find out the
problem, and only when i found the problem i managed to find any
information about this in bugzilla.
A notice when you create XML node with ':' in name could save 2 days of
my life )
Really very hard to detect this mistake, i was googling, sitting in IRC
and asking everyone for 48 hours without any result. And i think I'm not
alone who "stepped on this rake"
--
Edit this bug report at http://bugs.php.net/?id=40567&edit=1
