#39230 [Opn->Bgs]: Deep Recusion to Segmentation Fault (Stack Overflow)
ID: 39230 Updated by: [EMAIL PROTECTED] Reported By: seth at pricepages dot org -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Mac 10.4 PHP Version: 5CVS-2006-10-23 (snap) New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php PHP is allowed to segfault with infinite recursion. Don't do this :) Previous Comments: [2006-10-23 03:56:05] seth at pricepages dot org I figured out that my script was causing the recursion. Inserting "$this->freeze(false);" on line 70 of SForm/Elm/ Header.php eliminates it. [2006-10-23 00:28:31] seth at pricepages dot org Description: Steps to kill PHP dead: - Load test page. - Enter "Seth Price" as your name - Click the submit button eAccelerator 0.9.5 is installed, but not enabled. I'm running Apache 1.3.33 I'm not sure what would cause this crash, I've run all these bits of code already in similar scripts, but for some reason this kills PHP. Reproduce code: --- Script: http://pricepages.org/temp/test.php.zip Include File: http://pricepages.org/temp/SForm.zip Actual result: -- (gdb) bt [whole lotta stack] ... #60434 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffdfa8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60435 0x02449730 in execute (op_array=0x6d5670) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60436 0x0244a020 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffe148) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:234 #60437 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffe148) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60438 0x02449730 in execute (op_array=0x6d5f70) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60439 0x0244a020 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffe2e8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:234 #60440 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffe2e8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60441 0x02449730 in execute (op_array=0x2bc970) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60442 0x024192fc in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/php/ php5.2-20061030/Zend/zend.c:1097 #60443 0x023a7c48 in php_execute_script (primary_file=0xbfffec70) at /usr/local/php/ php5.2-20061030/main/main.c:1758 #60444 0x024be590 in apache_php_module_main (r=0x183e038, display_source_mode=0) at /usr/local/php/ php5.2-20061030/sapi/apache/sapi_apache.c:53 #60445 0x024bfb58 in send_php (r=0x183e038, display_source_mode=0, filename=0x183fe68 "/Library/ WebServer/Documents/test.php") at /usr/local/php/ php5.2-20061030/sapi/apache/mod_php5.c:660 #60446 0x024bfbc0 in send_parsed_php (r=0x183e038) at /usr/ local/php/php5.2-20061030/sapi/apache/mod_php5.c:675 #60447 0xdd04 in ap_invoke_handler () #60448 0x00017dc0 in process_request_internal () #60449 0x00017e40 in ap_process_request () #60450 0x6b4c in child_main () #60451 0x6d04 in make_child () #60452 0x6e68 in startup_children () #60453 0x74d8 in standalone_main () #60454 0x7d60 in main () (gdb) q -- Edit this bug report at http://bugs.php.net/?id=39230&edit=1
#39121 [Asn->Fbk]: Incorrect return array handling in non-wsdl soap client.
ID: 39121
Updated by: [EMAIL PROTECTED]
Reported By: sos at sokhapkin dot dyndns dot org
-Status: Assigned
+Status: Feedback
Bug Type: SOAP related
Operating System: Gentoo linux
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
I cannot analyze the report without full SOAP Envelope. I fixed one bug
related to this report, but I cannot be sure that it fixes your issue.
(Your pathch is completly wrong).
Previous Comments:
[2006-10-10 22:42:36] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-10-10 22:32:38] sos at sokhapkin dot dyndns dot org
Description:
Return soap type array needs special handling in non-wsdl mode. The
return array should have numeric indexes only because all elements of
returned array have the same name.
Here is the pacth to fix the problem:
--- php_packet_soap.c.orig 2006-01-01 07:50:13.0 -0500
+++ php_packet_soap.c 2006-10-10 17:50:50.0 -0400
@@ -338,9 +338,18 @@
if (val != NULL) {
if
(!node_is_equal_ex(val,"result",RPC_SOAP12_NAMESPACE)) {
zval *tmp;
+ int isarray = 0;
+ if(xmlHasProp(val,
"type")) {
+ xmlChar *type;
+ type =
xmlGetProp(val, "type");
+ if(strstr(type,
":Array"))
+ isarray
= 1;
+ xmlFree(type);
+ }
+
tmp =
master_to_zval(NULL, val);
- if (val->name) {
+ if (val->name &&
!isarray) {
add_assoc_zval(return_value, (char*)val->name, tmp);
} else {
add_next_index_zval(return_value, tmp);
Reproduce code:
---
Here is an example of soap return xml:
1732608065011.9901732588259911.990
Expected result:
Array => (
[0] => Array => (
[0] => 17326080650
[1] => 1
[2] => 1.99
[3] => 0
)
[1] => Array => (
[0] => 17325882599
[1] => 1
[2] => 1.99
[3] => 0
)
)
Actual result:
--
Array => (
[Array] => Array => (
[0] => 17325882599
[1] => 1
[2] => 1.99
[3] => 0
)
)
--
Edit this bug report at http://bugs.php.net/?id=39121&edit=1
#39179 [Asn->Fbk]: Abstract types not handled by SoapClient in WSDL mode
ID: 39179 Updated by: [EMAIL PROTECTED] Reported By: jchernia at netsuite dot com -Status: Assigned +Status: Feedback Bug Type: SOAP related Operating System: Windows XP PHP Version: 5.1.6 Assigned To: dmitry New Comment: Could you provide full WSDL file and SOAP request or reeponce that ext/soap cannot handle correct. Previous Comments: [2006-10-18 22:24:46] jchernia at netsuite dot com Still fails with 5.2. Is there a way to indicate that you want the subclass, not the abstract class? I don't see any in the documentation and I've tried lots of things. [2006-10-17 17:52:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-10-17 17:47:11] jchernia at netsuite dot com Description: This is very similar to bug 36575 http://bugs.php.net/bug.php?id=36575), but I still see this in the latest code. If an operation takes an abstract type, I can not get SoapClient (in WSDL mode) to produce one of the subclass instances of it, even if I set type, etc. Both Axis and .NET generated client classes will send the correct subclass if you specify it. NuSoap does not, but allows you to specify additional attributes in WSDL mode. Reproduce code: --- Operation XSD: Expected result: Either this, or the ability to set these attributes in WSDL mode. Actual result: -- -- Edit this bug report at http://bugs.php.net/?id=39179&edit=1
#39188 [Asn->Fbk]: reading php://input hangs with IIS
ID: 39188 Updated by: [EMAIL PROTECTED] Reported By: php at nineberry dot de -Status: Assigned +Status: Feedback Bug Type: IIS related Operating System: Win32 PHP Version: 5.1.6 Assigned To: dmitry New Comment: The provided example works fine (at least with latest php-5.2 snapshot and FastCGI SAPI). Previous Comments: [2006-10-18 19:19:02] php at nineberry dot de Can't test. Can't access server but by FTP. [2006-10-18 19:10:29] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-10-18 19:01:28] php at nineberry dot de Description: Posting to a php script makes the script hang reading from php://input on a server with IIS 6.0 / CGI Code works fine on Apache both on Linux and Win32. Code also works as expected, when "text/plain" is used as enctype in the HTML Form. Maybe related to #38488 ? Maybe stdin is not opened as binary any longer? Reproduce code: --- HTML Form: PHP Code in 1.php: Expected result: Expected Output: tDone Actual result: -- Constantly loading, CGI timeout after some minutes. -- Edit this bug report at http://bugs.php.net/?id=39188&edit=1
#39230 [Opn]: Deep Recusion to Segmentation Fault (Stack Overflow)
ID: 39230 User updated by: seth at pricepages dot org Reported By: seth at pricepages dot org Status: Open Bug Type: Reproducible crash Operating System: Mac 10.4 PHP Version: 5CVS-2006-10-23 (snap) New Comment: I figured out that my script was causing the recursion. Inserting "$this->freeze(false);" on line 70 of SForm/Elm/ Header.php eliminates it. Previous Comments: [2006-10-23 00:28:31] seth at pricepages dot org Description: Steps to kill PHP dead: - Load test page. - Enter "Seth Price" as your name - Click the submit button eAccelerator 0.9.5 is installed, but not enabled. I'm running Apache 1.3.33 I'm not sure what would cause this crash, I've run all these bits of code already in similar scripts, but for some reason this kills PHP. Reproduce code: --- Script: http://pricepages.org/temp/test.php.zip Include File: http://pricepages.org/temp/SForm.zip Actual result: -- (gdb) bt [whole lotta stack] ... #60434 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffdfa8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60435 0x02449730 in execute (op_array=0x6d5670) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60436 0x0244a020 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffe148) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:234 #60437 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffe148) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60438 0x02449730 in execute (op_array=0x6d5f70) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60439 0x0244a020 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffe2e8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:234 #60440 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffe2e8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60441 0x02449730 in execute (op_array=0x2bc970) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60442 0x024192fc in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/php/ php5.2-20061030/Zend/zend.c:1097 #60443 0x023a7c48 in php_execute_script (primary_file=0xbfffec70) at /usr/local/php/ php5.2-20061030/main/main.c:1758 #60444 0x024be590 in apache_php_module_main (r=0x183e038, display_source_mode=0) at /usr/local/php/ php5.2-20061030/sapi/apache/sapi_apache.c:53 #60445 0x024bfb58 in send_php (r=0x183e038, display_source_mode=0, filename=0x183fe68 "/Library/ WebServer/Documents/test.php") at /usr/local/php/ php5.2-20061030/sapi/apache/mod_php5.c:660 #60446 0x024bfbc0 in send_parsed_php (r=0x183e038) at /usr/ local/php/php5.2-20061030/sapi/apache/mod_php5.c:675 #60447 0xdd04 in ap_invoke_handler () #60448 0x00017dc0 in process_request_internal () #60449 0x00017e40 in ap_process_request () #60450 0x6b4c in child_main () #60451 0x6d04 in make_child () #60452 0x6e68 in startup_children () #60453 0x74d8 in standalone_main () #60454 0x7d60 in main () (gdb) q -- Edit this bug report at http://bugs.php.net/?id=39230&edit=1
#39227 [Opn]: php 5.1.6 introduced $_SESSION problems
ID: 39227 User updated by: martyn dot griffin at charter dot net Reported By: martyn dot griffin at charter dot net Status: Open Bug Type: Feature/Change Request Operating System: Fedora 5 PHP Version: 5.1.6 New Comment: I think I understand why you could not recreate the problem?! I was working using a frameset, where the SESSION values were being set in the page that defined the frames. When the target pages were launched in each of the frames, all the SESSION values are gone. When I finally tested it outside of any frames, it all worked as expected. To put this another way, when I create a simple frameset definition and at the start of it do something like: $_SESSION['xxx']="abcdef"; that value never shows when I try to echo it from the page that the frame links to. I have a WXP environment that is running PHP 5.1.5 and this problem does not occur. Unfortunately (for me!), I can not revert my Linux system back to pre-PHP 5.1.6 Previous Comments: [2006-10-22 15:52:56] martyn dot griffin at charter dot net I owe all an appology - it must have been a senior moment!! The issue applies to using $_SESSION not $_SERVER, so please change that in all my references. I have the following set (or defaulted) in php.ini register_globals = Off register_long_arrays = Off register_argc_argv = Off variables_order = "EGPCS" This was not changed since running 5.1.4 when the application functioned as expected. Also, the example to reproduce the problem should be altered in the included code as: '.$_SESSION['thmBGcol']; ?> Every page used starts with the include for funcs.php. [2006-10-22 05:44:26] [EMAIL PROTECTED] You are assigning things to _SERVER? That seems like a really bad idea. What do you think that will do? How about using $GLOBALS for that instead? Having said that, I can't reproduce your problem here. Are you running any 3rd-party extensions, or do you have variables_order in you php.ini file set to exclude "S" ? [2006-10-22 03:55:21] martyn dot griffin at charter dot net Description: Using Fedora 5 and yum updated from PHP 5.1.4 to PHP 5.1.6 After completetion of update, I have lost access to all of my $_SERVER values. They disappear right after assigning them in every script I use, which has crippled my current application Reproduce code: --- '.$_SERVER['thmBGcol']; ?> #66 instead I get BG Color--> Actual result: -- instead I get BG Color--> -- Edit this bug report at http://bugs.php.net/?id=39227&edit=1
#39229 [Opn->Bgs]: curl_exec hang on fiew cases of proxy connections
ID: 39229 Updated by: [EMAIL PROTECTED] Reported By: ludiqely at gmail dot com -Status: Open +Status: Bogus Bug Type: cURL related Operating System: linux PHP Version: 5.1.6 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Any hangs in curl_exec() are a direct result of "hangs" inside the libcurl code and as such are not a PHP bug. Previous Comments: [2006-10-22 19:03:30] ludiqely at gmail dot com Description: I've used exactly socks connections. This code create this problem: php hang on this line with curl_exec function Reproduce code: --- $hCurl = curl_init(); curl_setopt ($hCurl, CURLOPT_URL, "http://google.com";); curl_setopt ($hCurl, CURLOPT_HEADER, 0); curl_setopt ($hCurl, CURLOPT_PROXY, "66.210.89.130:1080"); curl_setopt ($hCurl, CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5); curl_setopt ($hCurl, CURLOPT_TIMEOUT, 7); curl_setopt ($hCurl, CURLOPT_CONNECTTIMEOUT, 7); curl_setopt ($hCurl, CURLE_OPERATION_TIMEOUTED, 7); curl_setopt ($hCurl, CURLOPT_DNS_CACHE_TIMEOUT, 7); curl_setopt ($hCurl, CURLOPT_RETURNTRANSFER, 1); print 'before curl_exec'; $out = curl_exec ($hCurl); print $out; Expected result: Expected exit from the function under the specified timeout. -- Edit this bug report at http://bugs.php.net/?id=39229&edit=1
#39230 [NEW]: Deep Recusion to Segmentation Fault (Stack Overflow)
From: seth at pricepages dot org Operating system: Mac 10.4 PHP version: 5CVS-2006-10-23 (snap) PHP Bug Type: Reproducible crash Bug description: Deep Recusion to Segmentation Fault (Stack Overflow) Description: Steps to kill PHP dead: - Load test page. - Enter "Seth Price" as your name - Click the submit button eAccelerator 0.9.5 is installed, but not enabled. I'm running Apache 1.3.33 I'm not sure what would cause this crash, I've run all these bits of code already in similar scripts, but for some reason this kills PHP. Reproduce code: --- Script: http://pricepages.org/temp/test.php.zip Include File: http://pricepages.org/temp/SForm.zip Actual result: -- (gdb) bt [whole lotta stack] ... #60434 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffdfa8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60435 0x02449730 in execute (op_array=0x6d5670) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60436 0x0244a020 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffe148) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:234 #60437 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffe148) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60438 0x02449730 in execute (op_array=0x6d5f70) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60439 0x0244a020 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffe2e8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:234 #60440 0x0244af60 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffe2e8) at /usr/local/php/ php5.2-20061030/Zend/zend_vm_execute.h:322 #60441 0x02449730 in execute (op_array=0x2bc970) at /usr/ local/php/php5.2-20061030/Zend/zend_vm_execute.h:92 #60442 0x024192fc in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/php/ php5.2-20061030/Zend/zend.c:1097 #60443 0x023a7c48 in php_execute_script (primary_file=0xbfffec70) at /usr/local/php/ php5.2-20061030/main/main.c:1758 #60444 0x024be590 in apache_php_module_main (r=0x183e038, display_source_mode=0) at /usr/local/php/ php5.2-20061030/sapi/apache/sapi_apache.c:53 #60445 0x024bfb58 in send_php (r=0x183e038, display_source_mode=0, filename=0x183fe68 "/Library/ WebServer/Documents/test.php") at /usr/local/php/ php5.2-20061030/sapi/apache/mod_php5.c:660 #60446 0x024bfbc0 in send_parsed_php (r=0x183e038) at /usr/ local/php/php5.2-20061030/sapi/apache/mod_php5.c:675 #60447 0xdd04 in ap_invoke_handler () #60448 0x00017dc0 in process_request_internal () #60449 0x00017e40 in ap_process_request () #60450 0x6b4c in child_main () #60451 0x6d04 in make_child () #60452 0x6e68 in startup_children () #60453 0x74d8 in standalone_main () #60454 0x7d60 in main () (gdb) q -- Edit bug report at http://bugs.php.net/?id=39230&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39230&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39230&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39230&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39230&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39230&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39230&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39230&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39230&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39230&r=support Expected behavior:http://bugs.php.net/fix.php?id=39230&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39230&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39230&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39230&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39230&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39230&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39230&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39230&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39230&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39230&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39230&r=mysqlcfg
#39229 [NEW]: curl_exec hang on fiew cases of proxy connections
From: ludiqely at gmail dot com Operating system: linux PHP version: 5.1.6 PHP Bug Type: cURL related Bug description: curl_exec hang on fiew cases of proxy connections Description: I've used exactly socks connections. This code create this problem: php hang on this line with curl_exec function Reproduce code: --- $hCurl = curl_init(); curl_setopt ($hCurl, CURLOPT_URL, "http://google.com";); curl_setopt ($hCurl, CURLOPT_HEADER, 0); curl_setopt ($hCurl, CURLOPT_PROXY, "66.210.89.130:1080"); curl_setopt ($hCurl, CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5); curl_setopt ($hCurl, CURLOPT_TIMEOUT, 7); curl_setopt ($hCurl, CURLOPT_CONNECTTIMEOUT, 7); curl_setopt ($hCurl, CURLE_OPERATION_TIMEOUTED, 7); curl_setopt ($hCurl, CURLOPT_DNS_CACHE_TIMEOUT, 7); curl_setopt ($hCurl, CURLOPT_RETURNTRANSFER, 1); print 'before curl_exec'; $out = curl_exec ($hCurl); print $out; Expected result: Expected exit from the function under the specified timeout. -- Edit bug report at http://bugs.php.net/?id=39229&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39229&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39229&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39229&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39229&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39229&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39229&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39229&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39229&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39229&r=support Expected behavior:http://bugs.php.net/fix.php?id=39229&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39229&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39229&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39229&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39229&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39229&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39229&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39229&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39229&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39229&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39229&r=mysqlcfg
#38915 [Bgs->Opn]: mod_php: system() (and similar) don't cleanup opened handles of Apache
ID: 38915
User updated by: dimmoborgir at gmail dot com
Reported By: dimmoborgir at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: Apache2 related
Operating System: UNIX
PHP Version: 4.4.3, 4.4.4, 5.0.4, 5.1.4, 5.1.6, 5.2.0RC5
New Comment:
There are some people that disagree.
Let them express their opinion here.
Previous Comments:
[2006-10-20 09:48:43] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
The opened file descriptors are opened by Apache.
It is the job of Apache to protect them, not something that should be
reinvented in all apache modules.
Not a bug in PHP.
[2006-09-24 18:17:22] dimmoborgir at gmail dot com
Tested on versions 4.4.3, 4.4.4, 5.0.4, 5.1.4, 5.1.6, 5.2.0RC5.
[2006-09-21 19:15:25] dimmoborgir at gmail dot com
Description:
The problem is in exec, system, popen (and similar) PHP functions. The
fact is that PHP doesn't sanitize opened file descriptors before
executing a program.
These functions use popen() C function to spawn a program.
popen() is equal to the successive execution of
pipe(), fork(), dup2(), exec().
These functions keep all opened handles. (Except STDOUT, which is
replaced to pipe).
This bug makes php-includes vulnerabilities more dangerous.
If the server uses mod_php, and we can execute shell commands via
system(), then we can, e.g. stop apache processes (by sending a
SIGSTOP), and to listen and process connections on 80 port (opened by
Apache, and transmitted to us by PHP). Also we can write anything to
its errorlog.
Reproduce code:
---
Some steps to reproduce a bug.
First. Simple program to wait :)
# cat test1.c
int main()
{
setsid( );
sleep( 1 );
}
#gcc -o test1 test1.c
Ok. Let's make a php script:
#cat a.php
Request: http://127.0.0.1/a.php
Good. Now see opened handles:
#lsof | grep test1
test1 cwdDIR /usr/local/apache2/htdocs
test1 rtdDIR /
test1 txtREG /var/www/html/test1
test1 memREG /lib/tls/libc-2.3.5.so
test1 memREG /lib/ld-2.3.5.so
test1 memREG [stack] (stat: No such file or
directory)
test1 0r CHR /dev/null
test1 1w FIFO pipe
test1 2w REG /usr/local/apache2/logs/error_log
test1 3u IPv4 *:http (LISTEN)
test1 4r FIFO pipe
test1 5w FIFO pipe
test1 6w REG /usr/local/apache2/logs/error_log
test1 7w REG /usr/local/apache2/logs/access_log
test1 8r unknown inode type
test1 9u IPv4 10.0.0.2:http->10.0.0.1:2134
(CLOSE_WAIT)
So, our test1 has apache's handles. Now we can do something like that:
int p = getsid( 0 ); // get current Process Group Id
setsid( ); // become session leader
kill( -p, SIGSTOP ); // good night, Apache Process Group :)
And after that:
for ( sock = 3; sock < getdtablesize(); sock++ ) // find valid socket
handle
if ( listen (sock, 10) == 0 ) break;
Full exploit is available on http://hackerdom.ru/~dimmo/phpexpl.c
Expected result:
I didn't expected program, executed via system() PHP function, to have
all opened descriptors of Apache Web Server (including 80 port, error
and access logs, opened connections, etc...)
Actual result:
--
Our PHP program has all descriptors of Apache Server.
--
Edit this bug report at http://bugs.php.net/?id=38915&edit=1
#37919 [Fbk->Opn]: PHP doesn't read the configurations propertly
ID: 37919 User updated by: rafael dot amador at gmail dot com Reported By: rafael dot amador at gmail dot com -Status: Feedback +Status: Open Bug Type: *Configuration Issues Operating System: Windows XP Pro SP2 PHP Version: 5.1.4 or above New Comment: i've perfectly told that any other method works, with this statement i mean any other method DOESN'T WORK. and by the way i'm reporting a BUG i've a work arround but the bug still remains in the code. i've solved this with the register method now i've my server working with this method but the point here is that the PATH method doesn't work ... i've spend a lot of time reporting this bug and following the progress of it. i'm waiting that anyone there (Zend-PHP developer staff) take this seriously don't give me a pretext to close this bug. This danm bug is giving headaches to more than a couple of IT admins. i'm very annoyed about the response time showing a profesionless attitude ... sorry guys but it's the truth Previous Comments: [2006-09-27 07:25:47] mcloudteo at hotmail dot com Do this: * Go to Control Panel and open the System icon (Start -> Settings -> Control Panel -> System, or just Start -> Control Panel -> System for Windows XP/2003) * Go to the Advanced tab * Click on the 'Environment Variables' button * Look into the 'System variables' pane * Click on 'New' and enter 'PHPRC' as the variable name and the directory where php.ini is located as the variable value (e.g. C:\php) * Press OK and restart your computer [2006-09-25 23:26:09] rafael dot amador at gmail dot com tested with lastest snapshot and the same result [2006-09-23 10:19:02] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-07-27 17:21:12] rafael dot amador at gmail dot com the bug is present in 5.1.5. Nobody will fix this anoying bug? [2006-06-27 02:16:12] rafael dot amador at gmail dot com i configured the php file with the registry entry pointing to it and didn't work but if i comment the doc_root option in php.ini all works WELL. a couple of questions come to me now: why the windows PATH method doesn't works? why the registry method works only with doc_root disabled? i saw a lot of bugs that have similar behavior. check this beacuse if isn't a bug then isn't documentated. 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/37919 -- Edit this bug report at http://bugs.php.net/?id=37919&edit=1
#39227 [Fbk->Opn]: php 5.1.6 introduced $_SESSION problems
ID: 39227 User updated by: martyn dot griffin at charter dot net -Summary: php 5.1.6 introduced $_SERVER problems Reported By: martyn dot griffin at charter dot net -Status: Feedback +Status: Open Bug Type: Feature/Change Request Operating System: Fedora 5 PHP Version: 5.1.6 New Comment: I owe all an appology - it must have been a senior moment!! The issue applies to using $_SESSION not $_SERVER, so please change that in all my references. I have the following set (or defaulted) in php.ini register_globals = Off register_long_arrays = Off register_argc_argv = Off variables_order = "EGPCS" This was not changed since running 5.1.4 when the application functioned as expected. Also, the example to reproduce the problem should be altered in the included code as: '.$_SESSION['thmBGcol']; ?> Every page used starts with the include for funcs.php. Previous Comments: [2006-10-22 05:44:26] [EMAIL PROTECTED] You are assigning things to _SERVER? That seems like a really bad idea. What do you think that will do? How about using $GLOBALS for that instead? Having said that, I can't reproduce your problem here. Are you running any 3rd-party extensions, or do you have variables_order in you php.ini file set to exclude "S" ? [2006-10-22 03:55:21] martyn dot griffin at charter dot net Description: Using Fedora 5 and yum updated from PHP 5.1.4 to PHP 5.1.6 After completetion of update, I have lost access to all of my $_SERVER values. They disappear right after assigning them in every script I use, which has crippled my current application Reproduce code: --- '.$_SERVER['thmBGcol']; ?> #66 instead I get BG Color--> Actual result: -- instead I get BG Color--> -- Edit this bug report at http://bugs.php.net/?id=39227&edit=1
#39228 [Opn->Bgs]: PDO: implement randomRow method
ID: 39228 User updated by: selecter at gmail dot com Reported By: selecter at gmail dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: * PHP Version: * New Comment: ok I get it Previous Comments: [2006-10-22 15:00:11] selecter at gmail dot com It's a feature request for PDO, not a question about how to implement. [2006-10-22 14:57:22] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. You can do that in PHP. However there is no way a random order can be fast. Nothing PHP, the RDBMS or any other software can do here. I guess the best option is to use a shuffle algorithm on top of the query result. [2006-10-22 14:51:35] selecter at gmail dot com Description: We need a unified method which will get a random row from a table. Please note that at least in MySQL: SELECT * FROM tablename ORDER BY rand(); is too slow on big tables. -- Edit this bug report at http://bugs.php.net/?id=39228&edit=1
#39228 [Bgs->Opn]: PDO: implement randomRow method
ID: 39228 User updated by: selecter at gmail dot com Reported By: selecter at gmail dot com -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: * New Comment: It's a feature request for PDO, not a question about how to implement. Previous Comments: [2006-10-22 14:57:22] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. You can do that in PHP. However there is no way a random order can be fast. Nothing PHP, the RDBMS or any other software can do here. I guess the best option is to use a shuffle algorithm on top of the query result. [2006-10-22 14:51:35] selecter at gmail dot com Description: We need a unified method which will get a random row from a table. Please note that at least in MySQL: SELECT * FROM tablename ORDER BY rand(); is too slow on big tables. -- Edit this bug report at http://bugs.php.net/?id=39228&edit=1
#39228 [Opn->Bgs]: PDO: implement randomRow method
ID: 39228 Updated by: [EMAIL PROTECTED] Reported By: selecter at gmail dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request -Operating System: Linux +Operating System: * -PHP Version: 5.1.6 +PHP Version: * New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. You can do that in PHP. However there is no way a random order can be fast. Nothing PHP, the RDBMS or any other software can do here. I guess the best option is to use a shuffle algorithm on top of the query result. Previous Comments: [2006-10-22 14:51:35] selecter at gmail dot com Description: We need a unified method which will get a random row from a table. Please note that at least in MySQL: SELECT * FROM tablename ORDER BY rand(); is too slow on big tables. -- Edit this bug report at http://bugs.php.net/?id=39228&edit=1
#39163 [Opn]: Invalid API call from php5isapi.dll causing IIS7 Application Pool failure.
ID: 39163
User updated by: tony dot stone at gmail dot com
Reported By: tony dot stone at gmail dot com
Status: Open
Bug Type: Win32API related
Operating System: Windows Vista RC 1 Build 5600
PHP Version: 5.1.6
New Comment:
Is there anything else I can do to assist with this?
Previous Comments:
[2006-10-17 11:03:01] tony dot stone at gmail dot com
No it doesn't. I installed the following version:
16 Oct 2006 12:40:40 +0200
Version: 5.2.0RC6-dev
Branch
[2006-10-17 07:42:10] [EMAIL PROTECTED]
Does it work with 5.2.0 snapshots from http://snaps.php.net/ ?
[2006-10-17 00:43:25] tony dot stone at gmail dot com
PHP isn't crashing so there's no way to get a backtrace (that I know
of). I did download the debug files and install them, but there's no
popup or window of any sort that would allow me to click Cancel or
enter a debug view. PHP isn't technically crashing. php5isapi.dll
is making an API call to the OS via the DefaultAppPool in IIS7 and the
DefaultAppPool is shutting down and generating an event log error,
which reads, "Failed to find the RegisterModule entrypoint in the
module DLL C:\Inetpub\PHP\php5isapi.dll. The data is the error."
Maybe I'm just not getting it, but I don't see any way to get the
backtrace info per the directions
(http://bugs.php.net/bugs-generating-backtrace-win32.php) based on this
behavior.
[2006-10-16 07:30:10] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2006-10-16 02:45:27] tony dot stone at gmail dot com
Description:
I've seen a few other people post concerning random crashes, but my
issue can be reproduced every time I try to access any web page on my
server since configuring it to use php5isapi.dll
I am running Vista RC1 build 5600 with IIS 7 installed. php5isapi.dll
appears to be making an API call not recognized by the OS. Ever since
I installed PHP my DefaultAppPool stops when I access any web page on
my server and it creates an error (Event ID 2295; Data 7F00) in the
Application Log.
Details from App Log:
- System
- Provider
[ Name] Microsoft-Windows-IIS-W3SVC-WP
[ Guid] {670080D9-742A-4187-8D16-41143D1290BD}
[ EventSourceName] W3SVC-WP
- EventID 2295
[ Qualifiers] 49152
Version 0
Level 2
Task 0
Opcode 0
Keywords 0x80
- TimeCreated
[ SystemTime] 2006-10-16T02:05:59.000Z
EventRecordID 1205
Correlation
- Execution
[ ProcessID] 0
[ ThreadID] 0
Channel Application
Computer epsilon
Security
- EventData
ModuleDll C:\Inetpub\PHP\php5isapi.dll
7F00
--
Edit this bug report at http://bugs.php.net/?id=39163&edit=1
#39228 [NEW]: PDO: implement randomRow method
From: selecter at gmail dot com Operating system: Linux PHP version: 5.1.6 PHP Bug Type: Feature/Change Request Bug description: PDO: implement randomRow method Description: We need a unified method which will get a random row from a table. Please note that at least in MySQL: SELECT * FROM tablename ORDER BY rand(); is too slow on big tables. -- Edit bug report at http://bugs.php.net/?id=39228&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39228&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39228&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39228&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39228&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39228&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39228&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39228&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39228&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39228&r=support Expected behavior:http://bugs.php.net/fix.php?id=39228&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39228&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39228&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39228&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39228&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39228&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39228&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39228&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39228&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39228&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39228&r=mysqlcfg
#39221 [Opn]: php5ts.dll faulting every few minutes on apache2.2
ID: 39221 User updated by: kris at k-software dot org Reported By: kris at k-software dot org Status: Open Bug Type: Apache2 related Operating System: windows server 2003 x64 PHP Version: 5CVS-2006-10-20 (snap) New Comment: Error in CPU IDs in previous comment, from microsoft support article ID 252867: Processor enumeration on computers that use hyperthreading first assign processor numbers to the primary logical processor for each processor and then assign numbers to the secondary. For example, for dual physical processor computers with hyperthreading, the first processor has logical processor 0 and 2, and the second processor has logical processor 1 and 3. Previous Comments: [2006-10-22 13:59:13] kris at k-software dot org It appears that setting the CPU affinity of the apache http process to a single physical processor stops the crashing... Setting the server to NOT use the second hyperthreaded core of the xeons (i.e. CPUs 0+2 or 1+3) seems to solve this random crashing. Will test with a prefork MPM. [2006-10-22 12:49:58] kris at k-software dot org I'm currently unable to track down a single script/function which causes this error, and am therefore unable to provide a code sample. I realise that the bug report is pretty useless without reproducable code, so I'm still investigating and trying to track down the exact cause of the crashes. [2006-10-21 20:38:21] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If 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. [2006-10-21 12:03:28] kris at k-software dot org Dr Watson log file : Application exception occurred: App: C:\Program Files (x86)\Apache Group\Apache2\bin\httpd.exe (pid=2632) When: 10/21/2006 @ 13:02:13.937 Exception number: c005 (access violation) *> System Information <* Computer Name: SECAMSERVER1 User Name: SYSTEM Terminal Session Id: 0 Number of Processors: 4 Processor Type: EM64T Family 15 Model 4 Stepping 3 Windows Version: 5.2 Current Build: 3790 Service Pack: 1 Current Type: Multiprocessor Free *> Module List <* 003e - 003f7000: C:\WINDOWS\system32\odbcint.dll 0040 - 00405000: C:\Program Files (x86)\Apache Group\Apache2\bin\httpd.exe 007f - 00842000: C:\WINDOWS\syswow64\SHLWAPI.dll 0095 - 00e14000: C:\php5\php5ts.dll 00e2 - 00eac000: C:\WINDOWS\syswow64\OLEAUT32.dll 012b - 013bd000: c:\php5\ext\php_gd2.dll 013c - 013df000: c:\php5\ext\php_ldap.dll 013e - 01412000: C:\WINDOWS\system32\SSLEAY32.dll 0142 - 0152b000: C:\WINDOWS\system32\LIBEAY32.dll 0153 - 016ce000: c:\php5\ext\php_mbstring.dll 016d - 016dc000: c:\php5\ext\php_mysql.dll 016e - 0184a000: C:\WINDOWS\system32\LIBMYSQL.dll 0186 - 0188a000: c:\php5\ext\php_pgsql.dll 1000 - 10009000: C:\php5\php5apache2_2.dll 4bf7 - 4bfad000: C:\WINDOWS\system32\ODBC32.dll 5f27 - 5f2c9000: C:\WINDOWS\system32\hnetcfg.dll 6950 - 69517000: C:\WINDOWS\system32\faultrep.dll 6ee5 - 6ee59000: C:\Program Files (x86)\Apache Group\Apache2\bin\libapriconv-1.dll 6ee6 - 6ee89000: C:\Program Files (x86)\Apache Group\Apache2\bin\libaprutil-1.dll 6eec - 6eedf000: C:\Program Files (x86)\Apache Group\Apache2\bin\libapr-1.dll 6faf - 6faf6000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authz_user.so 6fb0 - 6fb06000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authz_host.so 6fb1 - 6fb16000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authz_groupfile.so 6fb2 - 6fb26000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authz_default.so 6fb4 - 6fb46000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authn_file.so 6fb5 - 6fb56000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authn_defa
#39221 [Opn]: php5ts.dll faulting every few minutes on apache2.2
ID: 39221 User updated by: kris at k-software dot org Reported By: kris at k-software dot org Status: Open Bug Type: Apache2 related Operating System: windows server 2003 x64 PHP Version: 5CVS-2006-10-20 (snap) New Comment: It appears that setting the CPU affinity of the apache http process to a single physical processor stops the crashing... Setting the server to NOT use the second hyperthreaded core of the xeons (i.e. CPUs 0+2 or 1+3) seems to solve this random crashing. Will test with a prefork MPM. Previous Comments: [2006-10-22 12:49:58] kris at k-software dot org I'm currently unable to track down a single script/function which causes this error, and am therefore unable to provide a code sample. I realise that the bug report is pretty useless without reproducable code, so I'm still investigating and trying to track down the exact cause of the crashes. [2006-10-21 20:38:21] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If 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. [2006-10-21 12:03:28] kris at k-software dot org Dr Watson log file : Application exception occurred: App: C:\Program Files (x86)\Apache Group\Apache2\bin\httpd.exe (pid=2632) When: 10/21/2006 @ 13:02:13.937 Exception number: c005 (access violation) *> System Information <* Computer Name: SECAMSERVER1 User Name: SYSTEM Terminal Session Id: 0 Number of Processors: 4 Processor Type: EM64T Family 15 Model 4 Stepping 3 Windows Version: 5.2 Current Build: 3790 Service Pack: 1 Current Type: Multiprocessor Free *> Module List <* 003e - 003f7000: C:\WINDOWS\system32\odbcint.dll 0040 - 00405000: C:\Program Files (x86)\Apache Group\Apache2\bin\httpd.exe 007f - 00842000: C:\WINDOWS\syswow64\SHLWAPI.dll 0095 - 00e14000: C:\php5\php5ts.dll 00e2 - 00eac000: C:\WINDOWS\syswow64\OLEAUT32.dll 012b - 013bd000: c:\php5\ext\php_gd2.dll 013c - 013df000: c:\php5\ext\php_ldap.dll 013e - 01412000: C:\WINDOWS\system32\SSLEAY32.dll 0142 - 0152b000: C:\WINDOWS\system32\LIBEAY32.dll 0153 - 016ce000: c:\php5\ext\php_mbstring.dll 016d - 016dc000: c:\php5\ext\php_mysql.dll 016e - 0184a000: C:\WINDOWS\system32\LIBMYSQL.dll 0186 - 0188a000: c:\php5\ext\php_pgsql.dll 1000 - 10009000: C:\php5\php5apache2_2.dll 4bf7 - 4bfad000: C:\WINDOWS\system32\ODBC32.dll 5f27 - 5f2c9000: C:\WINDOWS\system32\hnetcfg.dll 6950 - 69517000: C:\WINDOWS\system32\faultrep.dll 6ee5 - 6ee59000: C:\Program Files (x86)\Apache Group\Apache2\bin\libapriconv-1.dll 6ee6 - 6ee89000: C:\Program Files (x86)\Apache Group\Apache2\bin\libaprutil-1.dll 6eec - 6eedf000: C:\Program Files (x86)\Apache Group\Apache2\bin\libapr-1.dll 6faf - 6faf6000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authz_user.so 6fb0 - 6fb06000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authz_host.so 6fb1 - 6fb16000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authz_groupfile.so 6fb2 - 6fb26000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authz_default.so 6fb4 - 6fb46000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authn_file.so 6fb5 - 6fb56000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authn_default.so 6fc0 - 6fc06000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_setenvif.so 6fc1 - 6fc19000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_negotiation.so 6fc2 - 6fc27000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_mime.so 6fc3 - 6fc37000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_log_config.so 6fc4 - 6fc48000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_isapi.so 6fc5 - 6fc5a000: C:
#39221 [Fbk->Opn]: php5ts.dll faulting every few minutes on apache2.2
ID: 39221 User updated by: kris at k-software dot org Reported By: kris at k-software dot org -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: windows server 2003 x64 PHP Version: 5CVS-2006-10-20 (snap) New Comment: I'm currently unable to track down a single script/function which causes this error, and am therefore unable to provide a code sample. I realise that the bug report is pretty useless without reproducable code, so I'm still investigating and trying to track down the exact cause of the crashes. Previous Comments: [2006-10-21 20:38:21] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If 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. [2006-10-21 12:03:28] kris at k-software dot org Dr Watson log file : Application exception occurred: App: C:\Program Files (x86)\Apache Group\Apache2\bin\httpd.exe (pid=2632) When: 10/21/2006 @ 13:02:13.937 Exception number: c005 (access violation) *> System Information <* Computer Name: SECAMSERVER1 User Name: SYSTEM Terminal Session Id: 0 Number of Processors: 4 Processor Type: EM64T Family 15 Model 4 Stepping 3 Windows Version: 5.2 Current Build: 3790 Service Pack: 1 Current Type: Multiprocessor Free *> Module List <* 003e - 003f7000: C:\WINDOWS\system32\odbcint.dll 0040 - 00405000: C:\Program Files (x86)\Apache Group\Apache2\bin\httpd.exe 007f - 00842000: C:\WINDOWS\syswow64\SHLWAPI.dll 0095 - 00e14000: C:\php5\php5ts.dll 00e2 - 00eac000: C:\WINDOWS\syswow64\OLEAUT32.dll 012b - 013bd000: c:\php5\ext\php_gd2.dll 013c - 013df000: c:\php5\ext\php_ldap.dll 013e - 01412000: C:\WINDOWS\system32\SSLEAY32.dll 0142 - 0152b000: C:\WINDOWS\system32\LIBEAY32.dll 0153 - 016ce000: c:\php5\ext\php_mbstring.dll 016d - 016dc000: c:\php5\ext\php_mysql.dll 016e - 0184a000: C:\WINDOWS\system32\LIBMYSQL.dll 0186 - 0188a000: c:\php5\ext\php_pgsql.dll 1000 - 10009000: C:\php5\php5apache2_2.dll 4bf7 - 4bfad000: C:\WINDOWS\system32\ODBC32.dll 5f27 - 5f2c9000: C:\WINDOWS\system32\hnetcfg.dll 6950 - 69517000: C:\WINDOWS\system32\faultrep.dll 6ee5 - 6ee59000: C:\Program Files (x86)\Apache Group\Apache2\bin\libapriconv-1.dll 6ee6 - 6ee89000: C:\Program Files (x86)\Apache Group\Apache2\bin\libaprutil-1.dll 6eec - 6eedf000: C:\Program Files (x86)\Apache Group\Apache2\bin\libapr-1.dll 6faf - 6faf6000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authz_user.so 6fb0 - 6fb06000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authz_host.so 6fb1 - 6fb16000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authz_groupfile.so 6fb2 - 6fb26000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authz_default.so 6fb4 - 6fb46000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authn_file.so 6fb5 - 6fb56000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_authn_default.so 6fc0 - 6fc06000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_setenvif.so 6fc1 - 6fc19000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_negotiation.so 6fc2 - 6fc27000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_mime.so 6fc3 - 6fc37000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_log_config.so 6fc4 - 6fc48000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_isapi.so 6fc5 - 6fc5a000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_include.so 6fc6 - 6fc67000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_imagemap.so 6fc7 - 6fc76000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_env.so 6fc8 - 6fc86000: C:\Program Files (x86)\Apache Group\Apache2\modules\mod_dir.so 6fc90
