#42393 [NEW]: mb_strtoupper is replacing one of the cyrillic symbols with wrong one.
From: ivan dot delchev at softconsultgroup dot com Operating system: Windows XP PHP version: 5.2.3 PHP Bug Type: *Unicode Issues Bug description: mb_strtoupper is replacing one of the cyrillic symbols with wrong one. Description: mb_strtoupper is doind wrong transformation for "å" in cyrillic alphabetic. Whe wrong transformation "å"->"í". Also the function is not UPPER the string! Reproduce code: --- // Ensure that the web browser encoding is UTF8 and edit application is UTF8 compatible! $main_string = "Òîâà å òåñò. Îòíîâî Òåñò. Êàêâî áè ñå ïîëó÷èëî ñ òîçè ÒÅÑÒ äà âèäèì!"; var_dump($main_string); var_dump(mb_strtoupper($main_string)); Expected result: Dumped result to be the same. And second string to be UPPER! Actual result: -- string(120) "Òîâà å òåñò. Îòíîâî Òåñò. Êàêâî áè ñå ïîëó÷èëî ñ òîçè ÒÅÑÒ äà âèäèì!" string(120) "Òîâà ï òïñò. Îòíîâî Òïñò. Êàêâî áè ñï ïîëó÷èëî ñ òîçè ÒÅÑÒ äà âèäèì!" -- Edit bug report at http://bugs.php.net/?id=42393&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42393&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42393&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42393&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42393&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42393&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42393&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42393&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42393&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42393&r=support Expected behavior:http://bugs.php.net/fix.php?id=42393&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42393&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42393&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42393&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42393&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42393&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42393&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42393&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42393&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42393&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42393&r=mysqlcfg
#42389 [Opn->Fbk]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389
Updated by: [EMAIL PROTECTED]
Reported By: webmaster at machostlink dot net
-Status: Open
+Status: Feedback
Bug Type: CGI related
Operating System: OSX 10.4.10
PHP Version: 5.2.3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce anything like this, even when uploading quite large
files so try the snapshot first. (any possibility that this isn't any
PHP bug at all..? :)
Previous Comments:
[2007-08-22 20:39:33] webmaster at machostlink dot net
Description:
When using a simple upload form to submit a file, all php4-cgi &
php5-cgi processes (parent & children) are killed and server throws "500
Internal Server Error" message. This happens ONLY when filesize is
larger then 4KB.
Apache error.log from vhost
---
[warn] (35)Resource temporarily unavailable: mod_fcgid: write data to
fastcgi server error
Apache error.log from main/default server
-
mod_fcgid: process /Volumes/home/www/vhost1/public_html/test.php(2293)
exit(communication error), terminated by calling exit(), return code: 0
I am not sure now, after reading other (older) bug reports regarding
cgi problems, if this is not an older issue as well!? However, since I
could not find many similarities to these posts I decided to file this
one.
I am running PHP 4.4.7 & PHP 5.2.3 as CGI using mod_fcgid 2.2 and
Apache 2.2.4
Reproduce code:
---
';
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile))
{
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "Possible file upload attack!\n";
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print "";
?>
Send this file:
Expected result:
File is valid, and was successfully uploaded.
Here is some more debugging info:Array
(
[userfile] => Array
(
[name] => test.jpg
[type] => image/jpeg
[tmp_name] => /Volumes/home/www/vhost1/tmp/phpcYOdvd
[error] => 0
[size] => 24852930
)
)
Actual result:
--
Error 500
Internal Server Error
...
--
Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42393 [Opn->Asn]: mb_strtoupper is replacing one of the cyrillic symbols with wrong one.
ID: 42393 Updated by: [EMAIL PROTECTED] Reported By: ivan dot delchev at softconsultgroup dot com -Status: Open +Status: Assigned -Bug Type: *Unicode Issues +Bug Type: mbstring related Operating System: Windows XP PHP Version: 5.2.3 -Assigned To: +Assigned To: hirokawa New Comment: Assigned to mbstring maintainer. Previous Comments: [2007-08-23 08:06:01] ivan dot delchev at softconsultgroup dot com Description: mb_strtoupper is doind wrong transformation for "å" in cyrillic alphabetic. Whe wrong transformation "å"->"í". Also the function is not UPPER the string! Reproduce code: --- // Ensure that the web browser encoding is UTF8 and edit application is UTF8 compatible! $main_string = "Òîâà å òåñò. Îòíîâî Òåñò. Êàêâî áè ñå ïîëó÷èëî ñ òîçè ÒÅÑÒ äà âèäèì!"; var_dump($main_string); var_dump(mb_strtoupper($main_string)); Expected result: Dumped result to be the same. And second string to be UPPER! Actual result: -- string(120) "Òîâà å òåñò. Îòíîâî Òåñò. Êàêâî áè ñå ïîëó÷èëî ñ òîçè ÒÅÑÒ äà âèäèì!" string(120) "Òîâà ï òïñò. Îòíîâî Òïñò. Êàêâî áè ñï ïîëó÷èëî ñ òîçè ÒÅÑÒ äà âèäèì!" -- Edit this bug report at http://bugs.php.net/?id=42393&edit=1
#42392 [Opn->Bgs]: Multiple Connections to the same Server and Login Override Previous Connections
ID: 42392
Updated by: [EMAIL PROTECTED]
Reported By: memso at memso dot net
-Status: Open
+Status: Bogus
Bug Type: MSSQL related
Operating System: Windows 2003 Server
PHP Version: 5.2.3
New Comment:
RTFM: http://php.net/mssql_connect
"If a second call is made to mssql_connect() with the same arguments,
no new link will be established, but instead, the link identifier of the
already opened link will be returned. "
To create separate link you need to use the 4th optional boolean
parameter (set to true).
Previous Comments:
[2007-08-23 00:45:50] memso at memso dot net
Description:
After creating a MSSQL connection, any subsequent connections to MSSQL,
whether persistant or otherwise, using the same server and login
information, will override the original MSSQL connection. Using two
different logins do not cause the problem.
This has been tested and found to occur in PHP 5.2.0 and 5.2.3 for
Windows (Windows 2003 Server) as well as PHP 5.2.3 for Linux (a heavily
customized v2.2.24).
This is very similar to Bug #17305.
Reproduce code:
---
$testquery = "SELECT EMAILADDRESS FROM adminmain WHERE ID = 1";
$conn1 = mssql_connect("localhost", "sa", "");
mssql_select_db("generic", $conn1);
// First Query!
$result = mssql_query($testquery, $conn1);
$qarray = mssql_fetch_array($result);
echo("First Result: " . $qarray["EMAILADDRESS"] . "");
$conn2 = mssql_connect("localhost", "sa", "");
mssql_select_db("buymanitou", $conn2);
// Second Query!
// NOTE THAT THIS IS ON CONN1 AGAIN!
$result = mssql_query($testquery, $conn1);
$qarray = mssql_fetch_array($result);
echo("Second Result: " . $qarray["EMAILADDRESS"] . "");
mssql_close($conn1);
mssql_close($conn2);
Expected result:
In my test case, I am grabbing an email address from the first
administrator in the system from the first database connection. Since in
my case, the first DB connection returns [EMAIL PROTECTED]
, I expect the following output:
First Result: [EMAIL PROTECTED]
Second Result: [EMAIL PROTECTED]
Actual result:
--
Because of the bug, the email address from the SECOND database is
returned for the second query:
First Result: [EMAIL PROTECTED]
Second Result: [EMAIL PROTECTED]
--
Edit this bug report at http://bugs.php.net/?id=42392&edit=1
#42389 [Com]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389
Comment by: webmaster at lifedit dot com
Reported By: webmaster at machostlink dot net
Status: Feedback
Bug Type: CGI related
Operating System: OSX 10.4.10
PHP Version: 5.2.3
New Comment:
Right, I was taken that already in consideration and posted a report on
"mod_fcgid users bug tracker" as well. But looking at the history of
somewhat related php-cgi problems and bug reported I think it is more
likely to be a PHP bug.
My problem is that I have a hosting service and I rely on both PHP5 &
PHP4 because I do have clients who still have PHP4 applications they
want to run. So even if it does work with the latest CVS (which I will
try out) I still have a need for this feature to run on PHP4 as well. :(
Previous Comments:
[2007-08-23 09:06:04] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce anything like this, even when uploading quite large
files so try the snapshot first. (any possibility that this isn't any
PHP bug at all..? :)
[2007-08-22 20:39:33] webmaster at machostlink dot net
Description:
When using a simple upload form to submit a file, all php4-cgi &
php5-cgi processes (parent & children) are killed and server throws "500
Internal Server Error" message. This happens ONLY when filesize is
larger then 4KB.
Apache error.log from vhost
---
[warn] (35)Resource temporarily unavailable: mod_fcgid: write data to
fastcgi server error
Apache error.log from main/default server
-
mod_fcgid: process /Volumes/home/www/vhost1/public_html/test.php(2293)
exit(communication error), terminated by calling exit(), return code: 0
I am not sure now, after reading other (older) bug reports regarding
cgi problems, if this is not an older issue as well!? However, since I
could not find many similarities to these posts I decided to file this
one.
I am running PHP 4.4.7 & PHP 5.2.3 as CGI using mod_fcgid 2.2 and
Apache 2.2.4
Reproduce code:
---
';
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile))
{
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "Possible file upload attack!\n";
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print "";
?>
Send this file:
Expected result:
File is valid, and was successfully uploaded.
Here is some more debugging info:Array
(
[userfile] => Array
(
[name] => test.jpg
[type] => image/jpeg
[tmp_name] => /Volumes/home/www/vhost1/tmp/phpcYOdvd
[error] => 0
[size] => 24852930
)
)
Actual result:
--
Error 500
Internal Server Error
...
--
Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42339 [Opn->Fbk]: Can't Build a CLI *only* must have APXS enabled
ID: 42339 Updated by: [EMAIL PROTECTED] Reported By: codeslinger at compsalot dot com -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: SimplyMEPIS Linux 6.5 PHP Version: 5.2.3 New Comment: # ./configure --disable-cgi or # ./configure --without-apxs2 Both work just fine here. You're simply doing something wrong or I'm high on crack. :) I even removed Apache from my test machine to be sure. Any other SAPIs aren't enabled by default except for CLI and CGI. With plain ./configure without any options you get both. Please it with this latest snapshot instead of 5.2.3: http://snaps.php.net/php5.2-latest.tar.gz Previous Comments: [2007-08-22 19:13:53] codeslinger at compsalot dot com The sources used are fine, I downloaded them direct from php.net and verified the md5. The documentation on the options is incomplete. I tried --without-apxs because even though it is not documented, it is symmetrical to the option --with-apxs which is documented, but that did not work. Also, not saying anything about apxs at all did not work either. Everything I tried, the ./configure failed. After entering this bug and thinking about it some more, it occurred to me to try --disable-apxs and did discover that it was the only thing which produced the desired behavior of a CLI only build. And that's when I changed the category to a documentation bug. Anything else results in the error: "Sorry, I was not able to successfully run APXS." I get that error even though I have not specified --with-apxs. php by default is trying to build the apxs version even when it is not requested. I note in the change log that there have been some recent changes to the "make". perhaps this problem is newly introduced. Also my actual goal was to build both CGI and CLI at the same time, but for the purpose of this bug I decided to simplify and isolate as much as possible. [2007-08-20 07:48:19] [EMAIL PROTECTED] This is not true. Simply doing './configure --disable-cgi' gives you CLI. There isn't such option as '--disable-apxs'.. You propably used unclean sources. [2007-08-18 17:46:21] codeslinger at compsalot dot com this is actually a documentation problem. the correct command should be './configure'--enable-cli --disable-cgi --disable-apxs [2007-08-18 17:36:23] codeslinger at compsalot dot com Description: There are many options for PHP, such as ncurses, which are not compatible with phpN-mod.so But when trying to build a CLI only config, it fails with an error message that APXS is not enabled. Reproduce code: --- I tried many variants, here is the simplest: './configure'--enable-cli--disable-cgi --without-apxs2 --without-apxs Expected result: Expected: No errors Note: the following command *does* work './configure'--enable-cli--disable-cgi '--with-apxs2=/usr/bin/apxs2' Actual result: -- Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... Sorry, I was not able to successfully run APXS. Possible reasons: 1. Perl is not installed; 2. Apache was not compiled with DSO support (--enable-module=so); 3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs The output of /usr/local/src/php-5.2.3/no follows ./configure: line 4396: /usr/local/src/php-5.2.3/no: No such file or directory configure: error: Aborting -- Edit this bug report at http://bugs.php.net/?id=42339&edit=1
#42390 [Opn->Fbk]: GMP functions exhausts memory
ID: 42390
Updated by: [EMAIL PROTECTED]
Reported By: cbimax at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Math related
Operating System: Linux Gentoo K.2.6.20
PHP Version: 5.2.2
New Comment:
I can not reproduce this using latest PHP 5.2.4-dev.
So please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
Previous Comments:
[2007-08-22 21:39:29] cbimax at gmail dot com
Description:
Any gmp_* function running on PHP 5.2.2-r1 (compiled with GMP
extensions), throws after a few invokes "Fatal error: Allowed memory
size of bytes exhausted (tried to allocate 16
bytes) in ".
Reproduce code:
---
for( $i= 0; $i!= 10; $i++ )
{
$node = gmp_init( $i );
$id = gmp_div( $node, '0x1' );
$edge = gmp_and( $node, '0x' );
$vert = gmp_div( $node, '0x1000' );
$path = gmp_and( $node, '0x00ff' );
$str_edge = gmp_strval( $edge );
$str_vert = gmp_strval( $vert );
$str_path = gmp_strval( $path );
echo "Graph -> ($str_edge, $str_vert, $str_path) \n";
}
Expected result:
The iterated procedure runs on PHP 5.1.x (and PHP 5.0.x) near to 1
million times per call.
In this case, it's only runs 500 times and then drop the Fatal error.
Actual result:
--
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 16 bytes) in quixtor/compute-graph-map.php on line 443
(actually line 443 isn't a gmp related function, but it is called under
for() iteration which uses GMP functions).
--
Edit this bug report at http://bugs.php.net/?id=42390&edit=1
#42394 [NEW]: UID ( X-UID ) > 0x80000000 misinterpreted unsigned numbers
From: ivan dot dolezal at vsb dot cz Operating system: Debian 3.1 PHP version: 4.4.7 PHP Bug Type: IMAP related Bug description: UID ( X-UID ) > 0x8000 misinterpreted unsigned numbers Description: Your library seems to break IMAP standard while inconsistently operating with UID numbers sometimes as signed, sometimes as unsigned. This results in fatal errors when operating e-mails with UID>0x8000. The whole issue had been documented at http://bugs.horde.org/ticket/?id=5657 as HORDE/IMP bug, but its developers refused the responsibility referring to PHP itself. -- Edit bug report at http://bugs.php.net/?id=42394&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42394&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42394&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42394&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42394&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42394&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42394&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42394&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42394&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42394&r=support Expected behavior:http://bugs.php.net/fix.php?id=42394&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42394&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42394&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42394&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42394&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42394&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42394&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42394&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42394&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42394&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42394&r=mysqlcfg
#42383 [Csd->Bgs]: Configuring with mysqli enabled consistently fails
ID: 42383 Updated by: [EMAIL PROTECTED] Reported By: intel352 at gmail dot com -Status: Closed +Status: Bogus Bug Type: Compile Failure Operating System: Centos 4 PHP Version: 5.2.3 Previous Comments: [2007-08-23 00:40:42] intel352 at gmail dot com Thanks, that tip helped me find the culprit file. I've got it compiling successfully now, I appreciate it! [2007-08-22 22:36:49] [EMAIL PROTECTED] find / -name libmysqlclient* 2>/dev/null you have a libmysqlclient thats its linking against. [2007-08-22 20:21:34] intel352 at gmail dot com Actually, I just checked, I have MySQL Client 5.0.45 installed. The only possible issue that I see, is that MySQL 4.1 Embedded is installed, so I dunno if that's overriding the MySQL 5 Client somehow. Any thoughts? [2007-08-22 20:00:46] intel352 at gmail dot com Thanks very much for letting me know, I'll check into that. This has been bothering the heck outta me, it'll be nice to get this resolved :-) Thanks! [2007-08-22 15:56:12] [EMAIL PROTECTED] If mysql_set_server_option isn't present then your version of mysqlclient is less than 4.1. You need mysqlclient 4.1 for MySQLi 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/42383 -- Edit this bug report at http://bugs.php.net/?id=42383&edit=1
#42395 [Opn->Fbk]: httpd crashes near file uploading
ID: 42395 Updated by: [EMAIL PROTECTED] Reported By: jille at hexon dot cx -Status: Open +Status: Feedback Bug Type: Apache related Operating System: MacOS 10.4.9 PHP Version: 5.2.3 New Comment: First get the latst 5.2.4-dev snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz Then compile it with using --enable-debug in your configure line. Before you launch Apache, disable all Zend extensions in your php.ini. Run Apache under GDB: # gdb --arg httpd -X (gdb) run Then do the things required to crash it and: (gdb) bt And you should have better backtrace. Although it seems to be coming from the filter extension by looking at the current backtrace, it's easier to pinpoint the exact place when the debug symbols are around. Previous Comments: [2007-08-23 10:03:39] jille at hexon dot cx Description: I have found these 2 lines in my syslog, this crash happens nearly a few times a day. Aug 23 10:37:00 hillsbrad crashdump[10305]: httpd crashed Aug 23 10:37:00 hillsbrad crashdump[10305]: crash report written to: /Library/Logs/CrashReporter/httpd.crash.log My website is being used by 400 users a day, on the 'crashing page' several images can be uploaded. Reproduce code: --- I tried to reproduce the crash, but it didn`t work out. I`ve added some debug code, some debuglines appear about 30 seconds before the crash. Some a few seconds after (they are not reported in the same way). It might also be that the debugging lines are not even reached. Expected result: I don`t know what exactly happens to the user on the website. I`ve never got any complaints about it or something. It could be a delayed crash or something (eg: the uploads create some buffer overflow, and apache crashes on the next request or something.) But I would expect not to see a crash happen Actual result: -- Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x310074f4 Thread 0 Crashed: 0 libphp5.so 0x022f2010 _zend_mm_free_int + 544 1 libphp5.so 0x02323808 zend_hash_destroy + 168 2 libphp5.so 0x023161b4 _zval_dtor_func + 164 3 libphp5.so 0x02304100 _zval_ptr_dtor + 80 4 libphp5.so 0x0207f4ec zm_deactivate_filter + 140 5 libphp5.so 0x0231a95c module_registry_cleanup + 44 6 libphp5.so 0x02323ce8 zend_hash_apply + 152 7 libphp5.so 0x02316c1c zend_deactivate_modules + 92 8 libphp5.so 0x022c1298 php_request_shutdown + 328 9 libphp5.so 0x023ca1cc apache_php_module_main + 236 10 libphp5.so 0x023cb8bc send_php + 1212 11 libphp5.so 0x023cb968 send_parsed_php + 56 12 httpd 0xdd18 ap_invoke_handler + 232 13 httpd 0x00017dd4 process_request_internal + 640 14 httpd 0x00017e54 ap_process_request + 72 15 httpd 0x6b60 child_main + 1832 16 httpd 0x6dc4 make_child + 312 17 httpd 0x7660 standalone_main + 852 18 httpd 0x7d74 main + 1052 19 httpd 0x238c _start + 348 20 httpd 0x222c start + 60 Thread 0 crashed with PPC Thread State 64: srr0: 0x022f2010 srr1: 0x1200f030 vrsave: 0x cr: 0x48000448 xer: 0x lr: 0x022f1e90 ctr: 0x3ddc r0: 0x r1: 0xbfffe220 r2: 0x0001 r3: 0x0185e800 r4: 0x002c74b0 r5: 0x0002 r6: 0x002c74a8 r7: 0x r8: 0x0010 r9: 0x002c74e8 r10: 0x002c74e8 r11: 0x310074e8 r12: 0x3ddc r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x00057314 r23: 0x00057314 r24: 0x00057314 r25: 0x00057314 r26: 0x0187a638 r27: 0x0231a930 r28: 0x0185e800 r29: 0x0040 r30: 0x002c74a8 r31: 0x022f1e04 Binary Images Description: 0x1000 -0x4 httpd /usr/sbin/httpd 0x65000 -0x67fff mod_log_config.so /usr/libexec/httpd/mod_log_config.so 0x6a000 -0x6bfff mod_mime.so /usr/libexec/httpd/mod_mime.so 0x6e000 -0x70fff mod_status.so /usr/libexec/httpd/mod_status.so 0x73000 -0x75fff mod_info.so /usr/libexec/httpd/mod_info.so 0x78000 -0x81fff mod_rewrite.so /usr/libexec/httpd/mod_rewrite.so 0x85000 -0x86fff mod_access.so /usr/libexec/httpd/mod_access.so 0x89000 -0x8afff mod_auth_apple.so /usr/libexec/httpd/mod_auth_apple.so 0x8d000 -0x8dfff mod_setenvif.so /usr/libexec/httpd/mod_setenvif.so 0x9 -0x90fff mod_hfs_apple.so /usr/libexec/httpd/mod_hfs_apple.so 0x93000 -0x95fff mod_digest_a
#42395 [NEW]: httpd crashes near file uploading
From: jille at hexon dot cx Operating system: MacOS 10.4.9 PHP version: 5.2.3 PHP Bug Type: Apache related Bug description: httpd crashes near file uploading Description: I have found these 2 lines in my syslog, this crash happens nearly a few times a day. Aug 23 10:37:00 hillsbrad crashdump[10305]: httpd crashed Aug 23 10:37:00 hillsbrad crashdump[10305]: crash report written to: /Library/Logs/CrashReporter/httpd.crash.log My website is being used by 400 users a day, on the 'crashing page' several images can be uploaded. Reproduce code: --- I tried to reproduce the crash, but it didn`t work out. I`ve added some debug code, some debuglines appear about 30 seconds before the crash. Some a few seconds after (they are not reported in the same way). It might also be that the debugging lines are not even reached. Expected result: I don`t know what exactly happens to the user on the website. I`ve never got any complaints about it or something. It could be a delayed crash or something (eg: the uploads create some buffer overflow, and apache crashes on the next request or something.) But I would expect not to see a crash happen Actual result: -- Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x310074f4 Thread 0 Crashed: 0 libphp5.so 0x022f2010 _zend_mm_free_int + 544 1 libphp5.so 0x02323808 zend_hash_destroy + 168 2 libphp5.so 0x023161b4 _zval_dtor_func + 164 3 libphp5.so 0x02304100 _zval_ptr_dtor + 80 4 libphp5.so 0x0207f4ec zm_deactivate_filter + 140 5 libphp5.so 0x0231a95c module_registry_cleanup + 44 6 libphp5.so 0x02323ce8 zend_hash_apply + 152 7 libphp5.so 0x02316c1c zend_deactivate_modules + 92 8 libphp5.so 0x022c1298 php_request_shutdown + 328 9 libphp5.so 0x023ca1cc apache_php_module_main + 236 10 libphp5.so 0x023cb8bc send_php + 1212 11 libphp5.so 0x023cb968 send_parsed_php + 56 12 httpd 0xdd18 ap_invoke_handler + 232 13 httpd 0x00017dd4 process_request_internal + 640 14 httpd 0x00017e54 ap_process_request + 72 15 httpd 0x6b60 child_main + 1832 16 httpd 0x6dc4 make_child + 312 17 httpd 0x7660 standalone_main + 852 18 httpd 0x7d74 main + 1052 19 httpd 0x238c _start + 348 20 httpd 0x222c start + 60 Thread 0 crashed with PPC Thread State 64: srr0: 0x022f2010 srr1: 0x1200f030 vrsave: 0x cr: 0x48000448 xer: 0x lr: 0x022f1e90 ctr: 0x3ddc r0: 0x r1: 0xbfffe220 r2: 0x0001 r3: 0x0185e800 r4: 0x002c74b0 r5: 0x0002 r6: 0x002c74a8 r7: 0x r8: 0x0010 r9: 0x002c74e8 r10: 0x002c74e8 r11: 0x310074e8 r12: 0x3ddc r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x00057314 r23: 0x00057314 r24: 0x00057314 r25: 0x00057314 r26: 0x0187a638 r27: 0x0231a930 r28: 0x0185e800 r29: 0x0040 r30: 0x002c74a8 r31: 0x022f1e04 Binary Images Description: 0x1000 -0x4 httpd /usr/sbin/httpd 0x65000 -0x67fff mod_log_config.so /usr/libexec/httpd/mod_log_config.so 0x6a000 -0x6bfff mod_mime.so /usr/libexec/httpd/mod_mime.so 0x6e000 -0x70fff mod_status.so /usr/libexec/httpd/mod_status.so 0x73000 -0x75fff mod_info.so /usr/libexec/httpd/mod_info.so 0x78000 -0x81fff mod_rewrite.so /usr/libexec/httpd/mod_rewrite.so 0x85000 -0x86fff mod_access.so /usr/libexec/httpd/mod_access.so 0x89000 -0x8afff mod_auth_apple.so /usr/libexec/httpd/mod_auth_apple.so 0x8d000 -0x8dfff mod_setenvif.so /usr/libexec/httpd/mod_setenvif.so 0x9 -0x90fff mod_hfs_apple.so /usr/libexec/httpd/mod_hfs_apple.so 0x93000 -0x95fff mod_digest_apple.so /usr/libexec/httpd/mod_digest_apple.so 0x98000 -0xb4fff libssl.so /usr/libexec/httpd/libssl.so 0xd1000 -0xeefff libjpeg.62.dylib /sw/lib/libjpeg.62.dylib 0xf6000 -0xf7fff ZendExtensionManager.so /usr/local/Zend/lib/ZendExtensionManager.so 0x205000 - 0x223fff libpng.3.dylib /sw/lib/libpng.3.dylib 0x282000 - 0x286fff libmnogocharset-3.3.dylib /usr/local/mnogosearch/lib/libmnogocharset-3.3.dylib 0x405000 - 0x4fefff libiconv.2.dylib /sw/lib/libiconv.2.dylib 0x1008000 - 0x1048fff libfreetype.6.dylib /sw/lib/libfreetype.6.dylib 0x118f000 - 0x129 libxml2.2.dylib /sw/lib/libxml2.2.dylib 0x14d5000 - 0x1600fff ZendOptimizer.so /usr/local/Zend/lib/Optimizer-3.2.8/php-5.2.x/ZendOptimizer.so 0x2008000
#42374 [Opn->Fbk]: --as-needed bug - follow-up
ID: 42374 Updated by: [EMAIL PROTECTED] Reported By: galtgendo at o2 dot pl -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: gentoo linux PHP Version: 5.2.3 New Comment: PHP_CHECK_LIBRARY restores the LDFLAGS after doing the test so it shouldn't be any problem? And bug #41973 was about ext/ldap and that was fixed. I'd fix these case by case rather than blindly changing places unlikely to even cause any problems. Previous Comments: [2007-08-22 15:40:41] galtgendo at o2 dot pl Well, I'm not 100%, if I was, I would mentioned it, not asked for futher testing. And AFAIK that commit from bug #41973 was only http://cvs.php.net/viewvc.cgi/php-src/ext/ldap/config.m4?r1=1.44&r2=1.45&diff_format=u so only about ext/ldap/config.m4 (as in my patch). What's more, although I can't recall if it made any difference you should consider changes in acinclude.m4, cause in PHP_CHECK_LIBRARY macro you were adding libraries to LDFLAGS instead of LIBS and that's most common source of --as-needed bugs. That's why I'm talking about false negatives - standard configure check would put those libraries in wrong place and check would fail even if the library was OK. [2007-08-22 14:46:27] [EMAIL PROTECTED] And have you even tested what was committed in our CVS? [2007-08-22 14:45:33] [EMAIL PROTECTED] FYI: this is not bugzilla and it's not annoying. It's just old. :) And about your patch..are you really sure you need to change all those places? [2007-08-22 10:30:40] galtgendo at o2 dot pl As I don't see a way to attach anything here, I'll give you a link to an old gentoo bug with my patch. It's http://bugs.gentoo.org/show_bug.cgi?id=151444 It's an old bug so it still covers the part from the closed bug. BTW your bugzilla is REALLY annoying. [2007-08-22 09:57:33] galtgendo at o2 dot pl Description: Recently closed bug #41973 may not cover all the issues. I have a patch that doesn't seem to break anything for me and AFAIK solves all potential issues. The --as-needed bugs happen mostly when you use libtool and add -L and -l to LDFLAGS instead of LIBS. So by the use of grep I tried to change all the macros that seem to do that. I hope I didn't break anything, however somebody should check that, cause 'works for me'!='it works'. At least look at acinclude.m4, cause that one may lead to false negatives with library detection. -- Edit this bug report at http://bugs.php.net/?id=42374&edit=1
#24679 [Com]: pg_insert problem!
ID: 24679
Comment by: frank at geo-dienstleistung dot de
Reported By: rorezende at hotmail dot com
Status: No Feedback
Bug Type: PostgreSQL related
Operating System: *
PHP Version: 4.3.2
Assigned To: helly
New Comment:
I can confirm this bug on php 5.2.1 too. It really makes this function
pretty much useless.
Previous Comments:
[2007-03-14 16:07:04] pentropia at gmail dot com
Iv'e noticed the same problem on php 5.2.1
[2005-09-21 05:04:00] nathanr at nathanr dot net
Nope, this is a genuine bug, I've tested on SuSE Linux Professional 9.3
using both PHP 4.3.10 and 5.0.3 against PostgreSQL 8.0.3. They both
produce non-working results. To replicate the bug:
test.sql:
create schema tstschma;
create table tstschma.tsttbl (
x int not null,
y int not null,
primary key (x)
);
now try this php:
$db = pg_connect("dbname=testdb");
$l = array('x'=>'1', 'y'=>'2');
pg_insert($db, "tstschma.tsttbl", $l);
pg_close($db);
If you remove the schema (tstschma) from the name then the select
works, but the insert of course does not.
The problem stems from the fact that pg_class.relname does not include
the schema name, but to run a query against the table you must have the
schema name. I suggest your fix is to strip everything before and
including the last dot in the table name (won't change anything for
those not using schemas, but will strip "tstschma." from the above
example), but use the table name passed to the method (ie. including the
"tstschma.") when you go to do the insert.
[2005-09-21 05:03:41] nathanr at nathanr dot net
Nope, this is a genuine bug, I've tested on SuSE Linux Professional 9.3
using both PHP 4.3.10 and 5.0.3 against PostgreSQL 8.0.3. They both
produce non-working results. To replicate the bug:
test.sql:
create schema tstschma;
create table tstschma.tsttbl (
x int not null,
y int not null,
primary key (x)
);
now try this php:
$db = pg_connect("dbname=testdb");
$l = array('x'=>'1', 'y'=>'2');
pg_insert($db, "tstschma.tsttbl", $l);
pg_close($db);
If you remove the schema (tstschma) from the name then the select
works, but the insert of course does not.
The problem stems from the fact that pg_class.relname does not include
the schema name, but to run a query against the table you must have the
schema name. I suggest your fix is to strip everything before and
including the last dot in the table name (won't change anything for
those not using schemas, but will strip "tstschma." from the above
example), but use the table name passed to the method (ie. including the
"tstschma.") when you go to do the insert.
[2003-07-23 22:30:19] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2003-07-16 21:28:37] [EMAIL PROTECTED]
Please provide an example script which shows the problem clearly.
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/24679
--
Edit this bug report at http://bugs.php.net/?id=24679&edit=1
#42378 [Opn->Asn]: bind_result memory exhaustion
ID: 42378 Updated by: [EMAIL PROTECTED] Reported By: jullrich at sans dot org -Status: Open +Status: Assigned Bug Type: MySQLi related Operating System: Linux (CentOS 4.5) PHP Version: 5.2.3 -Assigned To: +Assigned To: andrey New Comment: Assigned to the Mysqli maintainer. Previous Comments: [2007-08-22 11:44:28] jullrich at sans dot org 'cast' can be used as a workaround: works: cast(format(trend,2) as char(10))) does not work (same memory error): cast(format(trend,2) as char) [2007-08-22 11:33:14] jullrich at sans dot org Description: The use of the mysql command "format" will lead to memory exhaustion on bind_results. Here sample code that does cause the issue: $sQuery="select targetport,format(trend,2) from trends where current_targets>10 and trend is not null order by trend desc limit 100"; $oStmt=$oDB->prepare($sQuery); $oStmt->execute(); $oStmt->store_result(); $oStmt->bind_result($nPort,$nTrend); This code works fine if $sQuery is replaced with: $sQuery="select targetport,trend from trends where current_targets>10 and trend is not null order by trend desc limit 100"; removing 'store_result' has no effect. Other changes to the SQL statement have no effect either. Error message logged: PHP Fatal error: Allowed memory size of 83886080 bytes exhausted (tried to allocate 1431655788 bytes) in query.html on line 4 Reproduce code: --- $sQuery="select targetport,format(trend,2) from trends where current_targets>10 and trend is not null order by trend desc limit 100"; $oStmt=$oDB->prepare($sQuery); $oStmt->execute(); $oStmt->store_result(); $oStmt->bind_result($nPort,$nTrend); Expected result: I expected the query to "happen" and get executed. Actual result: -- PHP Fatal error: Allowed memory size of 83886080 bytes exhausted (tried to allocate 1431655788 bytes) in query.html on line 4 (Line number corresponds to the 'bind_result' statement) -- Edit this bug report at http://bugs.php.net/?id=42378&edit=1
#42318 [Opn->Fbk]: problem with nm not finding object files
ID: 42318 Updated by: [EMAIL PROTECTED] Reported By: rainer dot tammer at schulergroup dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: AIX 5.2/5.3 PHP Version: 5.2CVS-2007-08-17 Assigned To: dmitry New Comment: About libtool: PHP does not use any external libtool unless you force it to do it..so are you doing something you shouldn't be doing? :) PHP uses the bundled libtool version 1.5.20. Previous Comments: [2007-08-23 06:07:20] rainer dot tammer at schulergroup dot com Hello, just a quick note: The fix to the two config files (sapi/cgi/config9.m4 / sapi/cli/config.m4) only affects AIX !! Bye Rainer [2007-08-22 15:49:07] rainer dot tammer at schulergroup dot com Hello, yes nm -BCpg does not find the files. With the suggested fix nm does find all necessary file an works OK. I have tested the fix on AIX 5.2 and AIX 5.3 with IBM XL C/C++ 8.0 and gcc 3.3. Bye Rainer [2007-08-22 15:33:07] [EMAIL PROTECTED] So this is just a warning from AIX nm? PHP builds and runs ok after that, am I right? [2007-08-17 08:13:23] rainer dot tammer at schulergroup dot com Hello, its the same problem with gcc 3.3: nm: ext/libxml/libxml.o: 0654-200 Cannot open the specified file. nm: A file or directory in the path name does not exist. nm: ext/pcre/pcrelib/pcre_chartables.o: 0654-200 Cannot open the specified file. nm: A file or directory in the path name does not exist. nm: ext/pcre/pcrelib/pcre_ucp_searchfuncs.o: 0654-200 Cannot open the specified file. nm: A file or directory in the path name does not exist. Bye Rainer [2007-08-17 07:13:42] rainer dot tammer at schulergroup dot com Hello, the CVS snapshot does not change this problem (compiler xl c/c++). But to be sure I will also test gcc 3.3 Bye Rainer 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/42318 -- Edit this bug report at http://bugs.php.net/?id=42318&edit=1
#42379 [Opn->Fbk]: flush() will eat my server's memory!!
ID: 42379 Updated by: [EMAIL PROTECTED] Reported By: mika at netstock dot net -Status: Open +Status: Feedback Bug Type: Output Control Operating System: freebsd-6.2 PHP Version: 5.2.3 New Comment: Only thing I get is this output: Notice: Undefined variable: var in /opt/www/t.php on line 4 And no leak. How about providing us a bit more information and a script that does not have any errors/notices in it? Your configure line would be nice to know. And what extensions (if any) you load in php.ini.. Previous Comments: [2007-08-22 13:21:04] mika at netstock dot net Description: when i use flush() or ob_implicit_flush() to push data to browser it will keep eating my server's memory like 4k 4k 4k..and another 4k .. and my apache is 2.0.59 Do anyone can help me Reproduce code: --- or -- Edit this bug report at http://bugs.php.net/?id=42379&edit=1
#15363 [Com]: When the 'message' size is over 3991 bits, mail function fail.
ID: 15363 Comment by: jesus_dew at hotmail dot com Reported By: dsc at xp dot fm Status: No Feedback Bug Type: Mail related Operating System: windows 2000 PHP Version: 4.1.1 New Comment: I can not send too if message length more than 5290 bits. PHP: version 5.2.0 OS: Windows Server 2003R2 Web Server: IIS6.0 Previous Comments: [2002-07-03 01:00:09] php-bugs at lists dot php dot net No feedback was provided for this bug for over a month, 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". [2002-06-02 13:51:40] [EMAIL PROTECTED] Please try with the current snapshot from http://snaps.php.net/win32/php4-win32-latest.zip [2002-02-04 02:10:58] dsc at xp dot fm When the message size is over 3991 bits, there is an error msg : "PHP Warning: Failed to Send in e:\phplib\include\mime\mime.class on line 286", and when i cut down the message, then it sent mail success. -- Edit this bug report at http://bugs.php.net/?id=15363&edit=1
#42318 [Fbk->Opn]: problem with nm not finding object files
ID: 42318 User updated by: rainer dot tammer at schulergroup dot com Reported By: rainer dot tammer at schulergroup dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: AIX 5.2/5.3 PHP Version: 5.2CVS-2007-08-17 Assigned To: dmitry New Comment: Hello, this was only a general note on the system. It has nothing todo with the bug. This build uses the bundled libtool. Bye Rainer Previous Comments: [2007-08-23 10:46:58] [EMAIL PROTECTED] About libtool: PHP does not use any external libtool unless you force it to do it..so are you doing something you shouldn't be doing? :) PHP uses the bundled libtool version 1.5.20. [2007-08-23 06:07:20] rainer dot tammer at schulergroup dot com Hello, just a quick note: The fix to the two config files (sapi/cgi/config9.m4 / sapi/cli/config.m4) only affects AIX !! Bye Rainer [2007-08-22 15:49:07] rainer dot tammer at schulergroup dot com Hello, yes nm -BCpg does not find the files. With the suggested fix nm does find all necessary file an works OK. I have tested the fix on AIX 5.2 and AIX 5.3 with IBM XL C/C++ 8.0 and gcc 3.3. Bye Rainer [2007-08-22 15:33:07] [EMAIL PROTECTED] So this is just a warning from AIX nm? PHP builds and runs ok after that, am I right? [2007-08-17 08:13:23] rainer dot tammer at schulergroup dot com Hello, its the same problem with gcc 3.3: nm: ext/libxml/libxml.o: 0654-200 Cannot open the specified file. nm: A file or directory in the path name does not exist. nm: ext/pcre/pcrelib/pcre_chartables.o: 0654-200 Cannot open the specified file. nm: A file or directory in the path name does not exist. nm: ext/pcre/pcrelib/pcre_ucp_searchfuncs.o: 0654-200 Cannot open the specified file. nm: A file or directory in the path name does not exist. Bye Rainer 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/42318 -- Edit this bug report at http://bugs.php.net/?id=42318&edit=1
#42389 [Fbk->Opn]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389
User updated by: webmaster at machostlink dot net
Reported By: webmaster at machostlink dot net
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: OSX 10.4.10
PHP Version: 5.2.3
New Comment:
Ok, I checked the latest CVS snapshot but the problem still remains the
same.
I forgot to mention in my inital post that I am using Apache2 with
mod_suexec for permissions. But that seems to work fine according to
suexec.log and apache2 error.log files. Thought I mention it now anyway
just in case.
Previous Comments:
[2007-08-23 09:13:53] webmaster at lifedit dot com
Right, I was taken that already in consideration and posted a report on
"mod_fcgid users bug tracker" as well. But looking at the history of
somewhat related php-cgi problems and bug reported I think it is more
likely to be a PHP bug.
My problem is that I have a hosting service and I rely on both PHP5 &
PHP4 because I do have clients who still have PHP4 applications they
want to run. So even if it does work with the latest CVS (which I will
try out) I still have a need for this feature to run on PHP4 as well. :(
[2007-08-23 09:06:04] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce anything like this, even when uploading quite large
files so try the snapshot first. (any possibility that this isn't any
PHP bug at all..? :)
[2007-08-22 20:39:33] webmaster at machostlink dot net
Description:
When using a simple upload form to submit a file, all php4-cgi &
php5-cgi processes (parent & children) are killed and server throws "500
Internal Server Error" message. This happens ONLY when filesize is
larger then 4KB.
Apache error.log from vhost
---
[warn] (35)Resource temporarily unavailable: mod_fcgid: write data to
fastcgi server error
Apache error.log from main/default server
-
mod_fcgid: process /Volumes/home/www/vhost1/public_html/test.php(2293)
exit(communication error), terminated by calling exit(), return code: 0
I am not sure now, after reading other (older) bug reports regarding
cgi problems, if this is not an older issue as well!? However, since I
could not find many similarities to these posts I decided to file this
one.
I am running PHP 4.4.7 & PHP 5.2.3 as CGI using mod_fcgid 2.2 and
Apache 2.2.4
Reproduce code:
---
';
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile))
{
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "Possible file upload attack!\n";
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print "";
?>
Send this file:
Expected result:
File is valid, and was successfully uploaded.
Here is some more debugging info:Array
(
[userfile] => Array
(
[name] => test.jpg
[type] => image/jpeg
[tmp_name] => /Volumes/home/www/vhost1/tmp/phpcYOdvd
[error] => 0
[size] => 24852930
)
)
Actual result:
--
Error 500
Internal Server Error
...
--
Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42395 [Opn->Fbk]: httpd crashes near file uploading
ID: 42395 Updated by: [EMAIL PROTECTED] Reported By: jille at hexon dot cx -Status: Open +Status: Feedback Bug Type: Apache related Operating System: MacOS 10.4.9 PHP Version: 5.2.3 New Comment: Nobody asked you to run it on live site.. Previous Comments: [2007-08-23 11:33:40] jille at hexon dot cx I can't run 5.2.4-dev in gdb on a live server. That will slow down about 1000+ sites i`m hosting. But I will try to run one server without Zend extensions. Let`s see whether I still get crashes on that one [2007-08-23 10:26:12] [EMAIL PROTECTED] First get the latst 5.2.4-dev snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz Then compile it with using --enable-debug in your configure line. Before you launch Apache, disable all Zend extensions in your php.ini. Run Apache under GDB: # gdb --arg httpd -X (gdb) run Then do the things required to crash it and: (gdb) bt And you should have better backtrace. Although it seems to be coming from the filter extension by looking at the current backtrace, it's easier to pinpoint the exact place when the debug symbols are around. [2007-08-23 10:03:39] jille at hexon dot cx Description: I have found these 2 lines in my syslog, this crash happens nearly a few times a day. Aug 23 10:37:00 hillsbrad crashdump[10305]: httpd crashed Aug 23 10:37:00 hillsbrad crashdump[10305]: crash report written to: /Library/Logs/CrashReporter/httpd.crash.log My website is being used by 400 users a day, on the 'crashing page' several images can be uploaded. Reproduce code: --- I tried to reproduce the crash, but it didn`t work out. I`ve added some debug code, some debuglines appear about 30 seconds before the crash. Some a few seconds after (they are not reported in the same way). It might also be that the debugging lines are not even reached. Expected result: I don`t know what exactly happens to the user on the website. I`ve never got any complaints about it or something. It could be a delayed crash or something (eg: the uploads create some buffer overflow, and apache crashes on the next request or something.) But I would expect not to see a crash happen Actual result: -- Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x310074f4 Thread 0 Crashed: 0 libphp5.so 0x022f2010 _zend_mm_free_int + 544 1 libphp5.so 0x02323808 zend_hash_destroy + 168 2 libphp5.so 0x023161b4 _zval_dtor_func + 164 3 libphp5.so 0x02304100 _zval_ptr_dtor + 80 4 libphp5.so 0x0207f4ec zm_deactivate_filter + 140 5 libphp5.so 0x0231a95c module_registry_cleanup + 44 6 libphp5.so 0x02323ce8 zend_hash_apply + 152 7 libphp5.so 0x02316c1c zend_deactivate_modules + 92 8 libphp5.so 0x022c1298 php_request_shutdown + 328 9 libphp5.so 0x023ca1cc apache_php_module_main + 236 10 libphp5.so 0x023cb8bc send_php + 1212 11 libphp5.so 0x023cb968 send_parsed_php + 56 12 httpd 0xdd18 ap_invoke_handler + 232 13 httpd 0x00017dd4 process_request_internal + 640 14 httpd 0x00017e54 ap_process_request + 72 15 httpd 0x6b60 child_main + 1832 16 httpd 0x6dc4 make_child + 312 17 httpd 0x7660 standalone_main + 852 18 httpd 0x7d74 main + 1052 19 httpd 0x238c _start + 348 20 httpd 0x222c start + 60 Thread 0 crashed with PPC Thread State 64: srr0: 0x022f2010 srr1: 0x1200f030 vrsave: 0x cr: 0x48000448 xer: 0x lr: 0x022f1e90 ctr: 0x3ddc r0: 0x r1: 0xbfffe220 r2: 0x0001 r3: 0x0185e800 r4: 0x002c74b0 r5: 0x0002 r6: 0x002c74a8 r7: 0x r8: 0x0010 r9: 0x002c74e8 r10: 0x002c74e8 r11: 0x310074e8 r12: 0x3ddc r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x00057314 r23: 0x00057314 r24: 0x00057314 r25: 0x00057314 r26: 0x0187a638 r27: 0x0231a930 r28: 0x0185e800 r29: 0x0040 r30: 0x002c74a8 r31: 0x022f1e04 Binary Images Description: 0x1000 -0x4 httpd /usr/sbin/httpd 0x65000 -0x67fff mod_log_config.so /usr/libexec/httpd/mod_log_config.so 0x6a000 -0x6bfff mod_mime.so /usr/libexec/httpd/mod_mime.so 0x6e000 -0x70fff mod_status.so /usr/libexec/httpd/mod_status.so
#42395 [Fbk->Opn]: httpd crashes near file uploading
ID: 42395 User updated by: jille at hexon dot cx Reported By: jille at hexon dot cx -Status: Feedback +Status: Open Bug Type: Apache related Operating System: MacOS 10.4.9 PHP Version: 5.2.3 New Comment: true, but I can't reproduce it on my dev server... Previous Comments: [2007-08-23 11:46:12] [EMAIL PROTECTED] Nobody asked you to run it on live site.. [2007-08-23 11:33:40] jille at hexon dot cx I can't run 5.2.4-dev in gdb on a live server. That will slow down about 1000+ sites i`m hosting. But I will try to run one server without Zend extensions. Let`s see whether I still get crashes on that one [2007-08-23 10:26:12] [EMAIL PROTECTED] First get the latst 5.2.4-dev snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz Then compile it with using --enable-debug in your configure line. Before you launch Apache, disable all Zend extensions in your php.ini. Run Apache under GDB: # gdb --arg httpd -X (gdb) run Then do the things required to crash it and: (gdb) bt And you should have better backtrace. Although it seems to be coming from the filter extension by looking at the current backtrace, it's easier to pinpoint the exact place when the debug symbols are around. [2007-08-23 10:03:39] jille at hexon dot cx Description: I have found these 2 lines in my syslog, this crash happens nearly a few times a day. Aug 23 10:37:00 hillsbrad crashdump[10305]: httpd crashed Aug 23 10:37:00 hillsbrad crashdump[10305]: crash report written to: /Library/Logs/CrashReporter/httpd.crash.log My website is being used by 400 users a day, on the 'crashing page' several images can be uploaded. Reproduce code: --- I tried to reproduce the crash, but it didn`t work out. I`ve added some debug code, some debuglines appear about 30 seconds before the crash. Some a few seconds after (they are not reported in the same way). It might also be that the debugging lines are not even reached. Expected result: I don`t know what exactly happens to the user on the website. I`ve never got any complaints about it or something. It could be a delayed crash or something (eg: the uploads create some buffer overflow, and apache crashes on the next request or something.) But I would expect not to see a crash happen Actual result: -- Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x310074f4 Thread 0 Crashed: 0 libphp5.so 0x022f2010 _zend_mm_free_int + 544 1 libphp5.so 0x02323808 zend_hash_destroy + 168 2 libphp5.so 0x023161b4 _zval_dtor_func + 164 3 libphp5.so 0x02304100 _zval_ptr_dtor + 80 4 libphp5.so 0x0207f4ec zm_deactivate_filter + 140 5 libphp5.so 0x0231a95c module_registry_cleanup + 44 6 libphp5.so 0x02323ce8 zend_hash_apply + 152 7 libphp5.so 0x02316c1c zend_deactivate_modules + 92 8 libphp5.so 0x022c1298 php_request_shutdown + 328 9 libphp5.so 0x023ca1cc apache_php_module_main + 236 10 libphp5.so 0x023cb8bc send_php + 1212 11 libphp5.so 0x023cb968 send_parsed_php + 56 12 httpd 0xdd18 ap_invoke_handler + 232 13 httpd 0x00017dd4 process_request_internal + 640 14 httpd 0x00017e54 ap_process_request + 72 15 httpd 0x6b60 child_main + 1832 16 httpd 0x6dc4 make_child + 312 17 httpd 0x7660 standalone_main + 852 18 httpd 0x7d74 main + 1052 19 httpd 0x238c _start + 348 20 httpd 0x222c start + 60 Thread 0 crashed with PPC Thread State 64: srr0: 0x022f2010 srr1: 0x1200f030 vrsave: 0x cr: 0x48000448 xer: 0x lr: 0x022f1e90 ctr: 0x3ddc r0: 0x r1: 0xbfffe220 r2: 0x0001 r3: 0x0185e800 r4: 0x002c74b0 r5: 0x0002 r6: 0x002c74a8 r7: 0x r8: 0x0010 r9: 0x002c74e8 r10: 0x002c74e8 r11: 0x310074e8 r12: 0x3ddc r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x00057314 r23: 0x00057314 r24: 0x00057314 r25: 0x00057314 r26: 0x0187a638 r27: 0x0231a930 r28: 0x0185e800 r29: 0x0040 r30: 0x002c74a8 r31: 0x022f1e04 Binary Images Description: 0x1000 -0x4 httpd /usr/sbin/httpd 0x65000 -0x67fff mod_log_config.so /usr/libexe
#42395 [Fbk->Opn]: httpd crashes near file uploading
ID: 42395 User updated by: jille at hexon dot cx Reported By: jille at hexon dot cx -Status: Feedback +Status: Open Bug Type: Apache related Operating System: MacOS 10.4.9 PHP Version: 5.2.3 New Comment: I can't run 5.2.4-dev in gdb on a live server. That will slow down about 1000+ sites i`m hosting. But I will try to run one server without Zend extensions. Let`s see whether I still get crashes on that one Previous Comments: [2007-08-23 10:26:12] [EMAIL PROTECTED] First get the latst 5.2.4-dev snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz Then compile it with using --enable-debug in your configure line. Before you launch Apache, disable all Zend extensions in your php.ini. Run Apache under GDB: # gdb --arg httpd -X (gdb) run Then do the things required to crash it and: (gdb) bt And you should have better backtrace. Although it seems to be coming from the filter extension by looking at the current backtrace, it's easier to pinpoint the exact place when the debug symbols are around. [2007-08-23 10:03:39] jille at hexon dot cx Description: I have found these 2 lines in my syslog, this crash happens nearly a few times a day. Aug 23 10:37:00 hillsbrad crashdump[10305]: httpd crashed Aug 23 10:37:00 hillsbrad crashdump[10305]: crash report written to: /Library/Logs/CrashReporter/httpd.crash.log My website is being used by 400 users a day, on the 'crashing page' several images can be uploaded. Reproduce code: --- I tried to reproduce the crash, but it didn`t work out. I`ve added some debug code, some debuglines appear about 30 seconds before the crash. Some a few seconds after (they are not reported in the same way). It might also be that the debugging lines are not even reached. Expected result: I don`t know what exactly happens to the user on the website. I`ve never got any complaints about it or something. It could be a delayed crash or something (eg: the uploads create some buffer overflow, and apache crashes on the next request or something.) But I would expect not to see a crash happen Actual result: -- Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x310074f4 Thread 0 Crashed: 0 libphp5.so 0x022f2010 _zend_mm_free_int + 544 1 libphp5.so 0x02323808 zend_hash_destroy + 168 2 libphp5.so 0x023161b4 _zval_dtor_func + 164 3 libphp5.so 0x02304100 _zval_ptr_dtor + 80 4 libphp5.so 0x0207f4ec zm_deactivate_filter + 140 5 libphp5.so 0x0231a95c module_registry_cleanup + 44 6 libphp5.so 0x02323ce8 zend_hash_apply + 152 7 libphp5.so 0x02316c1c zend_deactivate_modules + 92 8 libphp5.so 0x022c1298 php_request_shutdown + 328 9 libphp5.so 0x023ca1cc apache_php_module_main + 236 10 libphp5.so 0x023cb8bc send_php + 1212 11 libphp5.so 0x023cb968 send_parsed_php + 56 12 httpd 0xdd18 ap_invoke_handler + 232 13 httpd 0x00017dd4 process_request_internal + 640 14 httpd 0x00017e54 ap_process_request + 72 15 httpd 0x6b60 child_main + 1832 16 httpd 0x6dc4 make_child + 312 17 httpd 0x7660 standalone_main + 852 18 httpd 0x7d74 main + 1052 19 httpd 0x238c _start + 348 20 httpd 0x222c start + 60 Thread 0 crashed with PPC Thread State 64: srr0: 0x022f2010 srr1: 0x1200f030 vrsave: 0x cr: 0x48000448 xer: 0x lr: 0x022f1e90 ctr: 0x3ddc r0: 0x r1: 0xbfffe220 r2: 0x0001 r3: 0x0185e800 r4: 0x002c74b0 r5: 0x0002 r6: 0x002c74a8 r7: 0x r8: 0x0010 r9: 0x002c74e8 r10: 0x002c74e8 r11: 0x310074e8 r12: 0x3ddc r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x00057314 r23: 0x00057314 r24: 0x00057314 r25: 0x00057314 r26: 0x0187a638 r27: 0x0231a930 r28: 0x0185e800 r29: 0x0040 r30: 0x002c74a8 r31: 0x022f1e04 Binary Images Description: 0x1000 -0x4 httpd /usr/sbin/httpd 0x65000 -0x67fff mod_log_config.so /usr/libexec/httpd/mod_log_config.so 0x6a000 -0x6bfff mod_mime.so /usr/libexec/httpd/mod_mime.so 0x6e000 -0x70fff mod_status.so /usr/libexec/httpd/mod_status.so 0x73000 -0x75fff mod_info.so /usr/libexec/httpd/mod_info.so 0x78000 -0x81fff mod_rewrite.so /usr/libexec/httpd/mod_rewrite.so 0x85000 -0x
#42396 [NEW]: Followup to #36711: __halt_compiler() and unicode detection
From: francois at tekwire dot net Operating system: all PHP version: 5.2.3 PHP Bug Type: Unicode Engine related Bug description: Followup to #36711: __halt_compiler() and unicode detection Description: Reopening bug #36711 because it is NOT a documentation problem. Setting 'detect_unicode=Off' is NOT a solution, just a workaround. In practice, because of this bug, PHK or PHAR packages cannot run on zend-multibyte-enabled environments, unless detect_unicode is turned off. Which makes them unusable in environments running unicode-encoded scripts. As a side effect, it also makes it impossible to include an unicode-encoded script inside a PHAR/PHK package, as it cannot be run. There is no logical reason to bind the __halt_compiler() feature with the zend-multibyte unicode detection capability. Everything after an __halt_compiler() directive must be considered as binary data and should not be scanned for unicode detection. If this data contains a unicode script, it will be scanned and detected when include()d through the stream wrapper. My (humble) suggestions to fix the problem: In zend_multibyte_detect_unicode(), the BOM detection does not have to be modified but, then, the script is scanned for null bytes : return zend_multibyte_detect_utf_encoding(LANG_SCNG(script_org), LANG_SCNG(script_org_size) TSRMLS_CC); There, the size should not be LANG_SCNG(script_org_size), but the offset of the __halt_compiler() directive. But I don't know where to find the COMPILER_HALT_OFFSET constant for the script. I even suspect it not to be available at this time... Another way, if the previous one is not possible, would be to scan for a binary string that cannot correspond to any unicode encoding. This way, PHK and PHAR could insert this string after ther __halt_compiler() directive, and it could be detected by zend_multibyte_detect_utf_encoding() as a stop string. I am ready to implement it if somebody provides a sequence of bytes that cannot be found in any unicode-encoded document. Reproduce code: --- Expected result: OK Actual result: -- ?? -- Edit bug report at http://bugs.php.net/?id=42396&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42396&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42396&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42396&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42396&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42396&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42396&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42396&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42396&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42396&r=support Expected behavior:http://bugs.php.net/fix.php?id=42396&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42396&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42396&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42396&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42396&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42396&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42396&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42396&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42396&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42396&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42396&r=mysqlcfg
#42389 [Fbk->Opn]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389
User updated by: webmaster at machostlink dot net
Reported By: webmaster at machostlink dot net
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: OSX 10.4.10
PHP Version: 5.2.3
New Comment:
Yeah I saw the news "PHP 4 end of life announcement" and I know that
bug reports for it probably won't be fixed unless they are critical
issues. I find it funny that both PHP versions are behaving like
that...
I checked the PHP config for this vhost again and again and tried
different settings:
Right now I have:
--
max_execution_time = 60
max_input_time = 120
memory_limit = 64M
error_reporting = E_ALL & ~E_NOTICE
display_errors = On
log_errors = On
log_errors_max_len = 1024
But even after some testing now, still no PHP error.log to be seen!?
Previous Comments:
[2007-08-23 12:01:53] [EMAIL PROTECTED]
Regarding any PHP 4 fixes, see php.net for latest NEWS: "PHP 4 end of
life announcement"
This isn't any critical issue so it's very unlikely it will get fixed
in PHP 4 (even if there were any more releases of PHP 4..)
And I still think this isn't PHP bug. Do you know if PHP is outputting
any errors? Do you have logging enabled? Are you sure you haven't hit
any limits set in php.ini for max size for uploaded file for example..?
[2007-08-23 11:41:18] webmaster at machostlink dot net
Ok, I checked the latest CVS snapshot but the problem still remains the
same.
I forgot to mention in my inital post that I am using Apache2 with
mod_suexec for permissions. But that seems to work fine according to
suexec.log and apache2 error.log files. Thought I mention it now anyway
just in case.
[2007-08-23 09:13:53] webmaster at lifedit dot com
Right, I was taken that already in consideration and posted a report on
"mod_fcgid users bug tracker" as well. But looking at the history of
somewhat related php-cgi problems and bug reported I think it is more
likely to be a PHP bug.
My problem is that I have a hosting service and I rely on both PHP5 &
PHP4 because I do have clients who still have PHP4 applications they
want to run. So even if it does work with the latest CVS (which I will
try out) I still have a need for this feature to run on PHP4 as well. :(
[2007-08-23 09:06:04] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce anything like this, even when uploading quite large
files so try the snapshot first. (any possibility that this isn't any
PHP bug at all..? :)
[2007-08-22 20:39:33] webmaster at machostlink dot net
Description:
When using a simple upload form to submit a file, all php4-cgi &
php5-cgi processes (parent & children) are killed and server throws "500
Internal Server Error" message. This happens ONLY when filesize is
larger then 4KB.
Apache error.log from vhost
---
[warn] (35)Resource temporarily unavailable: mod_fcgid: write data to
fastcgi server error
Apache error.log from main/default server
-
mod_fcgid: process /Volumes/home/www/vhost1/public_html/test.php(2293)
exit(communication error), terminated by calling exit(), return code: 0
I am not sure now, after reading other (older) bug reports regarding
cgi problems, if this is not an older issue as well!? However, since I
could not find many similarities to these posts I decided to file this
one.
I am running PHP 4.4.7 & PHP 5.2.3 as CGI using mod_fcgid 2.2 and
Apache 2.2.4
Reproduce code:
---
';
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile))
{
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "Possible file upload attack!\n";
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print "";
?>
Send this file:
Expected result:
File is valid, and was successfully uploaded.
Here is some more debugging info:Array
(
[userfile] => Array
(
[name] => test.jpg
[type] => image/jpeg
[tmp_name] => /Volumes/home/www/vhost1/tmp/phpcYOdvd
[error] => 0
[size] => 24852930
)
)
Actual result:
--
Error 500
Internal Server Error
...
--
Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42398 [NEW]: pg_(p)connect produces uninformative error messages
From: webmaster at touchingvirus dot net Operating system: Windows PHP version: 5.2.3 PHP Bug Type: Feature/Change Request Bug description: pg_(p)connect produces uninformative error messages Description: When connecting to a pgSQL server (I use 8.2) with a wrong username, password or port in the connection string, the error given is really uninformative to the user and actually suggests a problem with the postgreSQL server: "Unable to connect to PostgreSQL server: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request." The server didn't terminate & the connection was refused/aborted Expected result: To be honest, I expected an error that was similar to that of mySQL - though I know that is because mySQL actually produces good error messages =) e.g. Access denied for: [EMAIL PROTECTED] (Using Password: YES) The psql binary errors with the expect errors like: psql: FATAL: password authentication failed for user "root" -- Edit bug report at http://bugs.php.net/?id=42398&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42398&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42398&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42398&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42398&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42398&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42398&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42398&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42398&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42398&r=support Expected behavior:http://bugs.php.net/fix.php?id=42398&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42398&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42398&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42398&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42398&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42398&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42398&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42398&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42398&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42398&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42398&r=mysqlcfg
#42396 [Opn]: Followup to #36711: __halt_compiler() and unicode detection
ID: 42396 Updated by: [EMAIL PROTECTED] Reported By: francois at tekwire dot net Status: Open Bug Type: mbstring related Operating System: all PHP Version: 5.2.3 New Comment: Reclassified: There is no unicode in PHP 5. Just mbstring. Previous Comments: [2007-08-23 12:16:17] francois at tekwire dot net Description: Reopening bug #36711 because it is NOT a documentation problem. Setting 'detect_unicode=Off' is NOT a solution, just a workaround. In practice, because of this bug, PHK or PHAR packages cannot run on zend-multibyte-enabled environments, unless detect_unicode is turned off. Which makes them unusable in environments running unicode-encoded scripts. As a side effect, it also makes it impossible to include an unicode-encoded script inside a PHAR/PHK package, as it cannot be run. There is no logical reason to bind the __halt_compiler() feature with the zend-multibyte unicode detection capability. Everything after an __halt_compiler() directive must be considered as binary data and should not be scanned for unicode detection. If this data contains a unicode script, it will be scanned and detected when include()d through the stream wrapper. My (humble) suggestions to fix the problem: In zend_multibyte_detect_unicode(), the BOM detection does not have to be modified but, then, the script is scanned for null bytes : return zend_multibyte_detect_utf_encoding(LANG_SCNG(script_org), LANG_SCNG(script_org_size) TSRMLS_CC); There, the size should not be LANG_SCNG(script_org_size), but the offset of the __halt_compiler() directive. But I don't know where to find the COMPILER_HALT_OFFSET constant for the script. I even suspect it not to be available at this time... Another way, if the previous one is not possible, would be to scan for a binary string that cannot correspond to any unicode encoding. This way, PHK and PHAR could insert this string after ther __halt_compiler() directive, and it could be detected by zend_multibyte_detect_utf_encoding() as a stop string. I am ready to implement it if somebody provides a sequence of bytes that cannot be found in any unicode-encoded document. Reproduce code: --- Expected result: OK Actual result: -- ?? -- Edit this bug report at http://bugs.php.net/?id=42396&edit=1
#42395 [Opn->Fbk]: httpd crashes near file uploading
ID: 42395 Updated by: [EMAIL PROTECTED] Reported By: jille at hexon dot cx -Status: Open +Status: Feedback Bug Type: Apache related Operating System: MacOS 10.4.9 PHP Version: 5.2.3 New Comment: So it crashes but you can't build a debug version of PHP for your live site to get better backtraces so that we could actually fix it and you don't know how to reproduce it reliably..quite a chicken'n'egg problem here. :) Previous Comments: [2007-08-23 11:48:36] jille at hexon dot cx true, but I can't reproduce it on my dev server... [2007-08-23 11:46:12] [EMAIL PROTECTED] Nobody asked you to run it on live site.. [2007-08-23 11:33:40] jille at hexon dot cx I can't run 5.2.4-dev in gdb on a live server. That will slow down about 1000+ sites i`m hosting. But I will try to run one server without Zend extensions. Let`s see whether I still get crashes on that one [2007-08-23 10:26:12] [EMAIL PROTECTED] First get the latst 5.2.4-dev snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz Then compile it with using --enable-debug in your configure line. Before you launch Apache, disable all Zend extensions in your php.ini. Run Apache under GDB: # gdb --arg httpd -X (gdb) run Then do the things required to crash it and: (gdb) bt And you should have better backtrace. Although it seems to be coming from the filter extension by looking at the current backtrace, it's easier to pinpoint the exact place when the debug symbols are around. [2007-08-23 10:03:39] jille at hexon dot cx Description: I have found these 2 lines in my syslog, this crash happens nearly a few times a day. Aug 23 10:37:00 hillsbrad crashdump[10305]: httpd crashed Aug 23 10:37:00 hillsbrad crashdump[10305]: crash report written to: /Library/Logs/CrashReporter/httpd.crash.log My website is being used by 400 users a day, on the 'crashing page' several images can be uploaded. Reproduce code: --- I tried to reproduce the crash, but it didn`t work out. I`ve added some debug code, some debuglines appear about 30 seconds before the crash. Some a few seconds after (they are not reported in the same way). It might also be that the debugging lines are not even reached. Expected result: I don`t know what exactly happens to the user on the website. I`ve never got any complaints about it or something. It could be a delayed crash or something (eg: the uploads create some buffer overflow, and apache crashes on the next request or something.) But I would expect not to see a crash happen Actual result: -- Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x310074f4 Thread 0 Crashed: 0 libphp5.so 0x022f2010 _zend_mm_free_int + 544 1 libphp5.so 0x02323808 zend_hash_destroy + 168 2 libphp5.so 0x023161b4 _zval_dtor_func + 164 3 libphp5.so 0x02304100 _zval_ptr_dtor + 80 4 libphp5.so 0x0207f4ec zm_deactivate_filter + 140 5 libphp5.so 0x0231a95c module_registry_cleanup + 44 6 libphp5.so 0x02323ce8 zend_hash_apply + 152 7 libphp5.so 0x02316c1c zend_deactivate_modules + 92 8 libphp5.so 0x022c1298 php_request_shutdown + 328 9 libphp5.so 0x023ca1cc apache_php_module_main + 236 10 libphp5.so 0x023cb8bc send_php + 1212 11 libphp5.so 0x023cb968 send_parsed_php + 56 12 httpd 0xdd18 ap_invoke_handler + 232 13 httpd 0x00017dd4 process_request_internal + 640 14 httpd 0x00017e54 ap_process_request + 72 15 httpd 0x6b60 child_main + 1832 16 httpd 0x6dc4 make_child + 312 17 httpd 0x7660 standalone_main + 852 18 httpd 0x7d74 main + 1052 19 httpd 0x238c _start + 348 20 httpd 0x222c start + 60 Thread 0 crashed with PPC Thread State 64: srr0: 0x022f2010 srr1: 0x1200f030 vrsave: 0x cr: 0x48000448 xer: 0x lr: 0x022f1e90 ctr: 0x3ddc r0: 0x r1: 0xbfffe220 r2: 0x0001 r3: 0x0185e800 r4: 0x002c74b0 r5: 0x0002 r6: 0x002c74a8 r7: 0x r8: 0x0010 r9: 0x002c74e8 r10: 0x002c74e8 r11: 0x310074e8 r12: 0x3ddc r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x00057314 r23: 0x000573
#42389 [Opn->Fbk]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389 Updated by: [EMAIL PROTECTED] Reported By: webmaster at machostlink dot net -Status: Open +Status: Feedback Bug Type: CGI related Operating System: OSX 10.4.10 PHP Version: 5.2.3 New Comment: You forgot to set 'error_log = /path/to/php_error.log' Previous Comments: [2007-08-23 12:25:06] webmaster at machostlink dot net Yeah I saw the news "PHP 4 end of life announcement" and I know that bug reports for it probably won't be fixed unless they are critical issues. I find it funny that both PHP versions are behaving like that... I checked the PHP config for this vhost again and again and tried different settings: Right now I have: -- max_execution_time = 60 max_input_time = 120 memory_limit = 64M error_reporting = E_ALL & ~E_NOTICE display_errors = On log_errors = On log_errors_max_len = 1024 But even after some testing now, still no PHP error.log to be seen!? [2007-08-23 12:01:53] [EMAIL PROTECTED] Regarding any PHP 4 fixes, see php.net for latest NEWS: "PHP 4 end of life announcement" This isn't any critical issue so it's very unlikely it will get fixed in PHP 4 (even if there were any more releases of PHP 4..) And I still think this isn't PHP bug. Do you know if PHP is outputting any errors? Do you have logging enabled? Are you sure you haven't hit any limits set in php.ini for max size for uploaded file for example..? [2007-08-23 11:41:18] webmaster at machostlink dot net Ok, I checked the latest CVS snapshot but the problem still remains the same. I forgot to mention in my inital post that I am using Apache2 with mod_suexec for permissions. But that seems to work fine according to suexec.log and apache2 error.log files. Thought I mention it now anyway just in case. [2007-08-23 09:13:53] webmaster at lifedit dot com Right, I was taken that already in consideration and posted a report on "mod_fcgid users bug tracker" as well. But looking at the history of somewhat related php-cgi problems and bug reported I think it is more likely to be a PHP bug. My problem is that I have a hosting service and I rely on both PHP5 & PHP4 because I do have clients who still have PHP4 applications they want to run. So even if it does work with the latest CVS (which I will try out) I still have a need for this feature to run on PHP4 as well. :( [2007-08-23 09:06:04] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi I can't reproduce anything like this, even when uploading quite large files so try the snapshot first. (any possibility that this isn't any PHP bug at all..? :) 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/42389 -- Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42393 [Asn]: mb_strtoupper is replacing one of the cyrillic symbols with wrong one.
ID: 42393 User updated by: ivan dot delchev at softconsultgroup dot com Reported By: ivan dot delchev at softconsultgroup dot com Status: Assigned Bug Type: mbstring related Operating System: Windows XP PHP Version: 5.2.3 Assigned To: hirokawa New Comment: [mbstring] ; language for internal character representation. ;mbstring.language = Japanese ; internal/script encoding. ; Some encoding cannot work as internal encoding. ; (e.g. SJIS, BIG5, ISO-2022-*) ;mbstring.internal_encoding = EUC-JP ; http input encoding. ;mbstring.http_input = auto ; http output encoding. mb_output_handler must be ; registered as output buffer to function ;mbstring.http_output = SJIS ; enable automatic encoding translation according to ; mbstring.internal_encoding setting. Input chars are ; converted to internal encoding by setting this to On. ; Note: Do _not_ use automatic encoding translation for ; portable libs/applications. ;mbstring.encoding_translation = Off ; automatic encoding detection order. ; auto means ;mbstring.detect_order = auto ; substitute_character used when character cannot be converted ; one from another ;mbstring.substitute_character = none; ; overload(replace) single byte functions by mbstring functions. ; mail(), ereg(), etc are overloaded by mb_send_mail(), mb_ereg(), ; etc. Possible values are 0,1,2,4 or combination of them. ; For example, 7 for overload everything. ; 0: No overload ; 1: Overload mail() function ; 2: Overload str*() functions ; 4: Overload ereg*() functions ;mbstring.func_overload = 0 ; enable strict encoding detection. ;mbstring.strict_encoding = Off Previous Comments: [2007-08-23 14:30:54] [EMAIL PROTECTED] Please show me mbstring.language setting in php.ini. [2007-08-23 09:06:53] [EMAIL PROTECTED] Assigned to mbstring maintainer. [2007-08-23 08:06:01] ivan dot delchev at softconsultgroup dot com Description: mb_strtoupper is doind wrong transformation for "å" in cyrillic alphabetic. Whe wrong transformation "å"->"í". Also the function is not UPPER the string! Reproduce code: --- // Ensure that the web browser encoding is UTF8 and edit application is UTF8 compatible! $main_string = "Òîâà å òåñò. Îòíîâî Òåñò. Êàêâî áè ñå ïîëó÷èëî ñ òîçè ÒÅÑÒ äà âèäèì!"; var_dump($main_string); var_dump(mb_strtoupper($main_string)); Expected result: Dumped result to be the same. And second string to be UPPER! Actual result: -- string(120) "Òîâà å òåñò. Îòíîâî Òåñò. Êàêâî áè ñå ïîëó÷èëî ñ òîçè ÒÅÑÒ äà âèäèì!" string(120) "Òîâà ï òïñò. Îòíîâî Òïñò. Êàêâî áè ñï ïîëó÷èëî ñ òîçè ÒÅÑÒ äà âèäèì!" -- Edit this bug report at http://bugs.php.net/?id=42393&edit=1
#24679 [Com]: pg_insert problem!
ID: 24679
Comment by: frank at geo-dienstleistung dot de
Reported By: rorezende at hotmail dot com
Status: No Feedback
Bug Type: PostgreSQL related
Operating System: *
PHP Version: 4.3.2
Assigned To: helly
New Comment:
This seems to be true for more than only pg_insert() function. The same
error rises when pg_convert() is called with schema in front of table
name. So I suspect without testing, that pg_update() and pg_delete
suffer from the same bug.
Previous Comments:
[2007-08-23 10:42:10] frank at geo-dienstleistung dot de
I can confirm this bug on php 5.2.1 too. It really makes this function
pretty much useless.
[2007-03-14 16:07:04] pentropia at gmail dot com
Iv'e noticed the same problem on php 5.2.1
[2005-09-21 05:04:00] nathanr at nathanr dot net
Nope, this is a genuine bug, I've tested on SuSE Linux Professional 9.3
using both PHP 4.3.10 and 5.0.3 against PostgreSQL 8.0.3. They both
produce non-working results. To replicate the bug:
test.sql:
create schema tstschma;
create table tstschma.tsttbl (
x int not null,
y int not null,
primary key (x)
);
now try this php:
$db = pg_connect("dbname=testdb");
$l = array('x'=>'1', 'y'=>'2');
pg_insert($db, "tstschma.tsttbl", $l);
pg_close($db);
If you remove the schema (tstschma) from the name then the select
works, but the insert of course does not.
The problem stems from the fact that pg_class.relname does not include
the schema name, but to run a query against the table you must have the
schema name. I suggest your fix is to strip everything before and
including the last dot in the table name (won't change anything for
those not using schemas, but will strip "tstschma." from the above
example), but use the table name passed to the method (ie. including the
"tstschma.") when you go to do the insert.
[2005-09-21 05:03:41] nathanr at nathanr dot net
Nope, this is a genuine bug, I've tested on SuSE Linux Professional 9.3
using both PHP 4.3.10 and 5.0.3 against PostgreSQL 8.0.3. They both
produce non-working results. To replicate the bug:
test.sql:
create schema tstschma;
create table tstschma.tsttbl (
x int not null,
y int not null,
primary key (x)
);
now try this php:
$db = pg_connect("dbname=testdb");
$l = array('x'=>'1', 'y'=>'2');
pg_insert($db, "tstschma.tsttbl", $l);
pg_close($db);
If you remove the schema (tstschma) from the name then the select
works, but the insert of course does not.
The problem stems from the fact that pg_class.relname does not include
the schema name, but to run a query against the table you must have the
schema name. I suggest your fix is to strip everything before and
including the last dot in the table name (won't change anything for
those not using schemas, but will strip "tstschma." from the above
example), but use the table name passed to the method (ie. including the
"tstschma.") when you go to do the insert.
[2003-07-23 22:30:19] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". 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/24679
--
Edit this bug report at http://bugs.php.net/?id=24679&edit=1
#42318 [Opn->Asn]: problem with nm not finding object files
ID: 42318 Updated by: [EMAIL PROTECTED] Reported By: rainer dot tammer at schulergroup dot com -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: AIX 5.2/5.3 PHP Version: 5.2CVS-2007-08-17 Assigned To: dmitry New Comment: Dmitry, can you give some info about why you reverted your fix? Previous Comments: [2007-08-23 10:54:55] rainer dot tammer at schulergroup dot com Hello, this was only a general note on the system. It has nothing todo with the bug. This build uses the bundled libtool. Bye Rainer [2007-08-23 10:46:58] [EMAIL PROTECTED] About libtool: PHP does not use any external libtool unless you force it to do it..so are you doing something you shouldn't be doing? :) PHP uses the bundled libtool version 1.5.20. [2007-08-23 06:07:20] rainer dot tammer at schulergroup dot com Hello, just a quick note: The fix to the two config files (sapi/cgi/config9.m4 / sapi/cli/config.m4) only affects AIX !! Bye Rainer [2007-08-22 15:49:07] rainer dot tammer at schulergroup dot com Hello, yes nm -BCpg does not find the files. With the suggested fix nm does find all necessary file an works OK. I have tested the fix on AIX 5.2 and AIX 5.3 with IBM XL C/C++ 8.0 and gcc 3.3. Bye Rainer [2007-08-22 15:33:07] [EMAIL PROTECTED] So this is just a warning from AIX nm? PHP builds and runs ok after that, am I right? 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/42318 -- Edit this bug report at http://bugs.php.net/?id=42318&edit=1
#40661 [Opn->Asn]: cwd is reset when shutdown handler runs
ID: 40661 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned -Bug Type: *General Issues +Bug Type: Apache related Operating System: Linux PHP Version: 5.2.3, 4.4.7 -Assigned To: +Assigned To: jani Previous Comments: [2007-07-11 12:35:37] [EMAIL PROTECTED] Making sure this doesn't slip through the cracks..also found in PHP 5.2 [2007-02-27 15:00:13] [EMAIL PROTECTED] I disagree, there is no reason why PHP can't reset the CWD to the correct directory when a shutdown handler is run. That is what I would expect to happen. [2007-02-27 14:54:34] [EMAIL PROTECTED] See http://bugs.php.net/bug.php?id=36529 [2007-02-27 14:44:41] [EMAIL PROTECTED] Description: When this script is run with the Apache1 sapi the second CWD is reset to /. This is an issue for both php 4.4.4 and php 5.2.1rc3. Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=40661&edit=1
#41996 [Opn->Asn]: PDO_OCI: Problem accessing Oracle ROWID
ID: 41996
Updated by: [EMAIL PROTECTED]
Reported By: tsedeke at feigenblatt dot de
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: Suse Enterprise Server 9
PHP Version: 5.2.3
-Assigned To:
+Assigned To: sixd
New Comment:
Assigned to the PDO OCI driver maintainer.
Previous Comments:
[2007-07-14 14:45:08] tsedeke at feigenblatt dot de
Description:
Getting error accessing the oracle rowid in a PDO select statement.
The NLS_LANG is set to AMERICAN_AMERICA.AL32UTF8 same as the database.
I also restartet the Apache2.2 with the php as module, to be sure it
take the right parameters.
Reproduce code:
---
$db_username = "elements";
$db_password = "elements";
$db = "oci:dbname=XE;charset=AL32UTF8";
$conn = new PDO($db,$db_username,$db_password);
$stmt = $conn->prepare("SELECT rowid,t1,t2 FROM test");
$stmt->execute();
while ($row = $stmt->fetch()) {
print_r($row);
}
Expected result:
Array ( [ROWID] => AAADVUAAEFMAAA [0] => AAADVUAAEFMAAA [T1] =>
test1 [1] => test1 [T2] => First test [2] => First test )
Actual result:
--
Warning: PDOStatement::fetch() [function.PDOStatement-fetch]: column 0
data was too large for buffer and was truncated to fit it
--
Edit this bug report at http://bugs.php.net/?id=41996&edit=1
#42399 [NEW]: myqli_query causes error after calling mysql procedures
From: mfeldheim at gmail dot com
Operating system: Linux Debian
PHP version: 5.2.3
PHP Bug Type: MySQLi related
Bug description: myqli_query causes error after calling mysql procedures
Description:
After calling a mysql stored procedure with mysqli_query I get the error
"Commands out of sync; you can't run this command now" with the following
mysqli_query execution.
That is independent from mysqli_query resultmode parameter or a postquery
$result->close();
In my case the mysql procedure returns a resultset - didnt test for the
case of no resultset
Reproduce code:
---
$mysqli = new mysqli($host, $user, $password, $database);
$result = $mysqli->query('CALL mysql_stored_procedure(abc)');
if( $mysqli->errno ) die( $mysqli->error );
while( $data = $result->fetch_object() ):
print_r( $data );
endwhile;
$result->close();
$result = $mysqli->query('SELECT column1, column2 FROM table WHERE id =
1');
if( $mysqli->errno ) die( $mysqli->error );
while( $data = $result->fetch_object() ):
print_r( $data );
endwhile;
$result->close();
$mysqli->close();
Expected result:
mysqli_result (
resultset for the first query
)
mysqli_result (
resultset for the second query
)
Actual result:
--
mysqli_result (
resultset for the first query
)
Commands out of sync; you can't run this command now
--
Edit bug report at http://bugs.php.net/?id=42399&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42399&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42399&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42399&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42399&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42399&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42399&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42399&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42399&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42399&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42399&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42399&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42399&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42399&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42399&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42399&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42399&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42399&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42399&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42399&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42399&r=mysqlcfg
#42399 [Opn->Bgs]: myqli_query causes error after calling mysql procedures
ID: 42399
Updated by: [EMAIL PROTECTED]
Reported By: mfeldheim at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: MySQLi related
Operating System: Linux Debian
PHP Version: 5.2.3
New Comment:
See bug #32882 and bug #35203
Previous Comments:
[2007-08-23 14:51:29] mfeldheim at gmail dot com
Description:
After calling a mysql stored procedure with mysqli_query I get the
error "Commands out of sync; you can't run this command now" with the
following mysqli_query execution.
That is independent from mysqli_query resultmode parameter or a
postquery $result->close();
In my case the mysql procedure returns a resultset - didnt test for the
case of no resultset
Reproduce code:
---
$mysqli = new mysqli($host, $user, $password, $database);
$result = $mysqli->query('CALL mysql_stored_procedure(abc)');
if( $mysqli->errno ) die( $mysqli->error );
while( $data = $result->fetch_object() ):
print_r( $data );
endwhile;
$result->close();
$result = $mysqli->query('SELECT column1, column2 FROM table WHERE id =
1');
if( $mysqli->errno ) die( $mysqli->error );
while( $data = $result->fetch_object() ):
print_r( $data );
endwhile;
$result->close();
$mysqli->close();
Expected result:
mysqli_result (
resultset for the first query
)
mysqli_result (
resultset for the second query
)
Actual result:
--
mysqli_result (
resultset for the first query
)
Commands out of sync; you can't run this command now
--
Edit this bug report at http://bugs.php.net/?id=42399&edit=1
#42374 [Fbk->Opn]: --as-needed bug - follow-up
ID: 42374
User updated by: galtgendo at o2 dot pl
Reported By: galtgendo at o2 dot pl
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: gentoo linux
PHP Version: 5.2.3
New Comment:
Well, that's incorrect.
PHP_CHECK_LIBRARY calls AC_CHECK_LIB.
without -Wl,--as-needed it does not matter whether libs are in LDFLAGS
or in LIBS, with that flag however all dependent libraries must appear
after the objects.
AC_CHECK_LIB does something like
i686-pc-linux-gnu-gcc -o conftest ${CFLAGS} ${LDFLAGS} conftest.c
${LIBS}
(more or less)
that check fails with --as-needed flag if lib is added to LDFLAGS
so it does not matter if it gets restored, cause the check already
failed - those are the false negatives I'm talking about.
All the other macros from the patch seem to do this, so that's why I
changed them. I'm not sure if something got broken, however it was
correct for the ext/ldap/config.m4 so there's at least a chance it will
work for the rest.
Previous Comments:
[2007-08-23 10:38:24] [EMAIL PROTECTED]
PHP_CHECK_LIBRARY restores the LDFLAGS after doing the test so it
shouldn't be any problem?
And bug #41973 was about ext/ldap and that was fixed.
I'd fix these case by case rather than blindly changing places unlikely
to even cause any problems.
[2007-08-22 15:40:41] galtgendo at o2 dot pl
Well, I'm not 100%, if I was, I would mentioned it, not asked for
futher testing.
And AFAIK that commit from bug #41973 was only
http://cvs.php.net/viewvc.cgi/php-src/ext/ldap/config.m4?r1=1.44&r2=1.45&diff_format=u
so only about ext/ldap/config.m4 (as in my patch).
What's more, although I can't recall if it made any difference you
should consider changes in acinclude.m4, cause in PHP_CHECK_LIBRARY
macro you were adding libraries to LDFLAGS instead of LIBS and that's
most common source of --as-needed bugs. That's why I'm talking about
false negatives - standard configure check would put those libraries in
wrong place and check would fail even if the library was OK.
[2007-08-22 14:46:27] [EMAIL PROTECTED]
And have you even tested what was committed in our CVS?
[2007-08-22 14:45:33] [EMAIL PROTECTED]
FYI: this is not bugzilla and it's not annoying. It's just old. :)
And about your patch..are you really sure you need to change all those
places?
[2007-08-22 10:30:40] galtgendo at o2 dot pl
As I don't see a way to attach anything here, I'll give you a link to
an old gentoo bug with my patch. It's
http://bugs.gentoo.org/show_bug.cgi?id=151444
It's an old bug so it still covers the part from the closed bug.
BTW your bugzilla is REALLY annoying.
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/42374
--
Edit this bug report at http://bugs.php.net/?id=42374&edit=1
#42389 [Fbk->Opn]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389 User updated by: webmaster at machostlink dot net Reported By: webmaster at machostlink dot net -Status: Feedback +Status: Open Bug Type: CGI related Operating System: OSX 10.4.10 PHP Version: 5.2.3 New Comment: Sorry I forgot to add that.. I had a path set but only the path not the filename. Well so this time PHP did create a log but nothing in it when the "500 Internal Error" occurs. Well how should it write into the log when all the processes are killed at once!? Previous Comments: [2007-08-23 14:13:52] [EMAIL PROTECTED] You forgot to set 'error_log = /path/to/php_error.log' [2007-08-23 12:25:06] webmaster at machostlink dot net Yeah I saw the news "PHP 4 end of life announcement" and I know that bug reports for it probably won't be fixed unless they are critical issues. I find it funny that both PHP versions are behaving like that... I checked the PHP config for this vhost again and again and tried different settings: Right now I have: -- max_execution_time = 60 max_input_time = 120 memory_limit = 64M error_reporting = E_ALL & ~E_NOTICE display_errors = On log_errors = On log_errors_max_len = 1024 But even after some testing now, still no PHP error.log to be seen!? [2007-08-23 12:01:53] [EMAIL PROTECTED] Regarding any PHP 4 fixes, see php.net for latest NEWS: "PHP 4 end of life announcement" This isn't any critical issue so it's very unlikely it will get fixed in PHP 4 (even if there were any more releases of PHP 4..) And I still think this isn't PHP bug. Do you know if PHP is outputting any errors? Do you have logging enabled? Are you sure you haven't hit any limits set in php.ini for max size for uploaded file for example..? [2007-08-23 11:41:18] webmaster at machostlink dot net Ok, I checked the latest CVS snapshot but the problem still remains the same. I forgot to mention in my inital post that I am using Apache2 with mod_suexec for permissions. But that seems to work fine according to suexec.log and apache2 error.log files. Thought I mention it now anyway just in case. [2007-08-23 09:13:53] webmaster at lifedit dot com Right, I was taken that already in consideration and posted a report on "mod_fcgid users bug tracker" as well. But looking at the history of somewhat related php-cgi problems and bug reported I think it is more likely to be a PHP bug. My problem is that I have a hosting service and I rely on both PHP5 & PHP4 because I do have clients who still have PHP4 applications they want to run. So even if it does work with the latest CVS (which I will try out) I still have a need for this feature to run on PHP4 as well. :( 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/42389 -- Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#34972 [Com]: STDIN won't allow nonblocking.
ID: 34972
Comment by: julian at precisium dot com dot au
Reported By: VJTD3 at VJTD3 dot com
Status: Open
Bug Type: Streams related
Operating System: *
PHP Version: php5.1-200603270630
Assigned To: wez
New Comment:
I'm having this problem on Vista x64 with PHP 5.2.3.
This is a real showstopper for certain types of CLI app - people can't
always be waiting for newlines or eofs to read their data.
I don't mean to be rude but I'm kinda shocked such a major bug has been
unaddressed for nearly 2 years. I guess it just means people aren't
really using PHP for CLI apps on the windows platform.
Previous Comments:
[2007-08-19 20:51:34] donnyk at gmail dot com
i also have the same problem, i've tried the latest snapshot on windows
to no avail. It works on my linux systems however.
[2007-08-10 13:01:48] VJTD3 at VJTD3 dot com
notice how it just sits there? (blocking) it should exit instantly with
a null echo. (same as a tcp connection where if you just do a read that
is too fast with nonblocking it never gets a chance to fetch the data.)
what is happening is that php is blocking waiting for input
(specifically enter (line ending))
problem:
if you are echoing debug information and want to use key functionality
in tandem you can't because everything is blocked till you hit enter.
[2007-07-25 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-07-17 14:28:03] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce this (or very likely didn't understand the problem :)
[2006-03-27 14:12:28] VJTD3 at VJTD3 dot com
error in last message, "stream_select()" was ment.
code using "stream_select()" that still blocks:
data: '.(strlen(@$data4) ? $data4 :
'empty')."\n";
unset($data4);
sleep('1');
}
?>
the second you type/click a arrow key/anything it goes into blocking
mode again.
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/34972
--
Edit this bug report at http://bugs.php.net/?id=34972&edit=1
#42396 [Opn]: Followup to #36711: __halt_compiler() and unicode detection
ID: 42396 User updated by: francois at tekwire dot net Reported By: francois at tekwire dot net Status: Open Bug Type: mbstring related Operating System: all PHP Version: 5.2.3 New Comment: Not sure it should be reclassified as mbstring related, as the bug is in Zend/zend_multibyte.c and has nothing to do with mbstring. PHP5 has a little unicode part in the engine. It even has an (undocumented) 'detect_unicode' option. Previous Comments: [2007-08-23 14:08:09] [EMAIL PROTECTED] Reclassified: There is no unicode in PHP 5. Just mbstring. [2007-08-23 12:16:17] francois at tekwire dot net Description: Reopening bug #36711 because it is NOT a documentation problem. Setting 'detect_unicode=Off' is NOT a solution, just a workaround. In practice, because of this bug, PHK or PHAR packages cannot run on zend-multibyte-enabled environments, unless detect_unicode is turned off. Which makes them unusable in environments running unicode-encoded scripts. As a side effect, it also makes it impossible to include an unicode-encoded script inside a PHAR/PHK package, as it cannot be run. There is no logical reason to bind the __halt_compiler() feature with the zend-multibyte unicode detection capability. Everything after an __halt_compiler() directive must be considered as binary data and should not be scanned for unicode detection. If this data contains a unicode script, it will be scanned and detected when include()d through the stream wrapper. My (humble) suggestions to fix the problem: In zend_multibyte_detect_unicode(), the BOM detection does not have to be modified but, then, the script is scanned for null bytes : return zend_multibyte_detect_utf_encoding(LANG_SCNG(script_org), LANG_SCNG(script_org_size) TSRMLS_CC); There, the size should not be LANG_SCNG(script_org_size), but the offset of the __halt_compiler() directive. But I don't know where to find the COMPILER_HALT_OFFSET constant for the script. I even suspect it not to be available at this time... Another way, if the previous one is not possible, would be to scan for a binary string that cannot correspond to any unicode encoding. This way, PHK and PHAR could insert this string after ther __halt_compiler() directive, and it could be detected by zend_multibyte_detect_utf_encoding() as a stop string. I am ready to implement it if somebody provides a sequence of bytes that cannot be found in any unicode-encoded document. Reproduce code: --- Expected result: OK Actual result: -- ?? -- Edit this bug report at http://bugs.php.net/?id=42396&edit=1
#29955 [Fbk->Opn]: Support for Turkish/iso-8859-9
ID: 29955 User updated by: jan at horde dot org Reported By: jan at horde dot org -Status: Feedback +Status: Open Bug Type: mbstring related Operating System: Linux PHP Version: 5CVS, 4CVS (2004-09-02) Assigned To: hirokawa New Comment: No. The conversion has to be done this way for iso-8859-9 always, not only if the current locale is Turkish. Turkish is the only language that uses this charset. Previous Comments: [2007-08-17 22:19:19] [EMAIL PROTECTED] This change is already back ported to PHP 5.2. In my understanding, it shouldn't always applied to ISO-8859-9, because the conversion result is depends on the locale. (correct ?) [2007-01-05 14:33:51] jan at horde dot org Oh, and by the way, this conversion should always happen for iso-8859-9, not only if mbstring.language is set to Turkish, because this is completely useless in real world applications. [2007-01-05 14:31:12] jan at horde dot org Any chance this is going to be backported to PHP 5.2? I guess mbstring is going to be obsolete with the Unicode and ICU support in PHP 6. [2005-12-23 14:56:27] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php6.0-latest.tar.gz For Windows: http://snaps.php.net/win32/php6.0-win32-latest.zip Turkish language support is added in CVS HEAD. When mbstring.language = Turkish, Turkish case filding will be performed in ISO-8859-9. (upper:0x69 -> 0xdd, lower:0x49->0xfd) Otherwise, normal case folding is performed. (upper:0x69 -> 0x49, lower:0x49->0x69) [2005-12-23 14:28:29] [EMAIL PROTECTED] "man iso-8859-9" will tell you. "i" maps to "0xdd" and "0xfd" maps to "I" See also: http://www.eki.ee/letter/chardata.cgi?lang=tr+Turkish&script=latin 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/29955 -- Edit this bug report at http://bugs.php.net/?id=29955&edit=1
#42391 [Bgs]: DOM ignores several valid dtd entities.
ID: 42391
User updated by: linus dot martensson at elplan-gm dot se
Reported By: linus dot martensson at elplan-gm dot se
Status: Bogus
Bug Type: DOM XML related
Operating System: Linux - Ubuntu Feisty Fawn
PHP Version: 5.2.3
New Comment:
Then, may I recommend clarifying the documentation? The entity
was, for example, handled without that extra option, and it is in the
SAME file as one of the entities that fail to load! *This* is why I
found the behaviour strange and decided to report the bug. Would you
please clarify such behaviour?
Linus
Previous Comments:
[2007-08-22 22:49:12] [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
You need to pass the LIBXML_DTDLOAD option to loadXML as external
subsets are not loaded by default
[2007-08-22 22:01:13] linus dot martensson at elplan-gm dot se
Retouched the summary.
[2007-08-22 21:45:43] linus dot martensson at elplan-gm dot se
Description:
The DOM parser fails to parse SEVERAL valid xhtml entities, such as
» and ⇒, even though both are specified in
http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent and
http://www.w3.org/TR/xhtml1/DTD/xhtml-symbol.ent.
These two files (among others) are referred to by the specified doctype
definition, xhtml1-strict.dtd.
The parser is obviously not taking all valid xhtml entities into
account, which is a serious problem.
Reproduce code:
---
loadXML('http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
⇒⇒'))
var_dump(libxml_get_last_error());
Expected result:
No output, should correctly parse the document and store the two
entities in the DOMDocument.
Actual result:
--
When the libXml error is retrieved, this is the apparent error:
Line 1: Entity 'rArr' not defined. The parse is aborted.
--
Edit this bug report at http://bugs.php.net/?id=42391&edit=1
#42400 [NEW]: the page show blank, needs to refresh a couple of times to show correctly.
From: borninseventies at yahoo dot com Operating system: windows xp sp2 PHP version: 5.2.3 PHP Bug Type: Output Control Bug description: the page show blank, needs to refresh a couple of times to show correctly. Description: I tried to use php5.2.3, but my page randomly show blank, and i had to reload it by refreshing it a couple of times to ensure it show correctly. While I chaged back to php4.4.2, all problems of blanking page are gone. My system is windowsxp sp2 + IIS + mysql. Actual result: -- just blank page randomly. -- Edit bug report at http://bugs.php.net/?id=42400&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42400&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42400&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42400&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42400&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42400&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42400&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42400&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42400&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42400&r=support Expected behavior:http://bugs.php.net/fix.php?id=42400&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42400&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42400&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42400&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42400&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42400&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42400&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42400&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42400&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42400&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42400&r=mysqlcfg
#42401 [NEW]: php5ts crash on double free
From: reprovol at microsoft dot com Operating system: Windows Vista/LH Server PHP version: 5.2.3 PHP Bug Type: Reproducible crash Bug description: php5ts crash on double free Description: Crash Bucket: 421917130 szAppName w3wp.exe szAppVer 7.0.6001.16510 szModName StackHash_80ba szModVer 6.0.6001.16510 Offset 000a773f Exception Code c374 Application Stamp 462598ef Module Stamp 4625a0ae 0:014> !heap ** ** * HEAP ERROR DETECTED * ** ** Details: Error address: 02ebc1d8 Heap handle: 0085 Error type heap_failure_block_not_busy (8) Stack trace: 77ad01f8: ntdll!RtlFreeHeap+0x0060 75f22a89: kernel32!HeapFree+0x0014 76659fbb: msvcrt!free+0x00cd 025a9cfe: php5ts+0x00099cfe 77ac631c: ntdll!zzz_AsmCodeRange_End 77ab42bd: ntdll!LdrpUnloadDll+0x03d4 77aafeff: ntdll!LdrUnloadDll+0x0046 75eb2563: kernel32!FreeLibrary+0x0076 748ecaa0: isapi!ISAPI_DLL::Unload+0x0038 0:014> lmvmphp5ts startendmodule name 0251 029e7000 php5ts T (no symbols) Loaded symbol image file: php5ts.dll Image path: php5ts.dll Image name: php5ts.dll Timestamp:Thu May 31 06:37:03 2007 (465ECF7F) CheckSum: ImageSize:004D7000 File version: 5.2.3.3 Product version: 5.2.3.0 File flags: 0 (Mask 3F) File OS: 4 Unknown Win32 File type:2.0 Dll File date:. Translations: .04b0 .04e0 0409.04b0 0409.04e0 Sorry 0:014> u 025a9cfe php5ts+0x99cfe: 025a9cfe ?? ??? Actual result: -- 77ad01f8: ntdll!RtlFreeHeap+0x0060 75f22a89: kernel32!HeapFree+0x0014 76659fbb: msvcrt!free+0x00cd 025a9cfe: php5ts+0x00099cfe 77ac631c: ntdll!zzz_AsmCodeRange_End 77ab42bd: ntdll!LdrpUnloadDll+0x03d4 77aafeff: ntdll!LdrUnloadDll+0x0046 75eb2563: kernel32!FreeLibrary+0x0076 748ecaa0: isapi!ISAPI_DLL::Unload+0x0038 -- Edit bug report at http://bugs.php.net/?id=42401&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42401&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42401&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42401&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42401&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42401&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42401&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42401&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42401&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42401&r=support Expected behavior:http://bugs.php.net/fix.php?id=42401&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42401&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42401&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42401&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42401&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42401&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42401&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42401&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42401&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42401&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42401&r=mysqlcfg
#42401 [Opn->Fbk]: php5ts crash on double free
ID: 42401 Updated by: [EMAIL PROTECTED] Reported By: reprovol at microsoft dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows Vista/LH Server PHP Version: 5.2.3 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2007-08-23 19:23:22] reprovol at microsoft dot com Description: Crash Bucket: 421917130 szAppName w3wp.exe szAppVer 7.0.6001.16510 szModName StackHash_80ba szModVer 6.0.6001.16510 Offset 000a773f Exception Code c374 Application Stamp 462598ef Module Stamp 4625a0ae 0:014> !heap ** ** * HEAP ERROR DETECTED * ** ** Details: Error address: 02ebc1d8 Heap handle: 0085 Error type heap_failure_block_not_busy (8) Stack trace: 77ad01f8: ntdll!RtlFreeHeap+0x0060 75f22a89: kernel32!HeapFree+0x0014 76659fbb: msvcrt!free+0x00cd 025a9cfe: php5ts+0x00099cfe 77ac631c: ntdll!zzz_AsmCodeRange_End 77ab42bd: ntdll!LdrpUnloadDll+0x03d4 77aafeff: ntdll!LdrUnloadDll+0x0046 75eb2563: kernel32!FreeLibrary+0x0076 748ecaa0: isapi!ISAPI_DLL::Unload+0x0038 0:014> lmvmphp5ts startendmodule name 0251 029e7000 php5ts T (no symbols) Loaded symbol image file: php5ts.dll Image path: php5ts.dll Image name: php5ts.dll Timestamp:Thu May 31 06:37:03 2007 (465ECF7F) CheckSum: ImageSize:004D7000 File version: 5.2.3.3 Product version: 5.2.3.0 File flags: 0 (Mask 3F) File OS: 4 Unknown Win32 File type:2.0 Dll File date:. Translations: .04b0 .04e0 0409.04b0 0409.04e0 Sorry 0:014> u 025a9cfe php5ts+0x99cfe: 025a9cfe ?? ??? Actual result: -- 77ad01f8: ntdll!RtlFreeHeap+0x0060 75f22a89: kernel32!HeapFree+0x0014 76659fbb: msvcrt!free+0x00cd 025a9cfe: php5ts+0x00099cfe 77ac631c: ntdll!zzz_AsmCodeRange_End 77ab42bd: ntdll!LdrpUnloadDll+0x03d4 77aafeff: ntdll!LdrUnloadDll+0x0046 75eb2563: kernel32!FreeLibrary+0x0076 748ecaa0: isapi!ISAPI_DLL::Unload+0x0038 -- Edit this bug report at http://bugs.php.net/?id=42401&edit=1
#42218 [NoF->Asn]: ImageTTFBBox & any2eucjp
ID: 42218 Updated by: [EMAIL PROTECTED] Reported By: fernando at barnatech dot com -Status: No Feedback +Status: Assigned Bug Type: GD related Operating System: Suse 10.2 PHP Version: 5.2.4RC1 Assigned To: pajoye New Comment: Feedback provided by grzegorz Previous Comments: [2007-08-19 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-08-13 09:32:45] grzegorz at inventor dot com dot pl I experienced the same problem as described above. source file encoding: UTF-8 PHP version: 5.2.2 GD Version: bundled (2.0.34 compatible) OS: Sabayon Linux I recompiled PHP with japanese support disabled and it seems to make problem go away. [2007-08-09 07:59:47] fernando at barnatech dot com I'll ask to the sysadmin team for a recompilation without japanese support and then for a test repetition. It can last for days, I think. I'll tell you the progress, if there's some. [2007-08-09 07:47:24] [EMAIL PROTECTED] About the install, on windows you don't have to install anything. You can run php directly from the uncompressed directory, using the console (cmd). "By the way, may he bug disappear if PHP-GD is recompiled without japanese support? The "any2eucjp()" in the error suggests it." Yes, if you don't need japanese, disable it. I suspect a conflict between the encoding. [2007-08-09 07:42:48] fernando at barnatech dot com The code encoding is UTF-8 as I told. We carefully use UTF-8 for code in the IDE, for data in the DBMS and for output in the webserver. I think a test is not so easy to perform in my job environment. Usually I have no direct access to installation privileges, further than limited ones in the development servers. No access to clients administration, no PHP installation, recompilation or direct reconfiguration without an administrative permission, etc. I promise you it's not so easy. Working with PHP 5.2.0 right now. The bug is there too, of course. By the way, may he bug disappear if PHP-GD is recompiled without japanese support? The "any2eucjp()" in the error suggests it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/42218 -- Edit this bug report at http://bugs.php.net/?id=42218&edit=1
#42403 [NEW]: Field Attributes
From: ssufficool at rov dot sbcounty dot gov
Operating system: Linux
PHP version: 5.2.3
PHP Bug Type: Feature/Change Request
Bug description: Field Attributes
Description:
The PDO getColumnMeta does not return all of the attributes that the
mssql_* functions return using FreeTDS or DBLIB.
Reproduce code:
---
query('SELECT fruit_name FROM fruit');
$meta = $select->getColumnMeta(0);
var_dump($meta);
?>
Expected result:
the proper length, not -1 and type of the character field along with other
attributes provided by mssql_field_* functions
Actual result:
--
field length of -1 along with other invalid/unknown attributes
--
Edit bug report at http://bugs.php.net/?id=42403&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42403&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42403&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42403&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42403&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42403&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42403&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42403&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42403&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42403&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42403&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42403&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42403&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42403&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42403&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42403&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42403&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42403&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42403&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42403&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42403&r=mysqlcfg
#42404 [NEW]: PHP drops APR_EGENERAL from ap_get_brigade
From: cvitale at us dot ibm dot com Operating system: Linux 2.4 PHP version: 5.2.3 PHP Bug Type: Apache2 related Bug description: PHP drops APR_EGENERAL from ap_get_brigade Description: I've compiled php to run on Apache 2.0.59 with --with-apxs2. The function php_apache_sapi_read_post in php-5.2.3/sapi/apache2handler/sapi_apache2.c assumes that the call to ap_get_brigade will never return an error that php should give to Apache. This violates Apache best practices. An Apache2 input content filter may return an error, like APR_EGENERAL. I am working on a filter that will reject suspicious input content and return this value. I also set the Apache request_rec status to 403. The requests that are returned have a 403 Forbidden status header and the normal php output body content. If ap_get_brigade returns an apache error php should stop processing. -- Edit bug report at http://bugs.php.net/?id=42404&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42404&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42404&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42404&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42404&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42404&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42404&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42404&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42404&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42404&r=support Expected behavior:http://bugs.php.net/fix.php?id=42404&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42404&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42404&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42404&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42404&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42404&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42404&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42404&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42404&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42404&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42404&r=mysqlcfg
#42404 [Com]: PHP drops APR_EGENERAL from ap_get_brigade
ID: 42404 Comment by: buanzo at buanzo dot com dot ar Reported By: cvitale at us dot ibm dot com Status: Open Bug Type: Apache2 related Operating System: Linux 2.4 PHP Version: 5.2.3 New Comment: Reproduced in Apache 2.2.4-r10 (Gentoo), PHP-5.2.3. Previous Comments: [2007-08-23 21:52:31] cvitale at us dot ibm dot com Description: I've compiled php to run on Apache 2.0.59 with --with-apxs2. The function php_apache_sapi_read_post in php-5.2.3/sapi/apache2handler/sapi_apache2.c assumes that the call to ap_get_brigade will never return an error that php should give to Apache. This violates Apache best practices. An Apache2 input content filter may return an error, like APR_EGENERAL. I am working on a filter that will reject suspicious input content and return this value. I also set the Apache request_rec status to 403. The requests that are returned have a 403 Forbidden status header and the normal php output body content. If ap_get_brigade returns an apache error php should stop processing. -- Edit this bug report at http://bugs.php.net/?id=42404&edit=1
#42400 [Opn->Fbk]: the page show blank, needs to refresh a couple of times to show correctly.
ID: 42400 Updated by: [EMAIL PROTECTED] Reported By: borninseventies at yahoo dot com -Status: Open +Status: Feedback Bug Type: Output Control Operating System: windows xp sp2 PHP Version: 5.2.3 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2007-08-23 19:12:32] borninseventies at yahoo dot com Description: I tried to use php5.2.3, but my page randomly show blank, and i had to reload it by refreshing it a couple of times to ensure it show correctly. While I chaged back to php4.4.2, all problems of blanking page are gone. My system is windowsxp sp2 + IIS + mysql. Actual result: -- just blank page randomly. -- Edit this bug report at http://bugs.php.net/?id=42400&edit=1
#42389 [Opn]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389 Updated by: [EMAIL PROTECTED] Reported By: webmaster at machostlink dot net Status: Open Bug Type: CGI related Operating System: OSX 10.4.10 PHP Version: 5.2.3 New Comment: Good point. :) Previous Comments: [2007-08-23 15:35:57] webmaster at machostlink dot net Sorry I forgot to add that.. I had a path set but only the path not the filename. Well so this time PHP did create a log but nothing in it when the "500 Internal Error" occurs. Well how should it write into the log when all the processes are killed at once!? [2007-08-23 14:13:52] [EMAIL PROTECTED] You forgot to set 'error_log = /path/to/php_error.log' [2007-08-23 12:25:06] webmaster at machostlink dot net Yeah I saw the news "PHP 4 end of life announcement" and I know that bug reports for it probably won't be fixed unless they are critical issues. I find it funny that both PHP versions are behaving like that... I checked the PHP config for this vhost again and again and tried different settings: Right now I have: -- max_execution_time = 60 max_input_time = 120 memory_limit = 64M error_reporting = E_ALL & ~E_NOTICE display_errors = On log_errors = On log_errors_max_len = 1024 But even after some testing now, still no PHP error.log to be seen!? [2007-08-23 12:01:53] [EMAIL PROTECTED] Regarding any PHP 4 fixes, see php.net for latest NEWS: "PHP 4 end of life announcement" This isn't any critical issue so it's very unlikely it will get fixed in PHP 4 (even if there were any more releases of PHP 4..) And I still think this isn't PHP bug. Do you know if PHP is outputting any errors? Do you have logging enabled? Are you sure you haven't hit any limits set in php.ini for max size for uploaded file for example..? [2007-08-23 11:41:18] webmaster at machostlink dot net Ok, I checked the latest CVS snapshot but the problem still remains the same. I forgot to mention in my inital post that I am using Apache2 with mod_suexec for permissions. But that seems to work fine according to suexec.log and apache2 error.log files. Thought I mention it now anyway just in case. 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/42389 -- Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42389 [Opn->Fbk]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389 Updated by: [EMAIL PROTECTED] Reported By: webmaster at machostlink dot net -Status: Open +Status: Feedback Bug Type: CGI related Operating System: OSX 10.4.10 PHP Version: 5.2.3 New Comment: My guess is it's crashing so you should try and attach GDB to the running process and see what the crash is about (note: you need to use latest CVS snapshot configured using --enable-debug option!) Make sure you only start 1 PHP FastCGI child, check what it's pid is and attach gdb: # gdb /path/to/php-cgi Previous Comments: [2007-08-23 22:23:43] [EMAIL PROTECTED] Good point. :) [2007-08-23 15:35:57] webmaster at machostlink dot net Sorry I forgot to add that.. I had a path set but only the path not the filename. Well so this time PHP did create a log but nothing in it when the "500 Internal Error" occurs. Well how should it write into the log when all the processes are killed at once!? [2007-08-23 14:13:52] [EMAIL PROTECTED] You forgot to set 'error_log = /path/to/php_error.log' [2007-08-23 12:25:06] webmaster at machostlink dot net Yeah I saw the news "PHP 4 end of life announcement" and I know that bug reports for it probably won't be fixed unless they are critical issues. I find it funny that both PHP versions are behaving like that... I checked the PHP config for this vhost again and again and tried different settings: Right now I have: -- max_execution_time = 60 max_input_time = 120 memory_limit = 64M error_reporting = E_ALL & ~E_NOTICE display_errors = On log_errors = On log_errors_max_len = 1024 But even after some testing now, still no PHP error.log to be seen!? [2007-08-23 12:01:53] [EMAIL PROTECTED] Regarding any PHP 4 fixes, see php.net for latest NEWS: "PHP 4 end of life announcement" This isn't any critical issue so it's very unlikely it will get fixed in PHP 4 (even if there were any more releases of PHP 4..) And I still think this isn't PHP bug. Do you know if PHP is outputting any errors? Do you have logging enabled? Are you sure you haven't hit any limits set in php.ini for max size for uploaded file for example..? 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/42389 -- Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42374 [Opn->Asn]: --as-needed bug
ID: 42374
Updated by: [EMAIL PROTECTED]
-Summary: --as-needed bug - follow-up
Reported By: galtgendo at o2 dot pl
-Status: Open
+Status: Assigned
Bug Type: Compile Failure
-Operating System: gentoo linux
+Operating System: Gentoo
-PHP Version: 5.2.3
+PHP Version: 5.2CVS-2007-08-23
-Assigned To:
+Assigned To: jani
New Comment:
After some investigation to this flag I'm leaning towards simply
filtering it out totally if someone tries to use it. Reasons being:
a) it seems to be experimental
b) might cause problems in dynamic loading such as our shared
extensions, f.e. php -> pdo -> pdo driver (haven't tested yet :)
c) requires that pretty much everything in the system has to be
compiled using it
d) PHP build system does not link with anything else than what is
actually needed anyway (AFAIK)
Previous Comments:
[2007-08-23 15:30:49] galtgendo at o2 dot pl
For a simple test case:
#include
int main()
{
g_print("test done\n");
return 0;
}
gcc -o minitest -Wl,--as-needed `pkg-config glib-2.0 --cflags`
minitest.c `pkg-config glib-2.0 --libs`
- compiles fine
gcc -o minitest -Wl,--as-needed `pkg-config glib-2.0 --cflags`
`pkg-config glib-2.0 --libs` minitest.c
- gives
/tmp/ccKZrHDW.o: In function `main':
minitest.c:(.text+0x19): undefined reference to `g_print'
collect2: ld returned 1 exit status
[2007-08-23 15:21:10] galtgendo at o2 dot pl
Well, that's incorrect.
PHP_CHECK_LIBRARY calls AC_CHECK_LIB.
without -Wl,--as-needed it does not matter whether libs are in LDFLAGS
or in LIBS, with that flag however all dependent libraries must appear
after the objects.
AC_CHECK_LIB does something like
i686-pc-linux-gnu-gcc -o conftest ${CFLAGS} ${LDFLAGS} conftest.c
${LIBS}
(more or less)
that check fails with --as-needed flag if lib is added to LDFLAGS
so it does not matter if it gets restored, cause the check already
failed - those are the false negatives I'm talking about.
All the other macros from the patch seem to do this, so that's why I
changed them. I'm not sure if something got broken, however it was
correct for the ext/ldap/config.m4 so there's at least a chance it will
work for the rest.
[2007-08-23 10:38:24] [EMAIL PROTECTED]
PHP_CHECK_LIBRARY restores the LDFLAGS after doing the test so it
shouldn't be any problem?
And bug #41973 was about ext/ldap and that was fixed.
I'd fix these case by case rather than blindly changing places unlikely
to even cause any problems.
[2007-08-22 15:40:41] galtgendo at o2 dot pl
Well, I'm not 100%, if I was, I would mentioned it, not asked for
futher testing.
And AFAIK that commit from bug #41973 was only
http://cvs.php.net/viewvc.cgi/php-src/ext/ldap/config.m4?r1=1.44&r2=1.45&diff_format=u
so only about ext/ldap/config.m4 (as in my patch).
What's more, although I can't recall if it made any difference you
should consider changes in acinclude.m4, cause in PHP_CHECK_LIBRARY
macro you were adding libraries to LDFLAGS instead of LIBS and that's
most common source of --as-needed bugs. That's why I'm talking about
false negatives - standard configure check would put those libraries in
wrong place and check would fail even if the library was OK.
[2007-08-22 14:46:27] [EMAIL PROTECTED]
And have you even tested what was committed in our CVS?
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/42374
--
Edit this bug report at http://bugs.php.net/?id=42374&edit=1
#29955 [Opn->Asn]: Support for Turkish/iso-8859-9
ID: 29955 Updated by: [EMAIL PROTECTED] Reported By: jan at horde dot org -Status: Open +Status: Assigned Bug Type: mbstring related Operating System: Linux PHP Version: 5CVS, 4CVS (2004-09-02) Assigned To: hirokawa New Comment: Feedback given. Previous Comments: [2007-08-23 16:33:44] jan at horde dot org No. The conversion has to be done this way for iso-8859-9 always, not only if the current locale is Turkish. Turkish is the only language that uses this charset. [2007-08-17 22:19:19] [EMAIL PROTECTED] This change is already back ported to PHP 5.2. In my understanding, it shouldn't always applied to ISO-8859-9, because the conversion result is depends on the locale. (correct ?) [2007-01-05 14:33:51] jan at horde dot org Oh, and by the way, this conversion should always happen for iso-8859-9, not only if mbstring.language is set to Turkish, because this is completely useless in real world applications. [2007-01-05 14:31:12] jan at horde dot org Any chance this is going to be backported to PHP 5.2? I guess mbstring is going to be obsolete with the Unicode and ICU support in PHP 6. [2005-12-23 14:56:27] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php6.0-latest.tar.gz For Windows: http://snaps.php.net/win32/php6.0-win32-latest.zip Turkish language support is added in CVS HEAD. When mbstring.language = Turkish, Turkish case filding will be performed in ISO-8859-9. (upper:0x69 -> 0xdd, lower:0x49->0xfd) Otherwise, normal case folding is performed. (upper:0x69 -> 0x49, lower:0x49->0x69) 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/29955 -- Edit this bug report at http://bugs.php.net/?id=29955&edit=1
#42379 [Fbk->Opn]: flush() will eat my server's memory!!
ID: 42379 User updated by: mika at netstock dot net Reported By: mika at netstock dot net -Status: Feedback +Status: Open Bug Type: Output Control Operating System: freebsd-6.2 PHP Version: 5.2.3 New Comment: you probably need excute it for a while (5 min maybe!!) and $var maybe need to put some data inside at client browser, every things looks fine i didn't get any error but memory leak it seem call sapi or something . Previous Comments: [2007-08-23 10:51:23] [EMAIL PROTECTED] Only thing I get is this output: Notice: Undefined variable: var in /opt/www/t.php on line 4 And no leak. How about providing us a bit more information and a script that does not have any errors/notices in it? Your configure line would be nice to know. And what extensions (if any) you load in php.ini.. [2007-08-22 13:21:04] mika at netstock dot net Description: when i use flush() or ob_implicit_flush() to push data to browser it will keep eating my server's memory like 4k 4k 4k..and another 4k .. and my apache is 2.0.59 Do anyone can help me Reproduce code: --- or -- Edit this bug report at http://bugs.php.net/?id=42379&edit=1
#42389 [Com]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389 Comment by: crrodriguez at suse dot de Reported By: webmaster at machostlink dot net Status: Feedback Bug Type: CGI related Operating System: OSX 10.4.10 PHP Version: 5.2CVS-2007-08-23 New Comment: what is the value of MaxRequestsPerProcess in your mod_fcgid configuration, it should be -1 This is a known issue of mod_fcgid see the documentation http://fastcgi.coremail.cn/doc.htm This is not a bug in PHP. Previous Comments: [2007-08-23 22:25:37] [EMAIL PROTECTED] My guess is it's crashing so you should try and attach GDB to the running process and see what the crash is about (note: you need to use latest CVS snapshot configured using --enable-debug option!) Make sure you only start 1 PHP FastCGI child, check what it's pid is and attach gdb: # gdb /path/to/php-cgi [2007-08-23 22:23:43] [EMAIL PROTECTED] Good point. :) [2007-08-23 15:35:57] webmaster at machostlink dot net Sorry I forgot to add that.. I had a path set but only the path not the filename. Well so this time PHP did create a log but nothing in it when the "500 Internal Error" occurs. Well how should it write into the log when all the processes are killed at once!? [2007-08-23 14:13:52] [EMAIL PROTECTED] You forgot to set 'error_log = /path/to/php_error.log' [2007-08-23 12:25:06] webmaster at machostlink dot net Yeah I saw the news "PHP 4 end of life announcement" and I know that bug reports for it probably won't be fixed unless they are critical issues. I find it funny that both PHP versions are behaving like that... I checked the PHP config for this vhost again and again and tried different settings: Right now I have: -- max_execution_time = 60 max_input_time = 120 memory_limit = 64M error_reporting = E_ALL & ~E_NOTICE display_errors = On log_errors = On log_errors_max_len = 1024 But even after some testing now, still no PHP error.log to be seen!? 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/42389 -- Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42374 [Com]: --as-needed causes configure failures
ID: 42374
Comment by: crrodriguez at suse dot de
Reported By: galtgendo at o2 dot pl
Status: Assigned
Bug Type: Compile Failure
Operating System: Gentoo
PHP Version: 5.2CVS-2007-08-23
Assigned To: jani
New Comment:
>a) it seems to be experimental
yes, but it usually work.
>b) might cause problems in dynamic loading such as our shared
>extensions, f.e. php -> pdo -> pdo driver (haven't tested yet :)
I have tested it with some extensions and seem to work fine, except
that the IMAP extension does not compile because configure checks fail
for the same reason the reporter is showing here.
>d) PHP build system does not link with anything else than what is
>actually needed anyway (AFAIK)
ldd -u -r /usr/bin/php
Unused direct dependencies:
/lib/libnsl.so.1
/lib/libz.so.1
ldd -u -r xmlreader.so
/lib/libz.so.1
/lib/libm.so.6
dom.so
Unused direct dependencies:
/lib/libz.so.1
/lib/libm.so.6
gd.so
Unused direct dependencies:
/usr/lib/libX11.so.6
although in most cases the guilty stuff is "foobar_config" scripts or
pkgconfig scripts that inject "uneeded" dependencies (uneeded at least
on linux)
Previous Comments:
[2007-08-23 23:01:01] [EMAIL PROTECTED]
After some investigation to this flag I'm leaning towards simply
filtering it out totally if someone tries to use it. Reasons being:
a) it seems to be experimental
b) might cause problems in dynamic loading such as our shared
extensions, f.e. php -> pdo -> pdo driver (haven't tested yet :)
c) requires that pretty much everything in the system has to be
compiled using it
d) PHP build system does not link with anything else than what is
actually needed anyway (AFAIK)
[2007-08-23 15:30:49] galtgendo at o2 dot pl
For a simple test case:
#include
int main()
{
g_print("test done\n");
return 0;
}
gcc -o minitest -Wl,--as-needed `pkg-config glib-2.0 --cflags`
minitest.c `pkg-config glib-2.0 --libs`
- compiles fine
gcc -o minitest -Wl,--as-needed `pkg-config glib-2.0 --cflags`
`pkg-config glib-2.0 --libs` minitest.c
- gives
/tmp/ccKZrHDW.o: In function `main':
minitest.c:(.text+0x19): undefined reference to `g_print'
collect2: ld returned 1 exit status
[2007-08-23 15:21:10] galtgendo at o2 dot pl
Well, that's incorrect.
PHP_CHECK_LIBRARY calls AC_CHECK_LIB.
without -Wl,--as-needed it does not matter whether libs are in LDFLAGS
or in LIBS, with that flag however all dependent libraries must appear
after the objects.
AC_CHECK_LIB does something like
i686-pc-linux-gnu-gcc -o conftest ${CFLAGS} ${LDFLAGS} conftest.c
${LIBS}
(more or less)
that check fails with --as-needed flag if lib is added to LDFLAGS
so it does not matter if it gets restored, cause the check already
failed - those are the false negatives I'm talking about.
All the other macros from the patch seem to do this, so that's why I
changed them. I'm not sure if something got broken, however it was
correct for the ext/ldap/config.m4 so there's at least a chance it will
work for the rest.
[2007-08-23 10:38:24] [EMAIL PROTECTED]
PHP_CHECK_LIBRARY restores the LDFLAGS after doing the test so it
shouldn't be any problem?
And bug #41973 was about ext/ldap and that was fixed.
I'd fix these case by case rather than blindly changing places unlikely
to even cause any problems.
[2007-08-22 15:40:41] galtgendo at o2 dot pl
Well, I'm not 100%, if I was, I would mentioned it, not asked for
futher testing.
And AFAIK that commit from bug #41973 was only
http://cvs.php.net/viewvc.cgi/php-src/ext/ldap/config.m4?r1=1.44&r2=1.45&diff_format=u
so only about ext/ldap/config.m4 (as in my patch).
What's more, although I can't recall if it made any difference you
should consider changes in acinclude.m4, cause in PHP_CHECK_LIBRARY
macro you were adding libraries to LDFLAGS instead of LIBS and that's
most common source of --as-needed bugs. That's why I'm talking about
false negatives - standard configure check would put those libraries in
wrong place and check would fail even if the library was OK.
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/42374
--
Edit this bug report at http://bugs.php.net/?id=42374&edit=1
#42397 [NEW]: problem with opening russian name files/directories
From: norraxx at seznam dot cz
Operating system: windows XP Professional (cz)
PHP version: 5.2.3
PHP Bug Type: *Directory/Filesystem functions
Bug description: problem with opening russian name files/directories
Description:
functions: opendir, readdir, scandir etc...
1. can`t read/open russian named directories.
2. question marks are returned as a name of file while reading dir.
3. file exists write when create russian name directory
Reproduce code:
---
{$x[2]}\n";
chdir($x[2]);
$x = scandir('.');
print_r($x);
?>
Expected result:
I explected to create dir "Îêîí÷àòåëüíóþ" and go to this dir.
Actual result:
--
Warning: mkdir() [function.mkdir]: File exists in D:\www\bad\index.php on
line 2
Array ( [0] => . [1] => .. [2] => ? [3] => index.php )
?
Array ( [0] => . [1] => .. [2] => ? [3] => index.php )
--
Edit bug report at http://bugs.php.net/?id=42397&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42397&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42397&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42397&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42397&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42397&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42397&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42397&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42397&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42397&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42397&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42397&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42397&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42397&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42397&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42397&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42397&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42397&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42397&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42397&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42397&r=mysqlcfg
#42374 [Opn]: --as-needed bug - follow-up
ID: 42374
User updated by: galtgendo at o2 dot pl
Reported By: galtgendo at o2 dot pl
Status: Open
Bug Type: Compile Failure
Operating System: gentoo linux
PHP Version: 5.2.3
New Comment:
For a simple test case:
#include
int main()
{
g_print("test done\n");
return 0;
}
gcc -o minitest -Wl,--as-needed `pkg-config glib-2.0 --cflags`
minitest.c `pkg-config glib-2.0 --libs`
- compiles fine
gcc -o minitest -Wl,--as-needed `pkg-config glib-2.0 --cflags`
`pkg-config glib-2.0 --libs` minitest.c
- gives
/tmp/ccKZrHDW.o: In function `main':
minitest.c:(.text+0x19): undefined reference to `g_print'
collect2: ld returned 1 exit status
Previous Comments:
[2007-08-23 15:21:10] galtgendo at o2 dot pl
Well, that's incorrect.
PHP_CHECK_LIBRARY calls AC_CHECK_LIB.
without -Wl,--as-needed it does not matter whether libs are in LDFLAGS
or in LIBS, with that flag however all dependent libraries must appear
after the objects.
AC_CHECK_LIB does something like
i686-pc-linux-gnu-gcc -o conftest ${CFLAGS} ${LDFLAGS} conftest.c
${LIBS}
(more or less)
that check fails with --as-needed flag if lib is added to LDFLAGS
so it does not matter if it gets restored, cause the check already
failed - those are the false negatives I'm talking about.
All the other macros from the patch seem to do this, so that's why I
changed them. I'm not sure if something got broken, however it was
correct for the ext/ldap/config.m4 so there's at least a chance it will
work for the rest.
[2007-08-23 10:38:24] [EMAIL PROTECTED]
PHP_CHECK_LIBRARY restores the LDFLAGS after doing the test so it
shouldn't be any problem?
And bug #41973 was about ext/ldap and that was fixed.
I'd fix these case by case rather than blindly changing places unlikely
to even cause any problems.
[2007-08-22 15:40:41] galtgendo at o2 dot pl
Well, I'm not 100%, if I was, I would mentioned it, not asked for
futher testing.
And AFAIK that commit from bug #41973 was only
http://cvs.php.net/viewvc.cgi/php-src/ext/ldap/config.m4?r1=1.44&r2=1.45&diff_format=u
so only about ext/ldap/config.m4 (as in my patch).
What's more, although I can't recall if it made any difference you
should consider changes in acinclude.m4, cause in PHP_CHECK_LIBRARY
macro you were adding libraries to LDFLAGS instead of LIBS and that's
most common source of --as-needed bugs. That's why I'm talking about
false negatives - standard configure check would put those libraries in
wrong place and check would fail even if the library was OK.
[2007-08-22 14:46:27] [EMAIL PROTECTED]
And have you even tested what was committed in our CVS?
[2007-08-22 14:45:33] [EMAIL PROTECTED]
FYI: this is not bugzilla and it's not annoying. It's just old. :)
And about your patch..are you really sure you need to change all those
places?
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/42374
--
Edit this bug report at http://bugs.php.net/?id=42374&edit=1
#42369 [Fbk->Opn]: Implicit conversion to string leaks memory
ID: 42369 User updated by: david at acz dot org Reported By: david at acz dot org -Status: Feedback +Status: Open Bug Type: SimpleXML related Operating System: SuSE Linux PHP Version: 5.2.3 New Comment: I could reproduce on php5.2-200708231430 (32-bit). Previous Comments: [2007-08-23 01:02:58] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi couldn't reproduce on latest 5.2.4 RC [2007-08-21 23:30:17] david at acz dot org Description: Passing a SimpleXML string object to most builtin string functions causes a memory leak. Reproduce code: --- #!/usr/local/bin/php -d memory_limit=128M '; $x = simplexml_load_string($xml . "foo"); echo "explicit conversion\n"; for ($i = 0; $i < 100; $i++) md5(strval($x->x)); echo "no conversion\n"; for ($i = 0; $i < 100; $i++) md5($x->x); echo "done\n"; ?> Expected result: $ ./crash.php explicit conversion no conversion done Actual result: -- $ ./crash.php explicit conversion no conversion Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 40 bytes) in /tmp/crash.php on line 12 -- Edit this bug report at http://bugs.php.net/?id=42369&edit=1
#42389 [Com]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389 Comment by: crrodriguez at suse dot de Reported By: webmaster at machostlink dot net Status: Feedback Bug Type: CGI related Operating System: OSX 10.4.10 PHP Version: 5.2CVS-2007-08-23 New Comment: err.. I meant it should be set to 500 NOT -1 Previous Comments: [2007-08-24 02:52:55] crrodriguez at suse dot de what is the value of MaxRequestsPerProcess in your mod_fcgid configuration, it should be -1 This is a known issue of mod_fcgid see the documentation http://fastcgi.coremail.cn/doc.htm This is not a bug in PHP. [2007-08-23 22:25:37] [EMAIL PROTECTED] My guess is it's crashing so you should try and attach GDB to the running process and see what the crash is about (note: you need to use latest CVS snapshot configured using --enable-debug option!) Make sure you only start 1 PHP FastCGI child, check what it's pid is and attach gdb: # gdb /path/to/php-cgi [2007-08-23 22:23:43] [EMAIL PROTECTED] Good point. :) [2007-08-23 15:35:57] webmaster at machostlink dot net Sorry I forgot to add that.. I had a path set but only the path not the filename. Well so this time PHP did create a log but nothing in it when the "500 Internal Error" occurs. Well how should it write into the log when all the processes are killed at once!? [2007-08-23 14:13:52] [EMAIL PROTECTED] You forgot to set 'error_log = /path/to/php_error.log' 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/42389 -- Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42389 [Opn->Fbk]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389
Updated by: [EMAIL PROTECTED]
Reported By: webmaster at machostlink dot net
-Status: Open
+Status: Feedback
Bug Type: CGI related
Operating System: OSX 10.4.10
PHP Version: 5.2.3
Previous Comments:
[2007-08-23 12:01:53] [EMAIL PROTECTED]
Regarding any PHP 4 fixes, see php.net for latest NEWS: "PHP 4 end of
life announcement"
This isn't any critical issue so it's very unlikely it will get fixed
in PHP 4 (even if there were any more releases of PHP 4..)
And I still think this isn't PHP bug. Do you know if PHP is outputting
any errors? Do you have logging enabled? Are you sure you haven't hit
any limits set in php.ini for max size for uploaded file for example..?
[2007-08-23 11:41:18] webmaster at machostlink dot net
Ok, I checked the latest CVS snapshot but the problem still remains the
same.
I forgot to mention in my inital post that I am using Apache2 with
mod_suexec for permissions. But that seems to work fine according to
suexec.log and apache2 error.log files. Thought I mention it now anyway
just in case.
[2007-08-23 09:13:53] webmaster at lifedit dot com
Right, I was taken that already in consideration and posted a report on
"mod_fcgid users bug tracker" as well. But looking at the history of
somewhat related php-cgi problems and bug reported I think it is more
likely to be a PHP bug.
My problem is that I have a hosting service and I rely on both PHP5 &
PHP4 because I do have clients who still have PHP4 applications they
want to run. So even if it does work with the latest CVS (which I will
try out) I still have a need for this feature to run on PHP4 as well. :(
[2007-08-23 09:06:04] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce anything like this, even when uploading quite large
files so try the snapshot first. (any possibility that this isn't any
PHP bug at all..? :)
[2007-08-22 20:39:33] webmaster at machostlink dot net
Description:
When using a simple upload form to submit a file, all php4-cgi &
php5-cgi processes (parent & children) are killed and server throws "500
Internal Server Error" message. This happens ONLY when filesize is
larger then 4KB.
Apache error.log from vhost
---
[warn] (35)Resource temporarily unavailable: mod_fcgid: write data to
fastcgi server error
Apache error.log from main/default server
-
mod_fcgid: process /Volumes/home/www/vhost1/public_html/test.php(2293)
exit(communication error), terminated by calling exit(), return code: 0
I am not sure now, after reading other (older) bug reports regarding
cgi problems, if this is not an older issue as well!? However, since I
could not find many similarities to these posts I decided to file this
one.
I am running PHP 4.4.7 & PHP 5.2.3 as CGI using mod_fcgid 2.2 and
Apache 2.2.4
Reproduce code:
---
';
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile))
{
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "Possible file upload attack!\n";
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print "";
?>
Send this file:
Expected result:
File is valid, and was successfully uploaded.
Here is some more debugging info:Array
(
[userfile] => Array
(
[name] => test.jpg
[type] => image/jpeg
[tmp_name] => /Volumes/home/www/vhost1/tmp/phpcYOdvd
[error] => 0
[size] => 24852930
)
)
Actual result:
--
Error 500
Internal Server Error
...
--
Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42393 [Asn]: mb_strtoupper is replacing one of the cyrillic symbols with wrong one.
ID: 42393 Updated by: [EMAIL PROTECTED] Reported By: ivan dot delchev at softconsultgroup dot com Status: Assigned Bug Type: mbstring related Operating System: Windows XP PHP Version: 5.2.3 Assigned To: hirokawa New Comment: Please show me mbstring.language setting in php.ini. Previous Comments: [2007-08-23 09:06:53] [EMAIL PROTECTED] Assigned to mbstring maintainer. [2007-08-23 08:06:01] ivan dot delchev at softconsultgroup dot com Description: mb_strtoupper is doind wrong transformation for "å" in cyrillic alphabetic. Whe wrong transformation "å"->"í". Also the function is not UPPER the string! Reproduce code: --- // Ensure that the web browser encoding is UTF8 and edit application is UTF8 compatible! $main_string = "Òîâà å òåñò. Îòíîâî Òåñò. Êàêâî áè ñå ïîëó÷èëî ñ òîçè ÒÅÑÒ äà âèäèì!"; var_dump($main_string); var_dump(mb_strtoupper($main_string)); Expected result: Dumped result to be the same. And second string to be UPPER! Actual result: -- string(120) "Òîâà å òåñò. Îòíîâî Òåñò. Êàêâî áè ñå ïîëó÷èëî ñ òîçè ÒÅÑÒ äà âèäèì!" string(120) "Òîâà ï òïñò. Îòíîâî Òïñò. Êàêâî áè ñï ïîëó÷èëî ñ òîçè ÒÅÑÒ äà âèäèì!" -- Edit this bug report at http://bugs.php.net/?id=42393&edit=1
#42389 [Opn]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389
Updated by: [EMAIL PROTECTED]
Reported By: webmaster at machostlink dot net
Status: Open
Bug Type: CGI related
Operating System: OSX 10.4.10
PHP Version: 5.2.3
New Comment:
Regarding any PHP 4 fixes, see php.net for latest NEWS: "PHP 4 end of
life announcement"
This isn't any critical issue so it's very unlikely it will get fixed
in PHP 4 (even if there were any more releases of PHP 4..)
And I still think this isn't PHP bug. Do you know if PHP is outputting
any errors? Do you have logging enabled? Are you sure you haven't hit
any limits set in php.ini for max size for uploaded file for example..?
Previous Comments:
[2007-08-23 11:41:18] webmaster at machostlink dot net
Ok, I checked the latest CVS snapshot but the problem still remains the
same.
I forgot to mention in my inital post that I am using Apache2 with
mod_suexec for permissions. But that seems to work fine according to
suexec.log and apache2 error.log files. Thought I mention it now anyway
just in case.
[2007-08-23 09:13:53] webmaster at lifedit dot com
Right, I was taken that already in consideration and posted a report on
"mod_fcgid users bug tracker" as well. But looking at the history of
somewhat related php-cgi problems and bug reported I think it is more
likely to be a PHP bug.
My problem is that I have a hosting service and I rely on both PHP5 &
PHP4 because I do have clients who still have PHP4 applications they
want to run. So even if it does work with the latest CVS (which I will
try out) I still have a need for this feature to run on PHP4 as well. :(
[2007-08-23 09:06:04] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce anything like this, even when uploading quite large
files so try the snapshot first. (any possibility that this isn't any
PHP bug at all..? :)
[2007-08-22 20:39:33] webmaster at machostlink dot net
Description:
When using a simple upload form to submit a file, all php4-cgi &
php5-cgi processes (parent & children) are killed and server throws "500
Internal Server Error" message. This happens ONLY when filesize is
larger then 4KB.
Apache error.log from vhost
---
[warn] (35)Resource temporarily unavailable: mod_fcgid: write data to
fastcgi server error
Apache error.log from main/default server
-
mod_fcgid: process /Volumes/home/www/vhost1/public_html/test.php(2293)
exit(communication error), terminated by calling exit(), return code: 0
I am not sure now, after reading other (older) bug reports regarding
cgi problems, if this is not an older issue as well!? However, since I
could not find many similarities to these posts I decided to file this
one.
I am running PHP 4.4.7 & PHP 5.2.3 as CGI using mod_fcgid 2.2 and
Apache 2.2.4
Reproduce code:
---
';
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile))
{
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "Possible file upload attack!\n";
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print "";
?>
Send this file:
Expected result:
File is valid, and was successfully uploaded.
Here is some more debugging info:Array
(
[userfile] => Array
(
[name] => test.jpg
[type] => image/jpeg
[tmp_name] => /Volumes/home/www/vhost1/tmp/phpcYOdvd
[error] => 0
[size] => 24852930
)
)
Actual result:
--
Error 500
Internal Server Error
...
--
Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42389 [Fbk->Opn]: PHP+Apache2+mod_fcgid kills all processes after submit
ID: 42389 User updated by: webmaster at machostlink dot net Reported By: webmaster at machostlink dot net -Status: Feedback +Status: Open Bug Type: CGI related Operating System: OSX 10.4.10 PHP Version: 5.2CVS-2007-08-23 New Comment: @jani Ok will do and let you know what the result is. @crrodriguez Here is my config for mod_fcgid: -- SharememPath /tmp/fcgid_shm SocketPath /opt/local/apache2/logs/fcgidsock IPCConnectTimeout 60 IPCCommTimeout 60 MaxRequestsPerProcess 500 MaxRequestInMem 150 MaxRequestLen 150 I think I have tried EVERY possible combination there is. I read ALL the threads and issues posted on sourceforge page as well as pretty much every thread I could find on google regarding mod_fcgid issues. :( That's why I am quite desperate to solve this. Thanks for you help... Previous Comments: [2007-08-24 02:54:52] crrodriguez at suse dot de err.. I meant it should be set to 500 NOT -1 [2007-08-24 02:52:55] crrodriguez at suse dot de what is the value of MaxRequestsPerProcess in your mod_fcgid configuration, it should be -1 This is a known issue of mod_fcgid see the documentation http://fastcgi.coremail.cn/doc.htm This is not a bug in PHP. [2007-08-23 22:25:37] [EMAIL PROTECTED] My guess is it's crashing so you should try and attach GDB to the running process and see what the crash is about (note: you need to use latest CVS snapshot configured using --enable-debug option!) Make sure you only start 1 PHP FastCGI child, check what it's pid is and attach gdb: # gdb /path/to/php-cgi [2007-08-23 22:23:43] [EMAIL PROTECTED] Good point. :) [2007-08-23 15:35:57] webmaster at machostlink dot net Sorry I forgot to add that.. I had a path set but only the path not the filename. Well so this time PHP did create a log but nothing in it when the "500 Internal Error" occurs. Well how should it write into the log when all the processes are killed at once!? 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/42389 -- Edit this bug report at http://bugs.php.net/?id=42389&edit=1
#42407 [NEW]: Function error_get_last returns errors from other scripts
From: jcharrey at gmail dot com Operating system: Linux PHP version: 5CVS-2007-08-24 (CVS) PHP Bug Type: Unknown/Other Function Bug description: Function error_get_last returns errors from other scripts Description: It seems that when error_get_last() is called, if no error has occurred in the calling script the function may often return the last error encountered by the PHP instance. Simply calling this function in an otherwise empty file will spit out random errors from other scripts being run on the same server. Reproduce code: --- Expected result: A blank page. Actual result: -- Array ( [type] => 2048 [message] => Non-static method modules_html::modoutput_xhtml() should not be called statically [file] => /home/swiders2/public_html/grip/includes/frontend.html.php [line] => 112 ) -- Edit bug report at http://bugs.php.net/?id=42407&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42407&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42407&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42407&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42407&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42407&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42407&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42407&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42407&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42407&r=support Expected behavior:http://bugs.php.net/fix.php?id=42407&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42407&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42407&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42407&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42407&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42407&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42407&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42407&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42407&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42407&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42407&r=mysqlcfg
#42406 [NEW]: strtotime cause segmentation fail
From: jason_jin at sdc dot sercomm dot com Operating system: linux PHP version: 5.2.3 PHP Bug Type: Program Execution Bug description: strtotime cause segmentation fail Description: Execution of Reproduce code on my embedded linux system produce following error message: 1187917260 Segmentation fault My embedded system use uclibc.php version is 5.1.6. Reproduce code work well on my pc whose php version is 5.1.2. Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=42406&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42406&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42406&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42406&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42406&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42406&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42406&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42406&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42406&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42406&r=support Expected behavior:http://bugs.php.net/fix.php?id=42406&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42406&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42406&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42406&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42406&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42406&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42406&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42406&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42406&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42406&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42406&r=mysqlcfg
#42408 [NEW]: hjjhjhjhjjj
From: zzz at bn dot com Operating system: hhj PHP version: 5.2.3 PHP Bug Type: IIS related Bug description: hjjhjhjhjjj Description: tyhtyutyyu Reproduce code: --- tytutyty Expected result: yuyututyu Actual result: -- uyuutyutyu -- Edit bug report at http://bugs.php.net/?id=42408&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42408&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42408&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42408&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42408&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42408&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42408&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42408&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42408&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42408&r=support Expected behavior:http://bugs.php.net/fix.php?id=42408&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42408&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42408&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42408&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42408&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42408&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42408&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42408&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42408&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42408&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42408&r=mysqlcfg
