Bug #60598 [Com]: cli/apache sapi segfault on objects manipulation
Edit report at https://bugs.php.net/bug.php?id=60598&edit=1 ID: 60598 Comment by: andre at roaldseth dot net Reported by:arekm at maven dot pl Summary:cli/apache sapi segfault on objects manipulation Status: Feedback Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.4.0RC3 Block user comment: N Private report: N New Comment: Applied the patch and confirmed that the test script now works as expected. Previous Comments: [2013-08-29 11:40:06] manuel-php at mausz dot at works [2013-08-29 11:11:05] larue...@php.net I made a patch, could you please verify it? thanks [2013-08-29 11:09:44] larue...@php.net The following patch has been added/updated: Patch Name: bug60598 Revision: 134584 URL: https://bugs.php.net/patch-display.php?bug=60598&patch=bug60598&revision=134584 [2013-08-28 13:25:45] manuel-php at mausz dot at Still the same with 5.4.19 # php -n test.php If you see this, try to increase OBJECT_COUNT to 100,000Segmentation fault [2013-08-28 13:05:43] ras...@php.net Please try again with 5.4.19. There were some fixes related to this applied in 5.4.18. 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 https://bugs.php.net/bug.php?id=60598 -- Edit this bug report at https://bugs.php.net/bug.php?id=60598&edit=1
Req #49790 [Com]: mb_substr_count and substr_count do not have the same definition
Edit report at https://bugs.php.net/bug.php?id=49790&edit=1 ID: 49790 Comment by: andre at koethur dot de Reported by:pg dot millon at gmail dot com Summary:mb_substr_count and substr_count do not have the same definition Status: Open Type: Feature/Change Request Package:mbstring related Operating System: Ubuntu PHP Version:5.2.11 Block user comment: N Private report: N New Comment: Without the offset parameter, this function is quite useless, because it will behave exact like a binary safe substr_count() with $offset=0. In other words; There is only a need for a multi byte aware substr_count when $offset > 0 ⦠Previous Comments: [2013-03-19 13:07:47] neggelandia at gmail dot com The problem goes deeper. substr_count() takes 4 parameters while mb_substr_count() only takes three (and the third doens't even have the same meaning), which produces errors such as this: mb_substr_count() expects at most 3 parameters, 4 given This makes the mbstring.func_overload configuration parameter misbehave. [2009-10-06 15:52:02] pg dot millon at gmail dot com Description: I'm using the mbstring_funcoverload property defined to 7 which allows the overload of every functions. While using the function substr_count with the 3 parameter (offset) defined. As overloading is activated, calling substr_count is equivalent to calling mb_substr_count but the offset parameter does not exists for this function Reproduce code: --- In php.ini: mbstring.func_overload 7 $var = substr_count('/some/path', DIRECTORY_SEPARATOR, 0); Expected result: 1 Actual result: -- Warning: mb_substr_count(): Unknown encoding "0" in php shell code on line 1 Call Stack: 6.0376 46516 1. {main}() php shell code:0 6.0376 46648 2. mb_substr_count() php shell code:1 -- Edit this bug report at https://bugs.php.net/bug.php?id=49790&edit=1
[PHP-BUG] Bug #64708 [NEW]: apc_store() in CLI with apc.enable_cli=0 segfaults.
From: andre at roaldseth dot net Operating system: Linux PHP version: 5.4.14 Package: Reproducible crash Bug Type: Bug Bug description:apc_store() in CLI with apc.enable_cli=0 segfaults. Description: CentOS 6.4 with php-pecl-apcu.x86_64 from remi repo. It crashes consistently on apc_store() if apc.enable_cli=0. Test script: --- var_dump(apc_store("foo", "bar")); Expected result: It should result in true. Actual result: -- It segfaults. andrer@vg-dev-01:~/VGF (/trunk)$ gdb --args php -r 'apc_store("foo", "bar");' GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/php...(no debugging symbols found)...done. Missing separate debuginfos, use: debuginfo-install php-cli-5.4.14- 1.el6.remi.x86_64 (gdb) run Starting program: /usr/bin/php -r apc_store\(\"foo\",\ \"bar\"\)\; [Thread debugging using libthread_db enabled] [New Thread 0x7fffdef53700 (LWP 18656)] [Thread 0x7fffdef53700 (LWP 18656) exited] Program received signal SIGSEGV, Segmentation fault. 0x7fffedb2b691 in apc_cache_serializer () from /usr/lib64/php/modules/apcu.so (gdb) thread apply all backtrace Thread 1 (Thread 0x77fe17e0 (LWP 18637)): #0 0x7fffedb2b691 in apc_cache_serializer () from /usr/lib64/php/modules/apcu.so #1 0x7fffedb2ab44 in ?? () from /usr/lib64/php/modules/apcu.so #2 0x0065bfcc in ?? () #3 0x006497d8 in execute () #4 0x005d2d1e in zend_eval_stringl () #5 0x005d2df9 in zend_eval_stringl_ex () #6 0x0068ad44 in ?? () #7 0x0068b768 in ?? () #8 0x74f0ccdd in __libc_start_main () from /lib64/libc.so.6 #9 0x00423f89 in _start () -- Edit bug report at https://bugs.php.net/bug.php?id=64708&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64708&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64708&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64708&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64708&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64708&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64708&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64708&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64708&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64708&r=support Expected behavior: https://bugs.php.net/fix.php?id=64708&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64708&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64708&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64708&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64708&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64708&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64708&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64708&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64708&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64708&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64708&r=mysqlcfg
Bug #62393 [Com]: __callStatic from a derived class object context calls __call instead
Edit report at https://bugs.php.net/bug.php?id=62393&edit=1 ID: 62393 Comment by: andre-desch at t-online dot de Reported by:andre-desch at t-online dot de Summary:__callStatic from a derived class object context calls __call instead Status: Not a bug Type: Bug Package:Reflection related Operating System: Windows 7 Prof. PHP Version:5.4.4 Block user comment: N Private report: N New Comment: It is a static call if You use an empty proxy class like below. The only difference in scope is, that MyProxyClass is not directly in the hierachy tree above the calling method's class. Please explain why this is intended. class MyProxyClass extends MyBaseClass { //empty } class MyDerivedClass extends MyBaseClass { function someAction() { return MyProxyClass::Foo(); } } Previous Comments: [2012-06-23 06:39:49] larue...@php.net if there is a calling scope, then :: is not a static call. if there is no calling scope, then :: is a static call. the key point is the calling scope, not the "::" . thanks [2012-06-22 14:46:00] cataphr...@php.net > The test code is calling MyBaseClass::Foo(), which clearly is a static call. You are mistaken. MyBaseClass::Foo() is not necessarily a static call. Namely, if $this is of type MyBaseClass or a subclass thereof and there's no explicit static method MyBaseClass::Foo(), then MyBaseClass::Foo() is an instance call. [2012-06-22 11:57:35] john dot papaioannou at gmail dot com Excuse me, but how exactly does parent::Foo() come into the discussion? The test code is calling MyBaseClass::Foo(), which clearly is a static call. [2012-06-22 11:15:16] johan...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is due to the way calls to parent::foo() and such are handled, these look like static calls but in fact aren't. ---- [2012-06-22 10:04:14] andre-desch at t-online dot de Description: If You define both the magic function for static and dynamic calls for a class and then call a static function from a derivate's method, not the static but the dynamic magic function is called. Test script: --- someAction(); ?> Expected result: static call Actual result: -- dynamic call -- Edit this bug report at https://bugs.php.net/bug.php?id=62393&edit=1
[PHP-BUG] Bug #62393 [NEW]: __callStatic from a derived class object context calls __call instead
From: andre-desch at t-online dot de Operating system: Windows 7 Prof. PHP version: 5.4.4 Package: Reflection related Bug Type: Bug Bug description:__callStatic from a derived class object context calls __call instead Description: If You define both the magic function for static and dynamic calls for a class and then call a static function from a derivate's method, not the static but the dynamic magic function is called. Test script: --- someAction(); ?> Expected result: static call Actual result: -- dynamic call -- Edit bug report at https://bugs.php.net/bug.php?id=62393&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62393&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62393&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62393&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62393&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62393&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62393&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62393&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62393&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62393&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62393&r=support Expected behavior: https://bugs.php.net/fix.php?id=62393&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62393&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62393&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62393&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62393&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62393&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62393&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62393&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62393&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62393&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62393&r=mysqlcfg
[PHP-BUG] Bug #61502 [NEW]: pdo_oci persistent connections broken with Oracle 9.2 servers
From: Operating system: Ubuntu 12.04 PHP version: 5.4.0 Package: PDO related Bug Type: Bug Bug description:pdo_oci persistent connections broken with Oracle 9.2 servers Description: I've only verified this in PHP 5.3.10, but I checked that the relevant code has not changed in git/master. Enabling persistent connection to Oracle 9.2 servers does not work. The server seem to brutally kill the connection on OCIPing, a function the code in ext/pdo/oci_driver.c:pdo_oci_check_liveness() assumes will fail gracefully on older Oracle versions. This makes the error_code == 1010 check fail and it will (now correctly) re-connect to the server, saving the day by not failing in a user-visible way, but however rendering persistent connections to 9.2 servers useless and adding ~900ms of extra latency (in our case). I tried extending the check to the resulting 3113 (end-of-file on communication channel) error, but it turned out the connection really is dead at that point. Is there really any downside to just using OCIServerVersion instead of OCIPing? Test script: --- PDO::ERRMODE_EXCEPTION, PDO::ATTR_PERSISTENT => true) ); ?> Expected result: connections not beeing re-established (source port numbers in netstat -anp not changing) Actual result: -- connections beeing re-established (source port numbers in netstat -anp changing), incurring a large latency penalty. -- Edit bug report at https://bugs.php.net/bug.php?id=61502&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61502&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61502&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61502&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61502&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61502&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61502&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61502&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61502&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61502&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61502&r=support Expected behavior: https://bugs.php.net/fix.php?id=61502&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61502&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61502&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61502&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61502&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61502&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61502&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61502&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61502&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61502&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61502&r=mysqlcfg
Bug #55447 [Opn]: Global constant declared as const parsed as class constant with token_get_all()
Edit report at https://bugs.php.net/bug.php?id=55447&edit=1 ID: 55447 User updated by:andre at neo-anime dot org Reported by:andre at neo-anime dot org Summary:Global constant declared as const parsed as class constant with token_get_all() Status: Open Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.3SVN-2011-08-18 (SVN) Block user comment: N Private report: N New Comment: Test script should be https://bugs.php.net/bug.php?id=55447&edit=1
[PHP-BUG] Bug #55447 [NEW]: Global constant declared as const parsed as class constant with token_get_all()
From: Operating system: Linux PHP version: 5.3SVN-2011-08-18 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:Global constant declared as const parsed as class constant with token_get_all() Description: As of PHP 5.3.0 global constants can be declared using the const keyword in addition to the define() function. However token_get_all() incorrectly recognizes the former as a class constant. Test script: --- https://bugs.php.net/bug.php?id=55447&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55447&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55447&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55447&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55447&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55447&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55447&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55447&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55447&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55447&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55447&r=support Expected behavior: https://bugs.php.net/fix.php?id=55447&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55447&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55447&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55447&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55447&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55447&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55447&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55447&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55447&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55447&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55447&r=mysqlcfg
Bug #55132 [Bgs]: String access to an expression gives parse error
Edit report at https://bugs.php.net/bug.php?id=55132&edit=1 ID: 55132 User updated by:andre at webkr dot de Reported by:andre at webkr dot de Summary:String access to an expression gives parse error Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: Windows 7 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I double-checked the manual, there it says: "Characters within strings may be accessed and modified by specifying the zero-based offset of the desired character after the string using square array brackets, as in $str[42]. [...] Strings may also be accessed using braces, as in $str{42}, for the same purpose." The expression ((string)$i) obviously is a string, as confirmed by var_dump(): string(3) "123" So I don't see which part of the manual you are referring to. Previous Comments: [2011-07-04 19:01:44] fel...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The syntax (...){..} is not intended to work. ---- [2011-07-04 18:53:24] andre at webkr dot de Description: As documented, "accessing variables of other types [...] using [] or {} silently returns NULL". Because of this it is necessary to cast an integer to string before string access can be done. However, this results in a parse error. Test script: --- $i = 123; echo $i{1}; // -> empty (expected) echo ((string)$i){1}; // -> parse error -- Edit this bug report at https://bugs.php.net/bug.php?id=55132&edit=1
[PHP-BUG] Bug #55132 [NEW]: String access to an expression gives parse error
From: Operating system: Windows 7 PHP version: 5.3.6 Package: Scripting Engine problem Bug Type: Bug Bug description:String access to an expression gives parse error Description: As documented, "accessing variables of other types [...] using [] or {} silently returns NULL". Because of this it is necessary to cast an integer to string before string access can be done. However, this results in a parse error. Test script: --- $i = 123; echo $i{1}; // -> empty (expected) echo ((string)$i){1}; // -> parse error -- Edit bug report at https://bugs.php.net/bug.php?id=55132&edit=1 -- Try a snapshot (PHP 5.2): https://bugs.php.net/fix.php?id=55132&r=trysnapshot52 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55132&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55132&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55132&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55132&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55132&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55132&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55132&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55132&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55132&r=support Expected behavior: https://bugs.php.net/fix.php?id=55132&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55132&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55132&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55132&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55132&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55132&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55132&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55132&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55132&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55132&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55132&r=mysqlcfg Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55132&r=trysnapshot54
Bug #53848 [Opn]: fgetcsv ignores spaces at beginnings of fields
Edit report at http://bugs.php.net/bug.php?id=53848&edit=1 ID: 53848 User updated by:andre at webkr dot de Reported by:andre at webkr dot de -Summary:fgetcsv ignores spaces on beginning of line +Summary:fgetcsv ignores spaces at beginnings of fields Status: Open Type: Bug Package:Filesystem function related Operating System: Windows 7 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Indeed, I overlooked that. I added your data to my test (without the quotes and line break, of course) and I can confirm that issue. I changed the summary accordingly. Previous Comments: [2011-04-15 19:49:51] mark dot mccray at tbwachiat dot com Same issue on Mac OS X 10.6.7 running PHP ver 5.3.4. [2011-04-15 19:40:41] mark dot mccray at tbwachiat dot com Forgot to add that we are on hp-ux 11.11i. Php ver 5.2.4. [2011-04-15 19:40:08] mark dot mccray at tbwachiat dot com I'm posting a comment here instead of a bug because I feel we may be encountering the same issue. My problem is that fgetcsv seems to trim whitespace at the beginning of any field -- not just at the beginning of a record. In a record (our files are separated by a pipe symbol): "001|5964_154|OGLCV|003| 174699|USD|0326049|Corporation||00|11/03/27||11/04/14|1|MPY||CP" The field " 174699" gets inserted into the array as "174699". We are expecting the leading whitespace to not be trimmed. [2011-02-11 14:50:52] phillip at grueter-online dot de Same problem in version 5.2.10 shell > php --version PHP 5.2.10-2ubuntu6.5 php > var_dump(file("csvtest.csv")); array(3) { [0]=> string(4) "a,b " [1]=> string(5) " c,d " [2]=> string(1) " " } php > $handle = fopen("csvtest.csv", "r"); php > $a = fgetcsv($handle); php > var_dump($a); array(2) { [0]=> string(1) "a" [1]=> string(1) "b" } php > $a = fgetcsv($handle); php > var_dump($a); array(2) { [0]=> string(1) "c" [1]=> string(1) "d" } [2011-01-26 13:49:48] andre at webkr dot de Description: RFC4180 says: "Spaces are considered part of a field and should not be ignored." However (despite being the only CSV parsing function that fulfils all other requirements), fgetcsv ignores spaces at the very beginning of a record. Test script: --- /* Put this in a file: a,b c,d */ $fd = fopen('the_file','r'); $a = fgetcsv($fd); Expected result: array( array('a', 'b'), array(' c','d') ) Actual result: -- array( array('a', 'b'), array('c','d') ) -- Edit this bug report at http://bugs.php.net/bug.php?id=53848&edit=1
[PHP-BUG] Bug #53848 [NEW]: fgetcsv ignores spaces on beginning of line
From: Operating system: Windows 7 PHP version: 5.3.5 Package: Filesystem function related Bug Type: Bug Bug description:fgetcsv ignores spaces on beginning of line Description: RFC4180 says: "Spaces are considered part of a field and should not be ignored." However (despite being the only CSV parsing function that fulfils all other requirements), fgetcsv ignores spaces at the very beginning of a record. Test script: --- /* Put this in a file: a,b c,d */ $fd = fopen('the_file','r'); $a = fgetcsv($fd); Expected result: array( array('a', 'b'), array(' c','d') ) Actual result: -- array( array('a', 'b'), array('c','d') ) -- Edit bug report at http://bugs.php.net/bug.php?id=53848&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53848&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53848&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53848&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53848&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53848&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53848&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53848&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53848&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53848&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53848&r=support Expected behavior: http://bugs.php.net/fix.php?id=53848&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53848&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53848&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53848&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53848&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53848&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53848&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53848&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53848&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53848&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53848&r=mysqlcfg
Bug #52987 [Com]: Losing amperstamp with xml_parse_into_struct function
Edit report at http://bugs.php.net/bug.php?id=52987&edit=1 ID: 52987 Comment by: andre dot boily at mcccf dot gouv dot qc dot ca Reported by:andre dot boily at mcccf dot gouv dot qc dot ca Summary:Losing amperstamp with xml_parse_into_struct function Status: Feedback Type: Bug Package:XML related Operating System: Linux - SUSE PHP Version:5.2.14 Block user comment: N New Comment: I saw in the snapshot you've send me, the BUG is corrected in version 2.5.15. - Fixed bug #45996 (libxml2 2.7 causes breakage with character data in xml_parse()). (Rob) Thanx! Previous Comments: [2010-10-07 04:13:02] ahar...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works as expected for me on a current 5.2 build: the relevant bit of output is: [3]=> array(4) { ["tag"]=> string(3) "URL" ["type"]=> string(8) "complete" ["level"]=> int(3) ["value"]=> string(37) "http://www.test.com?param1=1¶m2=2"; } Note the decoded ampersand in the value. ---- [2010-10-04 22:05:58] andre dot boily at mcccf dot gouv dot qc dot ca Description: Running version: 5.2.14 After a lot of tests and reading, I experimenting a problem since we've upgraded the PHP version from 5.2.6 to 5.2.14 The problem is when i'm trying to put a xml string in a array, i'm loosing the amperstamp (&)characters in the output of xml_parse_into_struct function. Maybe it's a new features that I can't understand, but it look like a Bug. Note: The Bug is in the URL tag in my XML structure. Test script: --- Some Titlehttp://www.test.com?param1=1¶m2=21285352820"; xml_parse_into_struct( $parser, $data, $xmlValues, $xmlIndex ); var_dump($xmlValues); ?> Expected result: array(6) { [0]=> array(3) { ["tag"]=> string(10) "COLLECTION" ["type"]=> string(4) "open" ["level"]=> int(1) } [1]=> array(3) { ["tag"]=> string(8) "DOCUMENT" ["type"]=> string(4) "open" ["level"]=> int(2) } [2]=> array(4) { ["tag"]=> string(5) "TITRE" ["type"]=> string(8) "complete" ["level"]=> int(3) ["value"]=> string(10) "Some Title" } [3]=> array(4) { ["tag"]=> string(3) "URL" ["type"]=> string(8) "complete" ["level"]=> int(3) ["value"]=> string(36) "http://www.test.com?param1=1¶m2=2"; } [4]=> array(3) { ["tag"]=> string(8) "DOCUMENT" ["type"]=> string(5) "close" ["level"]=> int(2) } [5]=> array(3) { ["tag"]=> string(10) "COLLECTION" ["type"]=> string(5) "close" ["level"]=> int(1) } } Actual result: -- array(6) { [0]=> array(3) { ["tag"]=> string(10) "COLLECTION" ["type"]=> string(4) "open" ["level"]=> int(1) } [1]=> array(3) { ["tag"]=> string(8) "DOCUMENT" ["type"]=> string(4) "open" ["level"]=> int(2) } [2]=> array(4) { ["tag"]=> string(5) "TITRE" ["type"]=> string(8) "complete" ["level"]=> int(3) ["value"]=> string(10) "Some Title" } [3]=> array(4) { ["tag"]=> string(3) "URL" ["type"]=> string(8) "complete" ["level"]=> int(3) ["value"]=> string(36) "http://www.test.com?param1=1param2=2"; } [4]=> array(3) { ["tag"]=> string(8) "DOCUMENT" ["type"]=> string(5) "close" ["level"]=> int(2) } [5]=> array(3) { ["tag"]=> string(10) "COLLECTION" ["type"]=> string(5) "close" ["level"]=> int(1) } } -- Edit this bug report at http://bugs.php.net/bug.php?id=52987&edit=1
#23815 [Com]: imagecopymerge doesn't respect alpha-channel in PNG-24 file
ID: 23815 Comment by: andre at webkr dot de Reported By: bjorn at smokingmedia dot com Status: Assigned Bug Type: Feature/Change Request Operating System: Linux pluto 2.4.18lvm-r1 PHP Version: 5.2.9 Assigned To: pajoye New Comment: Ah, I see. It's imagecopy() which implements alpha transparency while imagecopymerge() does not. Previous Comments: [2009-12-10 18:23:20] andre at webkr dot de So what does the "it implements alpha transparency for true colour images" in "When pct = 0, no action is taken, when 100 this function behaves identically to imagecopy() for pallete images, while it implements alpha transparency for true colour images." mean anyway? [2009-07-20 12:10:43] steve at redmonkey dot org Thanks, understood. Although, I do think it would be a useful feature, perhaps there's scope for an 'imagecopymergealpha' type function in the future? [2009-07-20 08:43:04] paj...@php.net imagecopymerge was not meant to support the alpha channel but to emulate it via pct. It was also not meant to use both the alpha or the pct value to blend an image over another. [2009-07-20 05:44:49] steve at redmonkey dot org To make life a little easier I've put the notes and examples together on a simple web page at http://www.redmonkey.org/php-bug-23815/ After investigating the code base a little further I've realised my patch solution can be made more efficient as there is no need to make a copy of the source or pass the image over to gdImageCopy once the new alpha level has been set as we've already done the all the work and can simply set the pixels RGBA index within the second image scan. The revised patch (which is also available from a link on the web page) is as follows --- php-5.3.0/ext/gd/libgd/gd.c 2009-05-27 08:17:54.0 +0100 +++ php-5.3.0-build/ext/gd/libgd/gd.c 2009-07-20 05:54:21.709936176 +0100 @@ -2255,6 +2255,67 @@ int ncR, ncG, ncB; toy = dstY; + if (pct == 100) { + /* no opacity adjustment required pass through to gdImageCopy() */ + gdImageCopy(dst, src, dstX, dstY, srcX, srcY, w, h); + return; + } + + if (pct == 0) { + /* 0% opacity? nothing needs to be done */ + return; + } + + if (src->trueColor && dst->trueColor) { + /* support for maintaining the alpha (transparency) of both source and +* destination images (assuming they are true colour) while opacity blending. +*/ + int ca, cr, cg, cb; + float na; + float ac; + + /* we need to loop through the src image to get the max transparency level */ + int mt = 0; + + for (y = 0; y < h; y++) { + for (x = 0; x < w; x++) { + c = gdImageGetTrueColorPixel (src, srcX + x, srcY + y); + ca = gdImageAlpha(src, c); + + mt = ca > mt ? ca : mt; + } + } + + /* src has no transparency? set to use full alpha range */ + mt = mt == gdAlphaOpaque ? gdAlphaMax : mt; + + /* alpha correction factor */ + ac = (float)mt / gdAlphaMax; + + /* loop through the image again and set/adjust alpha channel level */ + for (y = 0; y < h; y++) { + for (x = 0; x < w; x++) { + c = gdImageGetTrueColorPixel (src, srcX + x, srcY + y); + ca = gdImageAlpha(src, c); + cr = gdImageRed(src, c); + cg = gdImageGreen(src, c); + cb = gdImageBlue(src, c); + + na = (ca + gdAlphaMax - (gdAlphaMax * ((float)pct / 100))) * ac; + na = (na > gdAlphaMax)? gdAlphaMax : ((na < gdAlphaOpaque)? gdAlphaOpaque: na); + + int nc = gdImageColorAllocateAlpha(src, cr, cg, cb, (int)na); + if (nc == -1) { + gdImageColorClosestAlpha(src, cr, cg, cb, (int)na); + } + + gdImageSetPixel (dst, dstX + x, dstY + y, nc); + } + } + + return; + } + for (y = srcY; y < (s
#23815 [Com]: imagecopymerge doesn't respect alpha-channel in PNG-24 file
ID: 23815 Comment by: andre at webkr dot de Reported By: bjorn at smokingmedia dot com Status: Assigned Bug Type: Feature/Change Request Operating System: Linux pluto 2.4.18lvm-r1 PHP Version: 5.2.9 Assigned To: pajoye New Comment: So what does the "it implements alpha transparency for true colour images" in "When pct = 0, no action is taken, when 100 this function behaves identically to imagecopy() for pallete images, while it implements alpha transparency for true colour images." mean anyway? Previous Comments: [2009-07-20 12:10:43] steve at redmonkey dot org Thanks, understood. Although, I do think it would be a useful feature, perhaps there's scope for an 'imagecopymergealpha' type function in the future? [2009-07-20 08:43:04] paj...@php.net imagecopymerge was not meant to support the alpha channel but to emulate it via pct. It was also not meant to use both the alpha or the pct value to blend an image over another. [2009-07-20 05:44:49] steve at redmonkey dot org To make life a little easier I've put the notes and examples together on a simple web page at http://www.redmonkey.org/php-bug-23815/ After investigating the code base a little further I've realised my patch solution can be made more efficient as there is no need to make a copy of the source or pass the image over to gdImageCopy once the new alpha level has been set as we've already done the all the work and can simply set the pixels RGBA index within the second image scan. The revised patch (which is also available from a link on the web page) is as follows --- php-5.3.0/ext/gd/libgd/gd.c 2009-05-27 08:17:54.0 +0100 +++ php-5.3.0-build/ext/gd/libgd/gd.c 2009-07-20 05:54:21.709936176 +0100 @@ -2255,6 +2255,67 @@ int ncR, ncG, ncB; toy = dstY; + if (pct == 100) { + /* no opacity adjustment required pass through to gdImageCopy() */ + gdImageCopy(dst, src, dstX, dstY, srcX, srcY, w, h); + return; + } + + if (pct == 0) { + /* 0% opacity? nothing needs to be done */ + return; + } + + if (src->trueColor && dst->trueColor) { + /* support for maintaining the alpha (transparency) of both source and +* destination images (assuming they are true colour) while opacity blending. +*/ + int ca, cr, cg, cb; + float na; + float ac; + + /* we need to loop through the src image to get the max transparency level */ + int mt = 0; + + for (y = 0; y < h; y++) { + for (x = 0; x < w; x++) { + c = gdImageGetTrueColorPixel (src, srcX + x, srcY + y); + ca = gdImageAlpha(src, c); + + mt = ca > mt ? ca : mt; + } + } + + /* src has no transparency? set to use full alpha range */ + mt = mt == gdAlphaOpaque ? gdAlphaMax : mt; + + /* alpha correction factor */ + ac = (float)mt / gdAlphaMax; + + /* loop through the image again and set/adjust alpha channel level */ + for (y = 0; y < h; y++) { + for (x = 0; x < w; x++) { + c = gdImageGetTrueColorPixel (src, srcX + x, srcY + y); + ca = gdImageAlpha(src, c); + cr = gdImageRed(src, c); + cg = gdImageGreen(src, c); + cb = gdImageBlue(src, c); + + na = (ca + gdAlphaMax - (gdAlphaMax * ((float)pct / 100))) * ac; + na = (na > gdAlphaMax)? gdAlphaMax : ((na < gdAlphaOpaque)? gdAlphaOpaque: na); + + int nc = gdImageColorAllocateAlpha(src, cr, cg, cb, (int)na); + if (nc == -1) { + gdImageColorClosestAlpha(src, cr, cg, cb, (int)na); + } + + gdImageSetPixel (dst, dstX + x, dstY + y, nc); + } + } + + return; + } + for (y = srcY; y < (srcY + h); y++) { tox = dstX; for (x = srcX; x < (srcX + w); x++) { [2009-07-20 01:52:43] steve dot denim at redmonkey dot org I have run into the sam
#42266 [Com]: BLOB functions do not work on 64bit systems
ID: 42266 Comment by: andre at spiceware dot co dot za Reported By: karasek at ceskyserver dot cz Status: Assigned Bug Type: InterBase related Operating System: Linux 64-bit PHP Version: 5.2.4 Assigned To: abies New Comment: I can confirm that php 5.2.1 was the last working version for BLOBS on 64 bit operating system as I have downloaded all the versions since then to check each one. I have recently compiled 5.3.0 with no joy too! Previous Comments: [2009-06-08 10:10:57] lester at lsces dot co dot uk I think we needs some proper feedback on this problem. There WAS a problem with some builds of PHP from 5.2.0 to 5.2.5 relating to how the blob ID was handled after some re-engineering of the core PHP code. This resulted in a problem which was clearly visible when running ADOdb, since it could not access the BLOB_ID. Since 5.2.6 that problem has been fixed, and I'm currently running both windows and linux x64 machineswithout the back to get around the problem. So as far as I am concerned this bug has been cleared. So where are people still seeing it and how can we recreate that view of the problem? [2009-05-21 20:35:59] mkoeditz at gmx dot de Well, i've just installed openSUSE 10.3 with php 25.2.9 and Firebird 2.1. 32 bit system. Same error. So I think there is no focus on the platform but the php version. Regards Martin [2008-09-08 14:24:17] andre at spiceware dot co dot za I compiled PHP 5.2.6 from source tar ball for Linux this last weekend and also ended up with the BLOB error. This is still a problem. [2008-08-06 17:31:41] hasul at etoscomp dot eu Hi, is this bug still open? Because BLOB is working on my system (Centos 5.2 64bit). I used php 5.2.6 from Jason Litka repo (http://www.jasonlitka.com/yum-repository/) and FirebirdSS-2.1.0.17798-0.amd64.rpm from official firebird site. [2008-05-16 07:19:43] paj...@php.net "You're maybe right, but the bug appeared in 5.2.4 while 5.2.1. works fine, something has changed in PHP, not in firebird." I meant support as in 2nd level support not for the quality of the driver :) About the handle question, it is how they do it in firebird itself. A quick search in codesearch: http://google.com/codesearch?q=lang%3Ac+typedef+FB_API_HANDLE&hl=en&btnG=Search+Code So the problem is somewhere else, but I can't help as I don't use firebird. Let wait a bit more for the maintainers answer. 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/42266 -- Edit this bug report at http://bugs.php.net/?id=42266&edit=1
#47785 [Com]: get_included_files resolves symlinks
ID: 47785 Comment by: andre at webkr dot de Reported By: andre at webkr dot de Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.9 New Comment: It's even worse: When an included file includes another file using a relative path, that is looked up in the target directory of the symlink! It should be relative to the path where the symlink resides. The only access types that should treat the symlink in a special way are unlink (it should remove the symlink, not the target file) and chmod (it should do nothing). All other access types (especially the read involved here) should see the symlink as if it were a file with the content and attributes of the target file. Previous Comments: [2009-03-26 04:04:41] andre at webkr dot de Description: When a symlink is included/required, get_included_files shows the target of the symlink. Together with Bug #46260 this makes it completely impossible to determine how the file was really called when it was included. Reproduce code: --- include('path_to/a_symlink.php'); var_dump(get_included_files()); Expected result: An array containing a string "[...]/path_to/a_symlink.php". Actual result: -- An array containing a string "[...]/some_file.php". -- Edit this bug report at http://bugs.php.net/?id=47785&edit=1
#47785 [NEW]: get_included_files resolves symlinks
From: andre at webkr dot de Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: get_included_files resolves symlinks Description: When a symlink is included/required, get_included_files shows the target of the symlink. Together with Bug #46260 this makes it completely impossible to determine how the file was really called when it was included. Reproduce code: --- include('path_to/a_symlink.php'); var_dump(get_included_files()); Expected result: An array containing a string "[...]/path_to/a_symlink.php". Actual result: -- An array containing a string "[...]/some_file.php". -- Edit bug report at http://bugs.php.net/?id=47785&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47785&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47785&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47785&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47785&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47785&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47785&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47785&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47785&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47785&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47785&r=support Expected behavior: http://bugs.php.net/fix.php?id=47785&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47785&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47785&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47785&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47785&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47785&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47785&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47785&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47785&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47785&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47785&r=mysqlcfg
#46497 [NEW]: Unable to complete network request to host
From: andre dot gadonski at gmail dot com Operating system: FreeBSD PHP version: 5.2.6 PHP Bug Type: InterBase related Bug description: Unable to complete network request to host Description: I'm using connect, the error had to be in the connect function and not in the query function. The interbase server is not on same computer as the script. The function connect should be get the connection from the previous persistent connection. Apache version: Apache 2.0 Handler Reproduce code: --- Actual result: -- object(stdClass)#3 (6) { ["USU_COD"]=> int(61) ["USU_NOME"]=> string(25) "ANDRE GADONSKI DE FREITAS" ["USU_CATEG"]=> int(0) ["USU_SENHA"]=> string(6) "" ["USU_LOGIN"]=> NULL ["USU_DOMINIO"]=> NULL } Warning: Unknown: Unable to complete network request to host "***some ip***". Error reading data from the connection. Bad file descriptor in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=46497&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46497&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46497&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46497&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46497&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46497&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46497&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46497&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46497&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46497&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46497&r=support Expected behavior: http://bugs.php.net/fix.php?id=46497&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46497&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46497&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46497&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46497&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46497&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46497&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46497&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46497&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46497&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46497&r=mysqlcfg
#33092 [Com]: Unable to complete network request to host
ID: 33092 Comment by: andre dot gadonski at gmail dot com Reported By: fabio at bs2 dot com dot br Status: No Feedback Bug Type: InterBase related Operating System: FreeBSD PHP Version: 5.0.4 New Comment: Hi... I have the same error. I'm using PHP 5.2.0 and APACHE 2.0 handler Previous Comments: [2005-05-31 01:00:03] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-05-23 22:10:12] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-05-23 19:23:19] fabio at bs2 dot com dot br I'm was wrong, the version of apache in both servers is 2.0.54. The differs is only the php version and number of users accessing the site. The server of intebase is version 6.0. I forgotten to say that the error occurs some times, is not constant. [2005-05-23 19:16:05] fabio at bs2 dot com dot br array( 'lifetime' => 0 ), 'login' => array( 'username' => 'ra', 'password' => 'senha' ), 'logout' => array( 'destroy' => false ), 'authContainers' => array( ...{Configuration of auth container}... ) ); $user = isset($_REQUEST['user']) ?$_REQUEST['user'] :''; $pass = isset($_REQUEST['pass']) ?$_REQUEST['pass'] :''; $logout = isset($_REQUEST['action']) && $_REQUEST['action'] == 'logout'; $lu = &LiveUser::singleton($conf); $lu->init($user ,$pass ,$logout); $con = ibase_pconnect(...); $res = ibase_query($con ,"SELECT * FROM table"); $row = ibase_fetch_assoc($res); var_dump($row); ?> [2005-05-23 10:28:48] [EMAIL PROTECTED] Please provide a complete reproducing script. (one that starts with ) 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/33092 -- Edit this bug report at http://bugs.php.net/?id=33092&edit=1
#42266 [Com]: BLOB functions do not work on 64bit systems
ID: 42266 Comment by: andre at spiceware dot co dot za Reported By: karasek at ceskyserver dot cz Status: Assigned Bug Type: InterBase related Operating System: Linux 64-bit PHP Version: 5.2.4 Assigned To: abies New Comment: I compiled PHP 5.2.6 from source tar ball for Linux this last weekend and also ended up with the BLOB error. This is still a problem. Previous Comments: [2008-08-06 17:31:41] hasul at etoscomp dot eu Hi, is this bug still open? Because BLOB is working on my system (Centos 5.2 64bit). I used php 5.2.6 from Jason Litka repo (http://www.jasonlitka.com/yum-repository/) and FirebirdSS-2.1.0.17798-0.amd64.rpm from official firebird site. [2008-05-16 07:19:43] [EMAIL PROTECTED] "You're maybe right, but the bug appeared in 5.2.4 while 5.2.1. works fine, something has changed in PHP, not in firebird." I meant support as in 2nd level support not for the quality of the driver :) About the handle question, it is how they do it in firebird itself. A quick search in codesearch: http://google.com/codesearch?q=lang%3Ac+typedef+FB_API_HANDLE&hl=en&btnG=Search+Code So the problem is somewhere else, but I can't help as I don't use firebird. Let wait a bit more for the maintainers answer. [2008-05-16 06:39:45] ale dot pas at tiscali dot it You're maybe right, but the bug appeared in 5.2.4 while 5.2.1. works fine, something has changed in PHP, not in firebird. [2008-05-15 09:42:35] [EMAIL PROTECTED] Let get it assigned. It will certainly help to bring some love here. > It's a pity we choose PHP for almost all of our projects, do not make > this error, choose Java, Python or Ruby you will find a better support > there. I doubt you will find better ibase support anywhere but InterBase directly. That's the main problem here, not PHP. [2008-05-15 09:35:39] ale dot pas at tiscali dot it Ok, after 10 months this bug is sill open without a comment from a developer. This clearly proves that PHP is definitely not ready for enterprise solutions. It's a pity we choose PHP for almost all of our projects, do not make this error, choose Java, Python or Ruby you will find a better support there. 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/42266 -- Edit this bug report at http://bugs.php.net/?id=42266&edit=1
#45013 [NEW]: Semaphore cannot be released under certain circumstances.
From: andre at koethur dot de Operating system: Linux PHP version: 4.4.8 PHP Bug Type: Semaphore related Bug description: Semaphore cannot be released under certain circumstances. Description: If I acqure a semaphore in one script, then it is not possible to release it in another script, even if I set "auto_release" to false. As I have found out, it has something to do with the "count" attribute of the "sysvsem_sem"-structure. This value is really only needed by the "auto_release"-functionality, so it should be safe to ignore it in php_sysvsem_semop()-function. The current cvs-version of sysvsem.c says on line 290: if (!acquire && sem_ptr->count == 0) I suggest to change it to: if (!acquire && sem_ptr->count == 0 && sem_ptr->auto_release) Reproduce code: --- First script, acquire semaphore: Second script, release semaphore: Expected result: The second script should run without errors/warnings and the semaphore should be released. Actual result: -- Warning: sem_release() [function.sem-release]: SysV semaphore 2 (key 0x965) is not currently acquired -- Edit bug report at http://bugs.php.net/?id=45013&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45013&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45013&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45013&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45013&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45013&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45013&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45013&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45013&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45013&r=support Expected behavior:http://bugs.php.net/fix.php?id=45013&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45013&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45013&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45013&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45013&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45013&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45013&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45013&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45013&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45013&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45013&r=mysqlcfg
#44552 [NEW]: $this can be overwritten by setting a reference
From: andre at webkr dot de Operating system: Tested on Windows and Linux PHP version: 5.2.5 PHP Bug Type: Feature/Change Request Bug description: $this can be overwritten by setting a reference Description: Usually $this cannot be set. But by creating a reference to $this it can. In the example the reference is created by the =& operator. The problem is also valid when passing $this to a function by reference. I think an error should be generated because both $this = 1 and $this =& $x do generate an error. Reproduce code: --- class testclass { function foo() { var_dump($this); // object(testclass)#1 (0) { } $this->bar(); var_dump($this); // object(testclass)#1 (0) { } } function bar() { $a =& $this; $a = 1; var_dump($this); // int(1) } } $b = new testclass; $b->foo(); Expected result: Fatal error: Cannot re-assign $this in eval()'d code on line 12 Actual result: -- object(testclass)#1 (0) { } int(1) object(testclass)#1 (0) { } -- Edit bug report at http://bugs.php.net/?id=44552&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44552&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44552&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44552&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44552&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44552&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44552&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44552&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44552&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44552&r=support Expected behavior:http://bugs.php.net/fix.php?id=44552&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44552&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44552&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44552&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44552&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44552&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44552&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44552&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44552&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44552&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44552&r=mysqlcfg
#44538 [NEW]: str_replace does not work for some regular expressions
From: andre dot thompson at sta dot uwi dot edu Operating system: Windows 2003 Server Standard PHP version: 5.2.5 PHP Bug Type: *Regular Expressions Bug description: str_replace does not work for some regular expressions Description: str_replace does not replace with more than one space. Reproduce code: --- $repstr = "', W"; $astring = "UPDATE Assets SET Supplier = '6', WHERE AssetID = '112'"; $update1 = str_replace($repstr, "'W", $astring); echo $update1; Expected result: UPDATE Assets SET Supplier = '6'WHERE AssetID = '112' Actual result: -- UPDATE Assets SET Supplier = '6' WHERE AssetID = '112' -- Edit bug report at http://bugs.php.net/?id=44538&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44538&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44538&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44538&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44538&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44538&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44538&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44538&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44538&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44538&r=support Expected behavior:http://bugs.php.net/fix.php?id=44538&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44538&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44538&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44538&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44538&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44538&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44538&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44538&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44538&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44538&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44538&r=mysqlcfg
#44509 [NEW]: pg_send_execute doesn't working and pg_send_query is blocking.
From: andre dot baggio at bol dot com dot br Operating system: Linux hm517 2.6.9-67.0.4.ELsmp # PHP version: 5.2.5 PHP Bug Type: PostgreSQL related Bug description: pg_send_execute doesn't working and pg_send_query is blocking. Description: PHP Version is 5.1.6 PostgreSQL(libpq) Version 8.1.6 Hi, Problem 1: In this code, the part 1 with pg_send_query() stores one record in the DB. (it's ok) the part 2 with the pg_send_prepare() and pg_send_excute() DOESN'T stores the record in the DB. Problem 2: Besides , when I use: pg_send_query($con,"select my_slow_func()"); sending a very slow query, the page takes the same time to be ready, as if it was using pg_query(). but it was supposed that will be fast; It seems that the pg_send_query is been bloking. Reproduce code: --- ///part 1 $query = "insert into teste (dt_ini,dt_fim) values ('ggg','hhh')"; $qq = pg_send_query($connrc,$query); /// part 2 $query = "insert into teste (dt_ini,dt_fim) values ('','')"; pg_send_prepare($connrc, "my_query", $query); if (!pg_connection_busy($connrc) ) pg_send_execute($connrc, "my_query"); Expected result: I expected 2 records in the database 'ggg','hhh' '','' Problem 2: the page should be ready quickly; Actual result: -- Only one record is 'ggg','hhh' Problem 2: the page takes the same time as using pg_query(); -- Edit bug report at http://bugs.php.net/?id=44509&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44509&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44509&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44509&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44509&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44509&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44509&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44509&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44509&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44509&r=support Expected behavior:http://bugs.php.net/fix.php?id=44509&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44509&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44509&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44509&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44509&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44509&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44509&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44509&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44509&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44509&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44509&r=mysqlcfg
#35780 [Fbk->Opn]: $INSTALL_ROOT confuses PEAR installer configuration
ID: 35780 User updated by: andre at tomt dot net Reported By: andre at tomt dot net -Status: Feedback +Status: Open Bug Type: *Configuration Issues Operating System: Linux (Debian sid/amd64) PHP Version: 5.1.1 New Comment: no change Previous Comments: [2005-12-22 23:18:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-12-22 22:59:12] andre at tomt dot net Description: When installing the PEAR installer and the base components as shipped in the php tarball, using INSTALL_ROOT will confuse the pear installation. INSTALL_ROOT gets prepended on the paths in the configuration (pear.conf) and in the pear binary. This breaks packaging. Reproduce code: --- ./configure make make install-pear INSTALL_ROOT=/somewhere/else/php-pear Now observe the "pear" shell script, and the pear.conf. I can't recall this used to be a problem before PHP 5.1. Expected result: Not having INSTALL_ROOT prepended in pear config and in pear command. Actual result: -- INSTALL_ROOT prepended in pear config and in pear command. -- Edit this bug report at http://bugs.php.net/?id=35780&edit=1
#35780 [NEW]: $INSTALL_ROOT confuses PEAR installer configuration
From: andre at tomt dot net Operating system: Linux (Debian sid/amd64) PHP version: 5.1.1 PHP Bug Type: *Configuration Issues Bug description: $INSTALL_ROOT confuses PEAR installer configuration Description: When installing the PEAR installer and the base components as shipped in the php tarball, using INSTALL_ROOT will confuse the pear installation. INSTALL_ROOT gets prepended on the paths in the configuration (pear.conf) and in the pear binary. This breaks packaging. Reproduce code: --- ./configure make make install-pear INSTALL_ROOT=/somewhere/else/php-pear Now observe the "pear" shell script, and the pear.conf. I can't recall this used to be a problem before PHP 5.1. Expected result: Not having INSTALL_ROOT prepended in pear config and in pear command. Actual result: -- INSTALL_ROOT prepended in pear config and in pear command. -- Edit bug report at http://bugs.php.net/?id=35780&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35780&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35780&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35780&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35780&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35780&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35780&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35780&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35780&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35780&r=support Expected behavior:http://bugs.php.net/fix.php?id=35780&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35780&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35780&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35780&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35780&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35780&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35780&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35780&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35780&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35780&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35780&r=mysqlcfg
#32351 [NEW]: Problems with freetds and mssql
From: andre at softexpert dot com Operating system: Fedora Core 3 PHP version: 4CVS-2005-03-17 (stable) PHP Bug Type: Compile Failure Bug description: Problems with freetds and mssql Description: In file included from /usr/local/freetds/include/sybfront.h:23, from /usr/local/freetds/include/sqlfront.h:23, from /root/install/php4/ext/mssql/php_mssql.h:34, from main/internal_functions.c:39: /usr/local/freetds/include/sybdb.h:118: error: redefinition of typedef 'USHORT' /opt/firebird/include/ibase.h:101: error: previous declaration of 'USHORT' was here /usr/local/freetds/include/sybdb.h:165: error: redefinition of typedef 'BYTE' /opt/firebird/include/ibase.h:156: error: previous declaration of 'BYTE' was here make: ** [main/internal_functions.lo] Erro 1 ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mssql=/usr/local/freetds --with-zlib-dir=/usr/lib --with-interbase=/opt/firebird --with-gd --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-mhash=/usr/local/mhash --with-dom --enable-bcmath --enable-dba=shared --with-db4=/usr/include/db4 Freetds Version: the last stable -- Edit bug report at http://bugs.php.net/?id=32351&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32351&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32351&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32351&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32351&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32351&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32351&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32351&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32351&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32351&r=support Expected behavior: http://bugs.php.net/fix.php?id=32351&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32351&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32351&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32351&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32351&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32351&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32351&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32351&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32351&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32351&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32351&r=mysqlcfg
#32342 [NEW]: Problems compiling with support to zlib
From: andre at softexpert dot com Operating system: Fedora Core 3 PHP version: 4CVS-2005-03-16 (stable) PHP Bug Type: Compile Failure Bug description: Problems compiling with support to zlib Description: ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mssql=/usr/local/freetds/ --with-zlib-dir=/usr/lib --with-interbase=/opt/firebird --with-gd --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-mhash=/usr/local/mhash --with-dom --enable-bcmath --enable-dba=shared --with-db4=/usr/include/db4 php4-STABLE-200503161530/Zend/../TSRM/TSRM.h:18:26: tsrm_config.h: No such file or directory In file included from /root/install/php4-STABLE-200503161530/ext/zlib/zlib.c:28: /root/install/php4-STABLE-200503161530/main/php.h:393:30: tsrm_virtual_cwd.h: No such file or directory make: ** [ext/zlib/zlib.lo] Erro 1 -- Edit bug report at http://bugs.php.net/?id=32342&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32342&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32342&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32342&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32342&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32342&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32342&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32342&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32342&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32342&r=support Expected behavior: http://bugs.php.net/fix.php?id=32342&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32342&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32342&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32342&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32342&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32342&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32342&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32342&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32342&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32342&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32342&r=mysqlcfg
#30368 [Bgs]: is_dir() return true after rmdir()
ID: 30368 User updated by: andre dot steffens at adress-research dot de Reported By: andre dot steffens at adress-research dot de Status: Bogus Bug Type: Directory function related Operating System: Win2k PHP Version: 4.3.9 New Comment: I think that after some file/dir functions the stat cache should be clean automatically. like: rmdir(); unlink(); ... all functions that alter files or dirs ... Previous Comments: [2004-10-08 18:30:04] [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 Expected behaviour, read about clearstatcache(); [2004-10-08 18:20:45] andre dot steffens at adress-research dot de Description: is_dir() seems to cache the last status for a given dir and don't check if it still exists. Reproduce code: --- Expected result: $err = false; Actual result: -- $err = true; -- Edit this bug report at http://bugs.php.net/?id=30368&edit=1
#30368 [NEW]: is_dir() return true after rmdir()
From: andre dot steffens at adress-research dot de Operating system: Win2k PHP version: 4.3.9 PHP Bug Type: Directory function related Bug description: is_dir() return true after rmdir() Description: is_dir() seems to cache the last status for a given dir and don't check if it still exists. Reproduce code: --- Expected result: $err = false; Actual result: -- $err = true; -- Edit bug report at http://bugs.php.net/?id=30368&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30368&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30368&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30368&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30368&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30368&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30368&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30368&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30368&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30368&r=support Expected behavior: http://bugs.php.net/fix.php?id=30368&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30368&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30368&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30368&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30368&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30368&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30368&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30368&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30368&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30368&r=mysqlcfg
#23580 [Com]: Random values for include_path
ID: 23580 Comment by: andre at digirati dot com dot br Reported By: maximiliano dot marques at bol dot com dot br Status: Open Bug Type: Apache related Operating System: Conectiva Linux 8 Kernel 2.4.19 PHP Version: 4.3.3RC5-dev New Comment: We've had this problem with some customers too. Asking them to change their 'include' directives to use the full path to the files to be included solved the problem. Previous Comments: [2003-09-19 15:05:22] php at techmeridian dot com Is there any action towards a resolution of this bug? I will do just about anything to help get this bug resolved... [2003-09-03 11:08:27] php at techmeridian dot com So what can we do to help out now? I would love to help in any other way possible, but I guess we just need some direction in what and how to help now? [2003-09-01 11:28:58] [EMAIL PROTECTED] no luck, I created my own test environment but was unable to reproduce this problem. [2003-09-01 11:26:34] php at techmeridian dot com Any luck looking at the files we sent? We are looking into the code as well, but it is taking us a very long time to get into the core... Thanks [2003-08-26 23:35:15] [EMAIL PROTECTED] I got the files, thank you. 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/23580 -- Edit this bug report at http://bugs.php.net/?id=23580&edit=1
#24536 [NEW]: cloning within a try-catch block
From: andre at onestep dot nl Operating system: w2k PHP version: 5CVS-2003-07-08 (dev) PHP Bug Type: Zend Engine 2 problem Bug description: cloning within a try-catch block Description: Cloning an object within a try-catch block generates a "bad opcode in throw list" error. Reproduce code: --- class MyClass { public $foobar; } try { $a = new MyClass(); $b = $a->__clone(); } catch(Exception $exception) { echo $exception->getMessage(); } Expected result: An empty page. Actual result: -- PHP Fatal error: Bad opcode in throw list in C:\simon\production\www\test2.php on line 13 -- Edit bug report at http://bugs.php.net/?id=24536&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24536&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24536&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24536&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24536&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24536&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24536&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24536&r=support Expected behavior: http://bugs.php.net/fix.php?id=24536&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24536&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24536&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24536&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24536&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24536&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24536&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24536&r=gnused
#22533 [NEW]: problem with strtr(), 100% of CPU use
From: andre at softexpert dot com Operating system: W2k PHP version: 4.2.3 PHP Bug Type: Reproducible crash Bug description: problem with strtr(), 100% of CPU use When using strtr() passing a number as first parameter, and an array that contains ("" => "anything"), php.exe uses 100% of CPU and stays running until IIS return a CGI Time limit. Example: echo strtr(10, array("" => "a")); -- Edit bug report at http://bugs.php.net/?id=22533&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22533&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22533&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22533&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22533&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22533&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22533&r=support Expected behavior: http://bugs.php.net/fix.php?id=22533&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22533&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22533&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22533&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22533&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22533&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22533&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22533&r=gnused
#22288 [Opn]: Local vars and function parameters not accessible!
ID: 22288 User updated by: andre dot goncalves at martelozero dot com Reported By: andre dot goncalves at martelozero dot com Status: Open Bug Type: Variables related Operating System: Linux PHP Version: 4.3.1-dev New Comment: Ok, I'm sorry I didn't get any answer from you guys. The problem is solved. I don't know how, but it suddenly stoped, after I made some random and desperate changes in the code somewhere. What I will never understand is what kind of error in my code, that is not detected by PHP causes such abnormal behaviour. PHP did not return any Notice, Warning, or Error message, it simply went beserk with variables. I don't really understand much about this issues, but someone told me that the stack was getting corrupted, and to look for recursive function calls. (there were none) Anyway I think that this issue should be investigated. Not just simply say that there were "serious issues" with my code. Off course there were, but certainly not with cookies. The thing is, if there is a reason for PHP to go nuts, it should issue some kind of warning (like it normally does). Thanks anyway Keep up developing this amazing thing. Previous Comments: ---- [2003-02-19 04:40:10] andre dot goncalves at martelozero dot com What do you mean by serious issues? Maybe you don't understand the questions I made, or the absurd behaviour that I describe - or in the other hand, maybe I don't understand that some stupid error I made somewhere (with cookies you say) might cause this strange behaviour of PHP (you sound very natural about it). Well I have some serious questions: 1. What's the relation between cookies and the Empty + Unavailable + Unassignable local variables and function parameters in the method's implementation? 2. What causes the script to go crazy in terms of variable value assignment? 3. Why do local vars fail to accept values from a certain point on? 4. Hhy it only happens the first time the script runs, and why only in the second time the method is called? After a code-induced & cookie-related error, you say? 5. How does a variable echo a value that it was not assigned? Again, how does $this->tmp2 = "whatever" makes $_query = "whatever"? And why var_dump'ing ($_query) returns NULL? 6. Why $localvar = "foo", does not make $localvar = "foo", i.e., why local vars and parameters are unavailable and unassignable? Thanks [2003-02-18 23:52:01] [EMAIL PROTECTED] Your script has serious issues...it sets some cookies? It also has some errors, apparently caused by the missing cookie value? This really doesn't seem like any problem in PHP.. [2003-02-18 23:26:04] andre dot goncalves at martelozero dot com Hi! this is really a spooky situation! A. problem with a class only happening in one site (other implementations use same class and always worked fine). B. It only happens the first time I hit the site. C. press F5, or re-enter address, and the problem is gone. D. restarting browser, causes the problem again. E. problem is: The 2nd time I call a method on a certain object, neither the method parameters, neither the global vars are acessible, only the pre-declared class members are there. Remember, i have made a call to this method in the same script exexcutation, some 20 lines before. F. Even more spooky, some vars tend to echo values (wrong values) but var_dump shows NULL for the same var, right from the next line of code!!! G. Check below example: output 1, 3 and 4 show vardump of function parameters NULL ouput 2 shows that local var $_query (the function's parameter $_query) receives the return value of the previous function foofunction() call output 3 shows that variable is in fact NULL output 5 shows that local var is not accessible output 6 shows that global var is accessible output 7 and 8 shows class members ok output 9 and 10 shows assigning local vars impossible H. Don't belive me? TEST IT: http://66.220.28.17/zero/index.php Looks like assignment of variables is totally messed up (currupt?) The script is like dead: I also tried unseting the global instance of $mydbclass and recreating it, but I get NULL if I vardump the new instance!!! Please help me on this one! //:: CODE EXTRACT FOLLOWS //:: test function function foofunction($_bla) { return "YOUR BLAH: ".$_bla; } $fooglobal= "fooglobal"; // function call $mydbclass->query("select id from user"); //class definition class mydbclass { var $version = 1.0 function mydbclass() { $this->connect(); } // more class methods ... function query
#22288 [Fbk->Opn]: Local vars and function parameters not accessible!
ID: 22288 User updated by: andre dot goncalves at martelozero dot com Reported By: andre dot goncalves at martelozero dot com -Status: Feedback +Status: Open Bug Type: Variables related Operating System: Linux PHP Version: 4.3.1-dev New Comment: What do you mean by serious issues? Maybe you don't understand the questions I made, or the absurd behaviour that I describe - or in the other hand, maybe I don't understand that some stupid error I made somewhere (with cookies you say) might cause this strange behaviour of PHP (you sound very natural about it). Well I have some serious questions: 1. What's the relation between cookies and the Empty + Unavailable + Unassignable local variables and function parameters in the method's implementation? 2. What causes the script to go crazy in terms of variable value assignment? 3. Why do local vars fail to accept values from a certain point on? 4. Hhy it only happens the first time the script runs, and why only in the second time the method is called? After a code-induced & cookie-related error, you say? 5. How does a variable echo a value that it was not assigned? Again, how does $this->tmp2 = "whatever" makes $_query = "whatever"? And why var_dump'ing ($_query) returns NULL? 6. Why $localvar = "foo", does not make $localvar = "foo", i.e., why local vars and parameters are unavailable and unassignable? Thanks Previous Comments: [2003-02-18 23:52:01] [EMAIL PROTECTED] Your script has serious issues...it sets some cookies? It also has some errors, apparently caused by the missing cookie value? This really doesn't seem like any problem in PHP.. ---- [2003-02-18 23:26:04] andre dot goncalves at martelozero dot com Hi! this is really a spooky situation! A. problem with a class only happening in one site (other implementations use same class and always worked fine). B. It only happens the first time I hit the site. C. press F5, or re-enter address, and the problem is gone. D. restarting browser, causes the problem again. E. problem is: The 2nd time I call a method on a certain object, neither the method parameters, neither the global vars are acessible, only the pre-declared class members are there. Remember, i have made a call to this method in the same script exexcutation, some 20 lines before. F. Even more spooky, some vars tend to echo values (wrong values) but var_dump shows NULL for the same var, right from the next line of code!!! G. Check below example: output 1, 3 and 4 show vardump of function parameters NULL ouput 2 shows that local var $_query (the function's parameter $_query) receives the return value of the previous function foofunction() call output 3 shows that variable is in fact NULL output 5 shows that local var is not accessible output 6 shows that global var is accessible output 7 and 8 shows class members ok output 9 and 10 shows assigning local vars impossible H. Don't belive me? TEST IT: http://66.220.28.17/zero/index.php Looks like assignment of variables is totally messed up (currupt?) The script is like dead: I also tried unseting the global instance of $mydbclass and recreating it, but I get NULL if I vardump the new instance!!! Please help me on this one! //:: CODE EXTRACT FOLLOWS //:: test function function foofunction($_bla) { return "YOUR BLAH: ".$_bla; } $fooglobal= "fooglobal"; // function call $mydbclass->query("select id from user"); //class definition class mydbclass { var $version = 1.0 function mydbclass() { $this->connect(); } // more class methods ... function query($_query = "foo", $_fooparam = "bar") { global $fooglobal; global $queryix; $queryix++; $foolocal = "foolocal"; $this->foonewmember = "foonewmember"; echo "($queryix) _query="; var_dump($_query);echo BR; //:: 1 outputs: (2) _query=NULL if (!($this->tmp = mysql_query($_query))) { ; $this->tmp2 = $this->bla("select id from zero_user"); echo "_query echo="; echo($_query); //::2 outputs: _query echo=YOUR BLAH: bla bla echo "_query dump="; var_dump($_query); //::3 ouputs: _query dump=NULL echo "_fooparam="; var_dump($_fooparam); //::4 ouputs: fooparam=NULL echo "globalfoo="; var_dump($fooglobal); //::5 ouputs: fooglobal=fooglobal echo "foolocal="; var_dump($foolocal); //::6 ouputs: foolocal=NULL echo "foonewmember="; var_dump($this->foonewmember); //::7 oupu
#22288 [NEW]: Local vars and function parameters not accessible!
From: andre dot goncalves at martelozero dot com Operating system: Linux PHP version: 4.3.1 PHP Bug Type: Variables related Bug description: Local vars and function parameters not accessible! Hi! this is really a spooky situation! A. problem with a class only happening in one site (other implementations use same class and always worked fine). B. It only happens the first time I hit the site. C. press F5, or re-enter address, and the problem is gone. D. restarting browser, causes the problem again. E. problem is: The 2nd time I call a method on a certain object, neither the method parameters, neither the global vars are acessible, only the pre-declared class members are there. Remember, i have made a call to this method in the same script exexcutation, some 20 lines before. F. Even more spooky, some vars tend to echo values (wrong values) but var_dump shows NULL for the same var, right from the next line of code!!! G. Check below example: output 1, 3 and 4 show vardump of function parameters NULL ouput 2 shows that local var $_query (the function's parameter $_query) receives the return value of the previous function foofunction() call output 3 shows that variable is in fact NULL output 5 shows that local var is not accessible output 6 shows that global var is accessible output 7 and 8 shows class members ok output 9 and 10 shows assigning local vars impossible H. Don't belive me? TEST IT: http://66.220.28.17/zero/index.php Looks like assignment of variables is totally messed up (currupt?) The script is like dead: I also tried unseting the global instance of $mydbclass and recreating it, but I get NULL if I vardump the new instance!!! Please help me on this one! //:: CODE EXTRACT FOLLOWS //:: test function function foofunction($_bla) { return "YOUR BLAH: ".$_bla; } $fooglobal= "fooglobal"; // function call $mydbclass->query("select id from user"); //class definition class mydbclass { var $version = 1.0 function mydbclass() { $this->connect(); } // more class methods ... function query($_query = "foo", $_fooparam = "bar") { global $fooglobal; global $queryix; $queryix++; $foolocal = "foolocal"; $this->foonewmember = "foonewmember"; echo "($queryix) _query="; var_dump($_query);echo BR; //:: 1 outputs: (2) _query=NULL if (!($this->tmp = mysql_query($_query))) { ; $this->tmp2 = $this->bla("select id from zero_user"); echo "_query echo="; echo($_query); //::2 outputs: _query echo=YOUR BLAH: bla bla echo "_query dump="; var_dump($_query); //::3 ouputs: _query dump=NULL echo "_fooparam="; var_dump($_fooparam); //::4 ouputs: fooparam=NULL echo "globalfoo="; var_dump($fooglobal); //::5 ouputs: fooglobal=fooglobal echo "foolocal="; var_dump($foolocal); //::6 ouputs: foolocal=NULL echo "foonewmember="; var_dump($this->foonewmember); //::7 ouputs: foonewmember=string(12) "foonewmember" echo "foooldmember="; var_dump($this->foooldmember); //::8 ouputs: foooldmember=string(9) "foooldmember" echo "result1="; var_dump($this->result1); //::9 ouputs: result1=bool(false) echo "result2="; var_dump($this->result2); //::10 ouputs: result2=NULL } // more class methods ... } // end of class __ Thanks, André Gonçalves -- Edit bug report at http://bugs.php.net/?id=22288&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22288&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22288&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22288&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22288&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22288&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22288&r=support Expected behavior: http://bugs.php.net/fix.php?id=22288&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22288&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22288&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22288&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22288&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22288&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22288&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22288&r=gnused
#20146 [NEW]: child process exited
From: [EMAIL PROTECTED] Operating system: Win2k PHP version: 4.3.0-pre2 PHP Bug Type: Apache2 related Bug description: child process exited The Apache2 server crashs with the following error message: Parent: child process exited with status 3221225477 (or 1073807364) -- Restarting. I've the same problem with older PHP and older Apache2 versions too. The problem is that sometimes the server is killed and I had to restart. Also the server get's sometimes very slow or hang. Apache Support says that this must be an PHP bug! Is their a stable php4apache2.dll version soon? Thx Andre -- Edit bug report at http://bugs.php.net/?id=20146&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20146&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20146&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20146&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20146&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20146&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20146&r=support Expected behavior: http://bugs.php.net/fix.php?id=20146&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20146&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20146&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20146&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20146&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20146&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20146&r=isapi
Bug #16882 Updated: HTML Help crashes opening php_manual_en.chm
ID: 16882 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Documentation problem Operating System: Win XP PHP Version: 4.2.0 New Comment: I downloaded http://www.php.net/distributions/manual/php_manual_en.chm again. Now the chm file is OK and opens in Winhelp. Thanks Previous Comments: [2002-05-02 06:57:53] [EMAIL PROTECTED] Try downloading the file again. hh.exe can't crashes on broken files. [2002-04-28 04:38:33] [EMAIL PROTECTED] What HTML Help is it actually. From php.net or from weblabor.hu? [2002-04-27 21:13:23] [EMAIL PROTECTED] HTML Help (latest version) crashes when opening php_manual_en.chm under Windows XP Pro. hh.exe opens other documents (not from php document page) correctly. AppName: hh.exe AppVer: 4.74.9273.0 ModName: itss.dll ModVer: 4.72.8085.0 Offset: 252c My preferred editor could open context sensitive help for a keyword (e.g. PHP function) with one keystroke - so I consider properly working HTML help a tremendous help in coding and debugging - compared to the other available formats. -- Edit this bug report at http://bugs.php.net/?id=16882&edit=1
Bug #16882: HTML Help crashes opening php_manual_en.chm
From: [EMAIL PROTECTED] Operating system: Win XP PHP version: 4.2.0 PHP Bug Type: Documentation problem Bug description: HTML Help crashes opening php_manual_en.chm HTML Help (latest version) crashes when opening php_manual_en.chm under Windows XP Pro. hh.exe opens other documents (not from php document page) correctly. AppName: hh.exe AppVer: 4.74.9273.0 ModName: itss.dll ModVer: 4.72.8085.0 Offset: 252c My preferred editor could open context sensitive help for a keyword (e.g. PHP function) with one keystroke - so I consider properly working HTML help a tremendous help in coding and debugging - compared to the other available formats. -- Edit bug report at http://bugs.php.net/?id=16882&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16882&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16882&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16882&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16882&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16882&r=support Expected behavior: http://bugs.php.net/fix.php?id=16882&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16882&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16882&r=submittedtwice
Bug #14222 Updated: PHP Crashes with weird output often
ID: 14222 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Windows XP Pro PHP Version: 4.1.1 New Comment: thanks, "apache - X" seems to work !! Previous Comments: [2002-02-08 12:20:56] [EMAIL PROTECTED] I also have this problem. Using latest patches with XP Pro, PHP, and Apache. I have not isolated it yet but it has to do with larger amounts of print/echo output being delivered from a php page. Meaning, if my code displays 10 "news" items (slashdot style page) it works, then if I display say 15 it starts to behave irregularly. This has been observed as a localhost access on to the server on the same computer and also accessing the server running from a different computer on the net. When the problem occurs the browser continually reloads this same page and never finishes. (this noticed when accessing the server through ie6 on xp) When accessing the problem page via mozzila from linux station I notice that the page gets just cut off. Anyway I'll try to isolate further. [2002-02-08 04:03:33] [EMAIL PROTECTED] run apache in single process mode eg: apache -X It's probably a bug in the duplicatesocket [2002-02-07 14:11:49] [EMAIL PROTECTED] Hi I have the same problem I use Win XP and I'm sure that's this is reason - few days ago I have Win Me same configuration Apache/PHP/MySQL - on XP I have: pages are loaded properly from localhost - from internet address: ie loads, nn doesn't (it stops but it do not show any message - just 10% of 10kB in status bar - and so for 30 min). I have rather small page - an online store - without graphics nearly but it communicate with MySQL - so I build a select and when it returns too many rows (or i want more products on page) - the page do not load (even in IE) and I get: Server unreachable. Where can I get alarmed when the bug would fix? Where can I read more about it? [2002-01-21 17:38:40] [EMAIL PROTECTED] update to newest version ? do you mean one in the cvs repository ? i tried everything: apache 1.3x, apache 2.0 beta and php version 4.05, 4.06, 3.x and 4.11 (the latest official) --- and - i must run php as an apache-module because i use gd-lib. besides - gd lib does not work correctly (gives jpegs with only 16 colors) after version 4.05 of php. is this because now there is an extra feature in gd-lib where you must provide bit-depth ? my resume: apache without php works fine, php in cgi-mode works fine -- so there must be an os-related bug in the interface wich allows using the php-dll as an apache - module. maybe an buffer-problem? i tried the following: i took a normal html-page, tried this with apache --> works fine. then simply renamed it to *.php - strange code-output - the normal html but fragmented with weird-passages, they change after every reload. [2002-01-19 21:52:17] [EMAIL PROTECTED] Please update PHP version :) 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/14222 -- Edit this bug report at http://bugs.php.net/?id=14222&edit=1