#39321 [Com]: $_FILES empty with enctype=multipart/form-data
ID: 39321 Comment by: judas dot iscariote at gmail dot com Reported By: josh at pixael dot com Status: Open Bug Type: Variables related Operating System: linux PHP Version: 4.4.4 New Comment: this has been reported before, and seems to be a internet explorer bug. nothing to do with PHP I think. Previous Comments: [2006-10-31 15:33:17] josh at pixael dot com Description: i'm trying to upload a file via ssl in a form with method post and enctype=multipart/form-data if i upload a gif or jpg is all right if i upload a txt or a pdf or other with INTERNET EXPLORER $_FILES and $_POST is empty with firefox i've no problem php version 4.3.9 this is the url of the test https://www.service-store.com/tst.php Reproduce code: --- File Upload Test '; print_r($_POST); echo'Print $_FILES'; print_r($_FILES); ?> Send this file: -- Edit this bug report at http://bugs.php.net/?id=39321&edit=1
#38698 [Asn]: for some keys cdbmake creates corrupted db and cdb can't read valid db.
ID: 38698 Updated by: [EMAIL PROTECTED] Reported By: oleg1917 at mail dot ru Status: Assigned Bug Type: DBM/DBA related -Operating System: centos 4.3 +Operating System: * -PHP Version: 5.1.6 +PHP Version: 5.2.0 Assigned To: helly New Comment: Fixed in head, will get fixed in 5.2.1 Previous Comments: [2006-09-12 16:40:40] oleg1917 at mail dot ru this one http://kudiz.com/129test.cdb is created by Bernstein's cdbmake utility. [2006-09-12 15:25:31] [EMAIL PROTECTED] That's the PHP generated db, do you have the one made outside of PHP? [2006-09-05 15:07:04] oleg1917 at mail dot ru here is it http://kudiz.com/129php.cdb i've got the same result on several boxes with centos 4.x, trustix 2.x distros and php 5.1.x [2006-09-05 14:38:35] [EMAIL PROTECTED] Can you please provide a copy of the 129php.cdb file. [2006-09-03 13:16:08] oleg1917 at mail dot ru Description: i used integer numbers packed into binary strings as keys. for some numbers dba's cdbmake handler produces files that can't be read by Bernshtein's tools like cdbtest and CPAN's perl module CDB_File. And vice versa files produced by Bernshtein's cdbmake and CPAN's perl module CDB_File can't be read by dba's cdb handler. Reproduce code: --- Expected result: database handler: cdb_make string(32) "1f34b74bde3744265acfc21e0f30af95" string(32) "1f34b74bde3744265acfc21e0f30af95" Actual result: -- database handler: cdb_make string(32) "1f34b74bde3744265acfc21e0f30af95" string(32) "b9ee8bfe966a01e287f8aa45b3fcc958" -- Edit this bug report at http://bugs.php.net/?id=38698&edit=1
#38478 [Asn->Bgs]: reset() does not work as expected on Iterator implementations
ID: 38478
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Bogus
Bug Type: SPL related
-Operating System: Gentoo
+Operating System: *
-PHP Version: 5.2.0RC1
+PHP Version: 5.2.0
Assigned To: helly
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
In PHP objects are also arrays of their properties and reset and
friends only work on real arrays. Thus the result is correct.
Previous Comments:
[2006-08-17 08:20:07] [EMAIL PROTECTED]
Description:
The Iterator interface (SPL) defines a method rewind(). When
implementing e.g. ArrayIterator to allow array access to an object, one
would expect that reset($object) would use the rewind method. This does
not happen, but the first property is returned.
Reproduce code:
---
'one',
2 => 'two',
3 => 'three',
);
public function rewind()
{
return reset( $this->prop );
}
public function key()
{
return key( $this->prop );
}
public function current()
{
return current( $this->prop );
}
public function next()
{
return next( $this->prop );
}
public function valid()
{
return ( current( $this->prop ) !== false );
}
}
$array = new testArray();
Expected result:
// Expected: string(3) "one"
var_dump( $array->rewind() );
// Expected: string(3) "one"
var_dump( reset( $array ) );
Actual result:
--
// As expected: string(3) "one"
var_dump( $array->rewind() );
// Expected: string(3) "one"
var_dump( reset( $array ) );
/* Got:
array(3) {
[1]=>
string(3) "one"
[2]=>
string(3) "two"
[3]=>
string(5) "three"
}
*/
--
Edit this bug report at http://bugs.php.net/?id=38478&edit=1
#39090 [Asn]: DirectoryFilterDots doxygen docs and example is wrong
ID: 39090 Updated by: [EMAIL PROTECTED] Reported By: judas dot iscariote at gmail dot com Status: Assigned Bug Type: SPL related -Operating System: Irrelevant +Operating System: * -PHP Version: 5CVS-2006-10-09 (CVS) +PHP Version: 5.2.0 Assigned To: helly New Comment: Fixed in 6, will get fixed in 5.2.1. Previous Comments: [2006-10-09 09:51:55] judas dot iscariote at gmail dot com Description: DirectoryFilterDots example [1] ) and docs [2] are wrong. example [1] says : parent::__construct(new DirectoryIterator($path)); must say : parent::__construct(new RecursiveDirectoryIterator($path)); Documentation say: This Iteraotr takes a pathname from which it creates a DirectoryIterator... must say : This **Iterator** takes a pathname from which it creates a **RecursiveDirectoryIterator**... [1] ext/spl/examples/directoryfilterdots.inc [2] http://www.php.net/~helly/php/ext/spl/classDirectoryFilterDots.html Reproduce code: --- Expected result: shiny new iterator containing the directory listing without dots. Actual result: -- Catchable fatal error: Argument 1 passed to RecursiveFilterIterator::__construct() must implement interface RecursiveIterator, instance of DirectoryIterator given -- Edit this bug report at http://bugs.php.net/?id=39090&edit=1
#39151 [Asn->Csd]: Parse error in recursiveiteratoriterator.php
ID: 39151 Updated by: [EMAIL PROTECTED] Reported By: harvey dot robin at gmail dot com -Status: Assigned +Status: Closed Bug Type: SPL related -Operating System: Linux, Ubuntu +Operating System: * -PHP Version: 5.2.0RC5 +PHP Version: 5.2.0 Assigned To: helly New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-10-13 19:53:45] harvey dot robin at gmail dot com Description: Hi, I noticed a parse error in the file ext/spl/internal/recursiveiteratoriterator.inc. The same error is in the web cvs view here: http://cvs.php.net/viewvc.cgi/php-src/ext/spl/internal/recursiveiteratoriterator.inc?view=markup The error is on line 220, or 152, depending on whether there are any comments in it. Many thanks, Robin Harvey Reproduce code: --- php -l ext/spl/internal/recursiveiteratoriterator.inc Actual result: -- Parse error: syntax error, unexpected T_VARIABLE in ext/spl/internal/recursiveiteratoriterator.inc on line 220 -- Edit this bug report at http://bugs.php.net/?id=39151&edit=1
#39313 [Opn]: spl_autoload triggers Fatal error
ID: 39313
Updated by: [EMAIL PROTECTED]
Reported By: justin dot foell at sellingsource dot com
Status: Open
Bug Type: SPL related
-Operating System: Gentoo Linux
+Operating System: *
-PHP Version: 5.1.6
+PHP Version: 5.2.0
-Assigned To:
+Assigned To: helly
New Comment:
I see your point, will get fixed in 6.0 and in 5.2.1 hopefully.
Previous Comments:
[2006-10-31 21:00:12] justin dot foell at sellingsource dot com
This may possibly be due to the fact that the Zend engine will turn any
thrown exceptions in the __autoload method into Fatal errors.
[2006-10-31 20:51:08] justin dot foell at sellingsource dot com
Maybe your explanation and/or the SPL autoload documentation is
unclear... but if I have two functions registered with the SPL
autoloader, the default 'spl_autoload' being the first and my own being
the second, the class will not be loaded even though the seconds
autoloader would normally find it (and will find it if it's first in
the stack). So it seems it is failing not if _NO_ autoloaders find the
class, but if the first 'spl_autoload' method does not find the class.
This has been tested on PHP (cli) 5.1.6 on both Gentoo and Ubuntu as
well as with the php5.2-200610311730 snapshot.
The issue is that the spl_autoload C code throws and exception if the
class is not found:
//php_spl.c - line 310:
if (!found) {
zend_throw_exception_ex(spl_ce_LogicException, 0 TSRMLS_CC,
"Class %s could not be loaded", class_name);
}
This stops further excecution of any autoloaders. When commented out,
it works as I would expect it to, failing silently then continuing to
the next registered loader.
[2006-10-31 18:43:05] [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
The order is respected as you described. But if you are using a non
existing class the __autoload facility starts its work. And that means
spl\'s autoload stuff is being invoked. That then calls all registered
autoload functions one after another. And only if all fail you get an
error, where the error is generated from the spl autoload handling
system and send to the engine\'s autoload facility.
[2006-10-31 00:27:44] justin dot foell at sellingsource dot com
Description:
If the default spl_autoload function is at the top of the stack and the
class is not found, a Fatal error is triggered. I would think you would
want to fail silently, that way the fast C code can be used first, then
fall-back to your custom PHP Code. Then if the class is still not
found, let PHP deal with it.
The following code will work if the two spl_autoload_register lines are
switched.
Reproduce code:
---
Expected result:
Array
(
[0] => spl_autoload
[1] => myloader
)
MyClass
Actual result:
--
Array
(
[0] => spl_autoload
[1] => myloader
)
Fatal error: Class 'MyClass' not found in
/virtualhosts/justin/test/test.php on line 12
--
Edit this bug report at http://bugs.php.net/?id=39313&edit=1
#39326 [Opn]: dbase_open can't open database
ID: 39326
User updated by: jabc at moz dot com dot mx
Reported By: jabc at moz dot com dot mx
Status: Open
Bug Type: dBase related
Operating System: FreeBSD 6.2-PRERELEASE
PHP Version: 5.1.6
New Comment:
we determine that the problem was the type of fields, we have four
fields with type 'date time' and when we change to type 'date' it
work.
But in version php4.4 it work fine with this type of fields.
try to test with this database that contain the four fields type 'date
time' and try to modify this fields to type 'date' for verify that work
it
http://148.223.129.153/soporte/complete.zip
thanks
Previous Comments:
[2006-10-31 22:05:47] jabc at moz dot com dot mx
Description:
when I try to open an database with more than 150 fields can't open it.
only If I delete fields under 150 can do it.
on version 4.4 it work very fine.
the error say: unable to open database
of course STCTRL21.DBF exist and have all permissions.
Reproduce code:
---
$dbi = dbase_open("/reco/RECO2005/TRAFICO/DATA/STCTRL21.DBF", 0);
if ($dbi === false)
print "unable to open database";
Expected result:
No errors and the database opened.
Actual result:
--
unable to open database
--
Edit this bug report at http://bugs.php.net/?id=39326&edit=1
#39320 [Opn->Csd]: ZEND_HASH_APPLY_STOP causes deletion
ID: 39320 Updated by: [EMAIL PROTECTED] Reported By: wharmby at uk dot ibm dot com -Status: Open +Status: Closed Bug Type: Scripting Engine problem -Operating System: Windows XP +Operating System: * -PHP Version: 5CVS-2006-10-31 (snap) +PHP Version: 5.2.* -Assigned To: +Assigned To: helly New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Might get fixed later in 5.2 Previous Comments: [2006-10-31 11:39:40] wharmby at uk dot ibm dot com Description: Specifying hash apply call-back function return code of ZEND_HASH_APPLY_STOP results in deletion of current element from subject hash table rather than halting of iteration as expected, i.e ZEND_HASH_APPLY_STOP treated same as ZEND_HASH_APPLY_REMOVE. I spotted this bug reviewing code the engine code whilst reading Sara Golemon's book "Extending and Embedding PHP". The meanings of the various callback return codes are listed on page 99 and the text suggests they can all be used by all the hash_apply_* functions. No comments in code or online documentation on php.net suggest otherwise. The test case below uses zend_hash_apply() but the defect, if indeed it is a defect, exists in all 3 zend_hash_apply functions; namely: ZEND_API void zend_hash_apply(HashTable *ht, apply_func_t apply_func TSRMLS_DC); ZEND_API void zend_hash_apply_with_argument( HashTable *ht, apply_func_arg_t apply_func, void * TSRMLS_DC); ZEND_API void zend_hash_apply_with_arguments( HashTable *ht, apply_func_args_t apply_func, int numargs, ...); All 3 functions delete the current entry on a non-zero return from the "apply_func". I have reviewed the open defects and can see no defect which covers the reported behaviour. I have tried the latest snap-shot build for Windows which at the time was "Oct 31, 2006 09:30 GMT" phpinfo() shows PHP version as "Version => 5.2.1-dev". Problem also persists in latest checked in version of file in CVS. Andy Wharmby IBM United Kingdom Limited Reproduce code: --- Reproduce code is posted here: http://pastebin.ca/230657 Possible fix to zend_hash.c posted here: http://pastebin.ca/230668 Expected result: Test 1: zend_hash_apply with stop colour red Stop_on_red called for element: orange Stop_on_red called for element: green Stop_on_red called for element: blue Stop_on_red called for element: red Array contents after test: orange green blue red yellow purple indigo TEST 1 PASSED Test 2: zend_hash_apply_with_argument with stop colour prurple Stop_on_colour called for element:orange Stop_on_colour called for element:green Stop_on_colour called for element:blue Stop_on_colour called for element:red Stop_on_colour called for element:yellow Stop_on_colour called for element:purple Array contents after test: orange green blue red yellow purple indigo TEST 2 PASSED Test 3: zend_hash_apply_with_arguments with stop colours yellow and black Stop_on_either_colour called for element: orange Stop_on_either_colour called for element: green Stop_on_either_colour called for element: blue Stop_on_either_colour called for element: red Stop_on_either_colour called for element: yellow Array contents after test: orange green blue red yellow purple indigo TEST 3 PASSED Actual result: -- Test 1: zend_hash_apply with stop colour red Stop_on_red called for element: orange Stop_on_red called for element: green Stop_on_red called for element: blue Stop_on_red called for element: red Stop_on_red called for element: yellow Stop_on_red called for element: purple Stop_on_red called for element: indigo Array contents after test: orange green blue yellow purple indigo TEST 1 FAILED Test 2: zend_hash_apply_with_argument with stop colour prurple Stop_on_colour called for element:orange Stop_on_colour called for element:green Stop_on_colour called for element:blue Stop_on_colour called for element:red Stop_on_colour called for element:yellow Stop_on_colour called for element:purple Stop_on_colour called for element:indigo Array contents after test: orange green blue red yellow indigo TEST 2 FAILED Test 3: zend_hash_apply_with_arguments with stop colours yellow and black Stop_on_either_colour called for element: orange Stop_on_either_colour called for element: green Stop_on_either_colour called for element: blue Stop_on_either_colour called for element: red Stop_on_either_colour called for element: yellow Stop_on_either_colour called for element: purpl
#39326 [NEW]: dbase_open can't open database
From: jabc at moz dot com dot mx
Operating system: FreeBSD 6.2-PRERELEASE
PHP version: 5.1.6
PHP Bug Type: dBase related
Bug description: dbase_open can't open database
Description:
when I try to open an database with more than 150 fields can't open it.
only If I delete fields under 150 can do it.
on version 4.4 it work very fine.
the error say: unable to open database
of course STCTRL21.DBF exist and have all permissions.
Reproduce code:
---
$dbi = dbase_open("/reco/RECO2005/TRAFICO/DATA/STCTRL21.DBF", 0);
if ($dbi === false)
print "unable to open database";
Expected result:
No errors and the database opened.
Actual result:
--
unable to open database
--
Edit bug report at http://bugs.php.net/?id=39326&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39326&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39326&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39326&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39326&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39326&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39326&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39326&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39326&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39326&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39326&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39326&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39326&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39326&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39326&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39326&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39326&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39326&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39326&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39326&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39326&r=mysqlcfg
#39313 [Bgs->Opn]: spl_autoload triggers Fatal error
ID: 39313
User updated by: justin dot foell at sellingsource dot com
Reported By: justin dot foell at sellingsource dot com
-Status: Bogus
+Status: Open
Bug Type: SPL related
Operating System: Gentoo Linux
PHP Version: 5.1.6
New Comment:
This may possibly be due to the fact that the Zend engine will turn any
thrown exceptions in the __autoload method into Fatal errors.
Previous Comments:
[2006-10-31 20:51:08] justin dot foell at sellingsource dot com
Maybe your explanation and/or the SPL autoload documentation is
unclear... but if I have two functions registered with the SPL
autoloader, the default 'spl_autoload' being the first and my own being
the second, the class will not be loaded even though the seconds
autoloader would normally find it (and will find it if it's first in
the stack). So it seems it is failing not if _NO_ autoloaders find the
class, but if the first 'spl_autoload' method does not find the class.
This has been tested on PHP (cli) 5.1.6 on both Gentoo and Ubuntu as
well as with the php5.2-200610311730 snapshot.
The issue is that the spl_autoload C code throws and exception if the
class is not found:
//php_spl.c - line 310:
if (!found) {
zend_throw_exception_ex(spl_ce_LogicException, 0 TSRMLS_CC,
"Class %s could not be loaded", class_name);
}
This stops further excecution of any autoloaders. When commented out,
it works as I would expect it to, failing silently then continuing to
the next registered loader.
[2006-10-31 18:43:05] [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
The order is respected as you described. But if you are using a non
existing class the __autoload facility starts its work. And that means
spl\'s autoload stuff is being invoked. That then calls all registered
autoload functions one after another. And only if all fail you get an
error, where the error is generated from the spl autoload handling
system and send to the engine\'s autoload facility.
[2006-10-31 00:27:44] justin dot foell at sellingsource dot com
Description:
If the default spl_autoload function is at the top of the stack and the
class is not found, a Fatal error is triggered. I would think you would
want to fail silently, that way the fast C code can be used first, then
fall-back to your custom PHP Code. Then if the class is still not
found, let PHP deal with it.
The following code will work if the two spl_autoload_register lines are
switched.
Reproduce code:
---
Expected result:
Array
(
[0] => spl_autoload
[1] => myloader
)
MyClass
Actual result:
--
Array
(
[0] => spl_autoload
[1] => myloader
)
Fatal error: Class 'MyClass' not found in
/virtualhosts/justin/test/test.php on line 12
--
Edit this bug report at http://bugs.php.net/?id=39313&edit=1
#39313 [Bgs]: spl_autoload triggers Fatal error
ID: 39313
User updated by: justin dot foell at sellingsource dot com
Reported By: justin dot foell at sellingsource dot com
Status: Bogus
Bug Type: SPL related
Operating System: Gentoo Linux
PHP Version: 5.1.6
New Comment:
Maybe your explanation and/or the SPL autoload documentation is
unclear... but if I have two functions registered with the SPL
autoloader, the default 'spl_autoload' being the first and my own being
the second, the class will not be loaded even though the seconds
autoloader would normally find it (and will find it if it's first in
the stack). So it seems it is failing not if _NO_ autoloaders find the
class, but if the first 'spl_autoload' method does not find the class.
This has been tested on PHP (cli) 5.1.6 on both Gentoo and Ubuntu as
well as with the php5.2-200610311730 snapshot.
The issue is that the spl_autoload C code throws and exception if the
class is not found:
//php_spl.c - line 310:
if (!found) {
zend_throw_exception_ex(spl_ce_LogicException, 0 TSRMLS_CC,
"Class %s could not be loaded", class_name);
}
This stops further excecution of any autoloaders. When commented out,
it works as I would expect it to, failing silently then continuing to
the next registered loader.
Previous Comments:
[2006-10-31 18:43:05] [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
The order is respected as you described. But if you are using a non
existing class the __autoload facility starts its work. And that means
spl\'s autoload stuff is being invoked. That then calls all registered
autoload functions one after another. And only if all fail you get an
error, where the error is generated from the spl autoload handling
system and send to the engine\'s autoload facility.
[2006-10-31 00:27:44] justin dot foell at sellingsource dot com
Description:
If the default spl_autoload function is at the top of the stack and the
class is not found, a Fatal error is triggered. I would think you would
want to fail silently, that way the fast C code can be used first, then
fall-back to your custom PHP Code. Then if the class is still not
found, let PHP deal with it.
The following code will work if the two spl_autoload_register lines are
switched.
Reproduce code:
---
Expected result:
Array
(
[0] => spl_autoload
[1] => myloader
)
MyClass
Actual result:
--
Array
(
[0] => spl_autoload
[1] => myloader
)
Fatal error: Class 'MyClass' not found in
/virtualhosts/justin/test/test.php on line 12
--
Edit this bug report at http://bugs.php.net/?id=39313&edit=1
#39325 [Opn->Bgs]: Apache child core-dumps while trying to show php page
ID: 39325 Updated by: [EMAIL PROTECTED] Reported By: mihai at all4u dot ro -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Mandriva Corporate 4 PHP Version: 5.1.6 New Comment: This seems to be a problem in the PECL Tk extension which shouldn't be enabled in a web server context. Furthermore PECL related problems should be reported at pecl.php.net. Thanks. Previous Comments: [2006-10-31 17:41:55] mihai at all4u dot ro Description: Apache version: 2.2.3 Core-dump is generated after php page with instructions like fwrite is shown Reproduce code: --- fwrite() Actual result: -- #0 0x2c0a1554 in fwrite () from /lib64/tls/libc.so.6 #1 0x2aaabcf68e25 in zm_deactivate_php_tk () from /usr/lib64/php/extensions/tk.so #2 0x2f3c2209 in module_registry_cleanup () from /usr/lib64/libphp5_common.so.5 #3 0x2f3c8d0f in zend_hash_apply () from /usr/lib64/libphp5_common.so.5 #4 0x2f3bf1f4 in zend_deactivate_modules () from /usr/lib64/libphp5_common.so.5 #5 0x2f380225 in php_request_shutdown () from /usr/lib64/libphp5_common.so.5 #6 0x2f122cad in php_ap2_register_hook () from /etc/httpd/extramodules/mod_php5.so #7 0x00433975 in ap_run_handler () #8 0x00433d72 in ap_invoke_handler () #9 0x00440960 in ap_process_request () #10 0x0043e06d in ap_filter_protocol () #11 0x0043a305 in ap_run_process_connection () #12 0x00444648 in ap_graceful_stop_signalled () #13 0x004448d4 in ap_graceful_stop_signalled () #14 0x0044494d in ap_graceful_stop_signalled () #15 0x00445430 in ap_mpm_run () #16 0x00420fe2 in main () -- Edit this bug report at http://bugs.php.net/?id=39325&edit=1
#39316 [Fbk->Opn]: extension_dir has no effect on Windows
ID: 39316 User updated by: aren at cambre dot biz Reported By: aren at cambre dot biz -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows Server 2003 PHP Version: 5.1.6 New Comment: That did not fix it. I deleted everything in C:\php, including directories, except for php.ini. Then I copied over the contents of php5.2-win32-latest.zip and did an iisreset (a command line program that restarts the web server). By the way, it looks like php is checking a couple of additional directories besides those specified in the path. Here is my path (each directory on a separate line): %SystemRoot%\system32 %SystemRoot% %SystemRoot%\System32\Wbem c:\Program Files\Intel\DMIX C:\Program Files\Microsoft SQL Server\80\Tools\Binn\ c:\Program Files\Microsoft SQL Server\90\Tools\binn\ c:\php Here is what PHP checks: C:\windows\system32\inetsrv\php_mysql.dll C:\WINDOWS\system32\php_mysql.dll C:\WINDOWS\system\php_mysql.dll C:\WINDOWS\php_mysql.dll C:\WINDOWS\system32\inetsrv\php_mysql.dll C:\WINDOWS\system32\php_mysql.dll C:\WINDOWS\php_mysql.dll C:\WINDOWS\System32\Wbem\php_mysql.dll C:\Program Files\Intel\DMIX\php_mysql.dll C:\Program Files\Microsoft SQL Server\80\Tools\Binn\php_mysql.dll C:\Program Files\Microsoft SQL Server\90\Tools\binn\php_mysql.dll C:\php\php_mysql.dll PHP follows the path exactly starting with the 6th line. The first 5 lines are some unknown set of directories. PHP checks those directories twice in a row. Previous Comments: [2006-10-31 11:32:17] [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-31 04:49:18] aren at cambre dot biz Description: extension_dir (in php.ini) has no effect in Windows. I installed a relatively clean installation of PHP 5.1.6 on Windows 2003. I configured the extension_dir line in php.ini using all these forms: extension_dir = c:\PHP\ext extension_dir = c:\php\ext extension_dir = c:/PHP/ext extension_dir = "c:\php\ext" Regardless of the form used, php does not even attempt to search the c:\php\ext directory to find extensions. Reproduce code: --- 1. Install php 5.1.6 on a clean Windows system. Only configure what is necessary to get it running. Be sure to set extension_dir to your actual ext directory. (Preferably, c:\php\ext.) Do a hello world php to test functionality. 2. Uncomment this line in php.ini: extension=php_mysql.dll 3. Download the latest phpMyAdmin. Extract files and copy to a directory in your web server. 4. Get File Monitor from sysinternals (www.sysinternals.com). 5. Load File Monitor, and set its filter to php_mysql.dll. (This is so that it just reports on attempts to find php_mysql.dll and not hundreds of other filesystem hits.) 6. Start File Monitor so that it's catching filesystem hits. 7. Browse myPhpAdmin's index.php in a browser. You'll get an error saying that the mysql drivers cannot be used. 8. Go back to File Monitor. Notice how none of the directories searched were the directory specified in extension_dir. Installing mySql is optional. Its presence has no effect on the above problem. (Of course, if the system actually found php_mysql.dll, then it would be a problem if mySql was not installed!) Expected result: phpMyAdmin should find the mySql extension, and File Monitor should confirm that php actually searches the c:\php\ext directory for the extensions. Actual result: -- Php searches all directories in the system path! extension_dir has no effect under Windows. You have to add c:\php AND c:\php\ext to the system path. I think this is likely an application bug because the documentation is quite clear on how extension_dir should be configured. -- Edit this bug report at http://bugs.php.net/?id=39316&edit=1
#39313 [Opn->Bgs]: spl_autoload triggers Fatal error
ID: 39313 Updated by: [EMAIL PROTECTED] Reported By: justin dot foell at sellingsource dot com -Status: Open +Status: Bogus Bug Type: SPL related Operating System: Gentoo Linux PHP Version: 5.1.6 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 The order is respected as you described. But if you are using a non existing class the __autoload facility starts its work. And that means spl's autoload stuff is being invoked. That then calls all registered autoload functions one after another. And only if all fail you get an error, where the error is generated from the spl autoload handling system and send to the engine's autoload facility. Previous Comments: [2006-10-31 00:27:44] justin dot foell at sellingsource dot com Description: If the default spl_autoload function is at the top of the stack and the class is not found, a Fatal error is triggered. I would think you would want to fail silently, that way the fast C code can be used first, then fall-back to your custom PHP Code. Then if the class is still not found, let PHP deal with it. The following code will work if the two spl_autoload_register lines are switched. Reproduce code: --- Expected result: Array ( [0] => spl_autoload [1] => myloader ) MyClass Actual result: -- Array ( [0] => spl_autoload [1] => myloader ) Fatal error: Class 'MyClass' not found in /virtualhosts/justin/test/test.php on line 12 -- Edit this bug report at http://bugs.php.net/?id=39313&edit=1
#39325 [NEW]: Apache child core-dumps while trying to show php page
From: mihai at all4u dot ro Operating system: Mandriva Corporate 4 PHP version: 5.1.6 PHP Bug Type: Apache2 related Bug description: Apache child core-dumps while trying to show php page Description: Apache version: 2.2.3 Core-dump is generated after php page with instructions like fwrite is shown Reproduce code: --- fwrite() Actual result: -- #0 0x2c0a1554 in fwrite () from /lib64/tls/libc.so.6 #1 0x2aaabcf68e25 in zm_deactivate_php_tk () from /usr/lib64/php/extensions/tk.so #2 0x2f3c2209 in module_registry_cleanup () from /usr/lib64/libphp5_common.so.5 #3 0x2f3c8d0f in zend_hash_apply () from /usr/lib64/libphp5_common.so.5 #4 0x2f3bf1f4 in zend_deactivate_modules () from /usr/lib64/libphp5_common.so.5 #5 0x2f380225 in php_request_shutdown () from /usr/lib64/libphp5_common.so.5 #6 0x2f122cad in php_ap2_register_hook () from /etc/httpd/extramodules/mod_php5.so #7 0x00433975 in ap_run_handler () #8 0x00433d72 in ap_invoke_handler () #9 0x00440960 in ap_process_request () #10 0x0043e06d in ap_filter_protocol () #11 0x0043a305 in ap_run_process_connection () #12 0x00444648 in ap_graceful_stop_signalled () #13 0x004448d4 in ap_graceful_stop_signalled () #14 0x0044494d in ap_graceful_stop_signalled () #15 0x00445430 in ap_mpm_run () #16 0x00420fe2 in main () -- Edit bug report at http://bugs.php.net/?id=39325&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39325&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39325&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39325&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39325&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39325&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39325&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39325&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39325&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39325&r=support Expected behavior:http://bugs.php.net/fix.php?id=39325&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39325&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39325&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39325&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39325&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39325&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39325&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39325&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39325&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39325&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39325&r=mysqlcfg
#39322 [NEW]: proc_terminate(): loosing process resource
From: c dot affolter at stepping-stone dot ch
Operating system: Linux 2.4
PHP version: 5.1.6
PHP Bug Type: Program Execution
Bug description: proc_terminate(): loosing process resource
Description:
After sending a signal via proc_terminate() to a process, the process
resource gets closed immediately.
This means that calling proc_get_status() afterwards, will throw a warning
about an invalid process resource.
This behaviour is somewhat cumbersomely, since you're unable to check if
it was your signal which has caused the process to terminate or if the
process has stopped.
Is this a bug or an undocumented behaviour?
BTW:
Sending a signal via the shell or through posix_kill(), will retain the
status for the first proc_get_status() call.
Reproduce code:
---
array('pipe', 'r'),
1 => array('pipe', 'w'),
2 => array('pipe', 'w'));
$pipes = array();
$process = proc_open('/bin/sleep 120', $descriptors, $pipes);
proc_terminate($process);
var_dump(proc_get_status($process));
?>
Expected result:
array(8) {
["command"]=>
string(14) "/bin/sleep 120"
["pid"]=>
int(23011)
["running"]=>
bool(false)
["signaled"]=>
bool(true)
["stopped"]=>
bool(false)
["exitcode"]=>
int(-1)
["termsig"]=>
int(15)
["stopsig"]=>
int(0)
}
Actual result:
--
Warning: proc_get_status(): 7 is not a valid process resource in ...
--
Edit bug report at http://bugs.php.net/?id=39322&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39322&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39322&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39322&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39322&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39322&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39322&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39322&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39322&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39322&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39322&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39322&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39322&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39322&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39322&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39322&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39322&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39322&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39322&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39322&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39322&r=mysqlcfg
#39324 [Opn]: url wrappers
ID: 39324
User updated by: omikorn at yahoo dot com
Reported By: omikorn at yahoo dot com
Status: Open
Bug Type: HTTP related
Operating System: all
PHP Version: 4.4.4
New Comment:
URGENT,
Please make this private or edit post and obfuscate the encoded
credentials in my capture.
Previous Comments:
[2006-10-31 17:06:19] omikorn at yahoo dot com
Description:
Ok there is a problem with URL wrappers when the remote server requires
authentification.
Reproduce code:
---
Take file_get_contents for example:
//example code
$user="user";
$pass="somepassword";
$url = "www.whatever.com/members/messages.xml"
$content = file_get_contents("http://$user:[EMAIL PROTECTED]");
$echo "Your new message is\n";
On the packet capture the things show like this:
T 65.111.170.157:33470 -> 196.34.149.111:80 [AP]
GET /members/messages.xml HTTP/1.0\r\n
HTTP/1.0\r\n
##
T 65.111.170.157:33470 -> 196.34.149.111:80 [AP]
Authorization: Basic bWI1MTptYXJpbHluMw==\r\nHost:
www.property24online.co.za\r\n\r\n
Of course this failes. Wouldn't it be correct to pass the auth
credentials _before_ the HTTP method is specified and more assign a
temporary cookie?
e.g:
GET /members/messages.xml HTTP/1.0\r\n
Authorization: Basic bWI1MTptYXJpbHluMw==\r\nHost:
www.property24online.co.za\r\n
HTTP/1.0\r\n\r\n
--
Edit this bug report at http://bugs.php.net/?id=39324&edit=1
#39324 [NEW]: url wrappers
From: omikorn at yahoo dot com
Operating system: all
PHP version: 4.4.4
PHP Bug Type: HTTP related
Bug description: url wrappers
Description:
Ok there is a problem with URL wrappers when the remote server requires
authentification.
Reproduce code:
---
Take file_get_contents for example:
//example code
$user="user";
$pass="somepassword";
$url = "www.whatever.com/members/messages.xml"
$content = file_get_contents("http://$user:[EMAIL PROTECTED]");
$echo "Your new message is\n";
On the packet capture the things show like this:
T 65.111.170.157:33470 -> 196.34.149.111:80 [AP]
GET /members/messages.xml HTTP/1.0\r\n
HTTP/1.0\r\n
##
T 65.111.170.157:33470 -> 196.34.149.111:80 [AP]
Authorization: Basic bWI1MTptYXJpbHluMw==\r\nHost:
www.property24online.co.za\r\n\r\n
Of course this failes. Wouldn't it be correct to pass the auth credentials
_before_ the HTTP method is specified and more assign a temporary cookie?
e.g:
GET /members/messages.xml HTTP/1.0\r\n
Authorization: Basic bWI1MTptYXJpbHluMw==\r\nHost:
www.property24online.co.za\r\n
HTTP/1.0\r\n\r\n
--
Edit bug report at http://bugs.php.net/?id=39324&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39324&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39324&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39324&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39324&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39324&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39324&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39324&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39324&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39324&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39324&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39324&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39324&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39324&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39324&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39324&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39324&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39324&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39324&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39324&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39324&r=mysqlcfg
#39319 [Opn->Bgs]: Problem to connect to SQLSERVER 2005
ID: 39319
Updated by: [EMAIL PROTECTED]
Reported By: luiscervantesjane at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: MSSQL related
Operating System: WINDOWS 2003
PHP Version: 5.1.6
New Comment:
The MSSQL extension uses ntwdblib to connect to the server. This
Microsoft library can be configured with Netbios or TCP/IP as the
default library.
Use the Client Network Tools to specify the default protocol and to
create server aliases. A server alias can be defined to use a specific
host name and port numbr and you can use the alias as the first
parameter to mssql_connect().
Previous Comments:
[2006-10-31 11:03:36] luiscervantesjane at hotmail dot com
Description:
The web server are running in windows 2003, Version Apache/2.0.55
(Win32) PHP/5.1.6. And when I try to connect to MSSQL 2005 over
windows2003, I can`t.
If the code move to another server windows 2000, with the same Apache
Version, PHP 5.1.6. The connection is OK.
I belive that there are a problem the connection with SO windows2003
where are running php.
Thanks
Reproduce code:
---
$SERVER="SATURNO\SATURNO";
$USER="USER";
$PASSWD="PASSWORD";
$link = mssql_connect($SERVER, $USER, $PASSWD) or die ("Could not
connect MSSQL");
mssql_select_db($DATABASE,$link) or die ("Could not select database " .
$DATABASE. " in MSSQL");
$query = "Select * form TABLA";
$result = mssql_query($link,$query);
while ($row = mssql_fetch_array($result)){
print $row['ALU_NOMBRE'] . "";
}
Expected result:
Warning: mssql_connect() [function.mssql-connect]: Unable to connect to
server: SATURNO\SATURNO in C:\WEB\PRUEBAS\SQL2005\index2.php on line 5
Could not connect MSSQL
--
Edit this bug report at http://bugs.php.net/?id=39319&edit=1
#39321 [NEW]: $_FILES empty with enctype=multipart/form-data
From: josh at pixael dot com Operating system: linux PHP version: 4.4.4 PHP Bug Type: Variables related Bug description: $_FILES empty with enctype=multipart/form-data Description: i'm trying to upload a file via ssl in a form with method post and enctype=multipart/form-data if i upload a gif or jpg is all right if i upload a txt or a pdf or other with INTERNET EXPLORER $_FILES and $_POST is empty with firefox i've no problem php version 4.3.9 this is the url of the test https://www.service-store.com/tst.php Reproduce code: --- File Upload Test '; print_r($_POST); echo'Print $_FILES'; print_r($_FILES); ?> Send this file: -- Edit bug report at http://bugs.php.net/?id=39321&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39321&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39321&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39321&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39321&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39321&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39321&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39321&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39321&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39321&r=support Expected behavior:http://bugs.php.net/fix.php?id=39321&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39321&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39321&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39321&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39321&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39321&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39321&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39321&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39321&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39321&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39321&r=mysqlcfg
#39323 [NEW]: ifx_fetch_row returns shortened values
From: tobin dot lloyd at cognitomobile dot co dot uk Operating system: Unix PHP version: 4.4.4 PHP Bug Type: Informix related Bug description: ifx_fetch_row returns shortened values Description: I'm running an ifx_query/ifx_fetch row on a table containing an lvarchar(1000) field. When the field contains more than 255 characters the element of the array returned only contains the first 255 characters. I've verified the contents of the field and it does indeed contain 268 characters. -- Edit bug report at http://bugs.php.net/?id=39323&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39323&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39323&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39323&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39323&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39323&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39323&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39323&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39323&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39323&r=support Expected behavior:http://bugs.php.net/fix.php?id=39323&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39323&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39323&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39323&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39323&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39323&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39323&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39323&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39323&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39323&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39323&r=mysqlcfg
#39312 [Fbk->Csd]: Cannot install OCI_PDO
ID: 39312 User updated by: andrew dot nagy at villanova dot edu Reported By: andrew dot nagy at villanova dot edu -Status: Feedback +Status: Closed Bug Type: PDO related Operating System: Linux PHP Version: 5.1.6 New Comment: Sorry. It appears oracle is installed in 2 locations /usr/lib and /usr/include and the headers are in /usr/include Previous Comments: [2006-10-30 23:06:39] [EMAIL PROTECTED] So the headers are in /usr/lib../? I mean the .h files, oci.h for example. [2006-10-30 22:41:47] andrew dot nagy at villanova dot edu I installed the instant client to: /usr/lib/oracle/10.1.0.3 Is this what you are asking for? [2006-10-30 19:44:29] [EMAIL PROTECTED] So where is your include dir? [2006-10-30 19:36:04] andrew dot nagy at villanova dot edu Description: I installed the instantclient library and when I try to run configure I get the following error: checking for oci.h... configure: error: I'm too dumb to figure out where the include dir is in your instant client install This is a bad error message, although quite humorous. Reproduce code: --- Here is my configure settings: --with-oci8=instantclient,/usr/lib/oracle/10.1.0.3/client/lib --with-pdo-oci=instantclient,/usr/lib/oracle,10.1.0.3 -- Edit this bug report at http://bugs.php.net/?id=39312&edit=1
#39314 [Bgs]: imagecolorallocatealpha causing problems
ID: 39314 User updated by: slyc6 at aol dot com Reported By: slyc6 at aol dot com Status: Bogus Bug Type: *General Issues Operating System: Windows XP PHP Version: 5.1.6 Assigned To: pajoye New Comment: Well I only use 63 for the example. But what Im really trying to do is set a color ever pixel but the color differ in alpha value depending on the color of the pixel in the image mask that I am using. imagecolorallocatealpha ($newim,0,0,0,63); So when I really call this function it would be more along the lines of imagecolorallocatealpha ($newim,$backr,$backg,$backb,$alpha); So is there a way I can delete the previous color after I use it since I only need it for that one pixel? So I dont reach that 255 cap? Previous Comments: [2006-10-31 13:05:59] [EMAIL PROTECTED] You allocate a new color on each iteration. You reached the 255 limit on the 255th iteration. It makes also little sense to do that in the loop if you use always the same color. As a side note, you may consider to use imagefill or imagefilledrectangle. [2006-10-31 02:50:02] slyc6 at aol dot com Description: Ok the problem is that when you use imagesetpixel in an nested loop it fails to draw the specified pixel. Im trying to make an image mask and need imagecolorallocatealpha to change according to the mask image im using. But in this case i just simply set it to a grey color and an alpha value of 63. But anyway when I run this loop the image draws the pixels up to a certain point. Usually it stops on the second line 1/3 of the way. The way I fixed this porblem was taking imagecolorallocatealpha out of the nested loop and put it in the first loop. In my code I have a for loop using $x nested inside of for loop using $y. So when imagecolorallocatealpha is in the loop of $y I get my problem. But if I move it to $x I dont any problems (but I can't achieve my goal) Reproduce code: --- Expected result: what it should doing is something along the lines of this -- xx xx xx etc... Actual result: -- but I get something like this -- xx xx -- Edit this bug report at http://bugs.php.net/?id=39314&edit=1
#39134 [Opn->Fbk]: PHP + FreeTDS 0.64 crashes when TEXT field with empty string encountered
ID: 39134
Updated by: [EMAIL PROTECTED]
Reported By: jr-phpbugs at cedric dot unob dot cz
-Status: Open
+Status: Feedback
Bug Type: MSSQL related
Operating System: linux (irrelevant)
PHP Version: 4.4.4
New Comment:
try using --with-mssql instead of --with-sybase-ct. When you are
compiling with the sybase option you are not using the MSSQL extension
but the sybase extension that happens to have aliasses so you can use
mssql_* when you call the functions.
- Frank
Previous Comments:
[2006-10-31 05:22:07] cameron dot mcshane at csiro dot au
I have also experienced this problem. Details:
SuSE SLES 9
php 4.4.2 ('./configure' '--with-apxs2=/usr/local/apache2/bin/apxs'
'--prefix=/usr/local/php' '--with-sybase-ct=/usr/local/freetds')
FreeTDS 0.64
MS MSL 2000
Have tested code as provided in original bug report.
CLI version:
- crash with "segmentation fault" message
libphp4.so version:
- affected thread produces a line "[notice] child pid X exit
signal
Segmentation fault (11)" in Apache's error log.
backtrace included below:
Program received signal SIGSEGV, Segmentation fault.
0x4014c40c in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0x4014c40c in memcpy () from /lib/tls/libc.so.6
#1 0x0811d82b in _estrndup (s=0x820522c "", length=136454143) at
/usr/src/php-4.4.2/Zend/zend_alloc.c:387
#2 0x080e6c18 in php_sybase_fetch_result_row (result=0x81e825f,
numrows=-1) at /usr/src/php-4.4.2/ext/sybase_ct/php_sybase_ct.c:1185
#3 0x080e8586 in php_sybase_fetch_result_set (sybase_ptr=0x81caf7c,
buffered=0, store=)
at /usr/src/php-4.4.2/ext/sybase_ct/php_sybase_ct.c:1333
#4 0x080e8bbb in php_sybase_query (ht=,
return_value=0x81cdb1c, this_ptr=,
return_value_used=1, buffered=0)
at /usr/src/php-4.4.2/ext/sybase_ct/php_sybase_ct.c:1497
#5 0x0813ad3c in execute (op_array=0x81caf14) at
/usr/src/php-4.4.2/Zend/zend_execute.c:1675
#6 0x08129623 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php-4.4.2/Zend/zend.c:934
#7 0x0810181e in php_execute_script (primary_file=0xb3c0) at
/usr/src/php-4.4.2/main/main.c:1753
#8 0x0813bda2 in main (argc=2, argv=0xb484) at
/usr/src/php-4.4.2/sapi/cli/php_cli.c:830
(gdb) frame 5
#5 0x0813ad3c in execute (op_array=0x81caf14) at
/usr/src/php-4.4.2/Zend/zend_execute.c:1675
1675
((zend_internal_function *)
EX(function_state).function)->handler(EX(opline)->extended_value,
EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr,
return_value_used TSRMLS_CC);
(gdb) print (char
*)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0x8150075 "mssql_query"
(gdb) print (char *)executor_globals.active_op_array->function_name
$2 = 0x0
(gdb) print (char *)executor_globals.active_op_array->filename
$3 = 0x81cefdc ""
(gdb)
[2006-10-12 10:32:07] jr-phpbugs at cedric dot unob dot cz
(gdb) bt
#0 0x003e830f in memcpy () from /lib/libc.so.6
#1 0x0816d0ca in _estrndup (s=0x838a4ac "", length=137940992,
__zend_filename=0x8235d40
"/usr/local/src/php/php-4.4.4/ext/sybase_ct/php_sybase_ct.c",
__zend_lineno=1185, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php/php-4.4.4/Zend/zend_alloc.c:409
#2 0x0813627c in php_sybase_fetch_result_row (result=0x838b450,
numrows=-1)
at /usr/local/src/php/php-4.4.4/ext/sybase_ct/php_sybase_ct.c:1185
#3 0x08136857 in php_sybase_fetch_result_set (sybase_ptr=0x8352334,
buffered=0, store=-1)
at /usr/local/src/php/php-4.4.4/ext/sybase_ct/php_sybase_ct.c:1333
#4 0x08136ed3 in php_sybase_query (ht=-1, return_value=0x8389c14,
this_ptr=0x0, return_value_used=1, buffered=0)
at /usr/local/src/php/php-4.4.4/ext/sybase_ct/php_sybase_ct.c:1497
#5 0x081371e9 in zif_sybase_query (ht=2, return_value=0x8389c14,
this_ptr=0x0, return_value_used=1)
at /usr/local/src/php/php-4.4.4/ext/sybase_ct/php_sybase_ct.c:1626
#6 0x0818819c in execute (op_array=0x83522ac)
at /usr/local/src/php/php-4.4.4/Zend/zend_execute.c:1675
#7 0x0817a183 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/src/php/php-4.4.4/Zend/zend.c:934
#8 0x0815336b in php_execute_script (primary_file=0xbfffdbe0)
at /usr/local/src/php/php-4.4.4/main/main.c:1752
#9 0x0818c938 in main (argc=4, argv=0xbfffdc74)
at /usr/local/src/php/php-4.4.4/sapi/cli/php_cli.c:832
#10 0x00381bb4 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 6
#6 0x0818819c in execute (op_array=0x83522ac)
at /usr/local/src/php/php-4.4.4/Zend/zend_execute.c:1675
1675
((zend_internal_function *)
EX(function_state).function)->handler(EX(opline)->extended_value,
EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr,
return_value_used TSRMLS_CC);
(gdb) print
#39312 [Csd->Opn]: Cannot install OCI_PDO
ID: 39312 User updated by: andrew dot nagy at villanova dot edu Reported By: andrew dot nagy at villanova dot edu -Status: Closed +Status: Open Bug Type: PDO related Operating System: Linux PHP Version: 5.1.6 New Comment: Well, I changed my configure to: --with-oci8=instantclient,/usr/lib/oracle/10.1.0.3/client/lib --with-pdo-oci=instantclient,/usr/include/oracle,10.1.0.3 And am still getting the same error. The first oci8 option passes in the configuration, but the PDO_OCI does not. According to the ./configure --help, I am doing everything correctly ... I think. Previous Comments: [2006-10-31 14:41:47] andrew dot nagy at villanova dot edu Sorry. It appears oracle is installed in 2 locations /usr/lib and /usr/include and the headers are in /usr/include [2006-10-30 23:06:39] [EMAIL PROTECTED] So the headers are in /usr/lib../? I mean the .h files, oci.h for example. [2006-10-30 22:41:47] andrew dot nagy at villanova dot edu I installed the instant client to: /usr/lib/oracle/10.1.0.3 Is this what you are asking for? [2006-10-30 19:44:29] [EMAIL PROTECTED] So where is your include dir? [2006-10-30 19:36:04] andrew dot nagy at villanova dot edu Description: I installed the instantclient library and when I try to run configure I get the following error: checking for oci.h... configure: error: I'm too dumb to figure out where the include dir is in your instant client install This is a bad error message, although quite humorous. Reproduce code: --- Here is my configure settings: --with-oci8=instantclient,/usr/lib/oracle/10.1.0.3/client/lib --with-pdo-oci=instantclient,/usr/lib/oracle,10.1.0.3 -- Edit this bug report at http://bugs.php.net/?id=39312&edit=1
#39314 [Asn->Bgs]: imagecolorallocatealpha causing problems
ID: 39314 Updated by: [EMAIL PROTECTED] Reported By: slyc6 at aol dot com -Status: Assigned +Status: Bogus Bug Type: *General Issues Operating System: Windows XP PHP Version: 5.1.6 Assigned To: pajoye New Comment: You allocate a new color on each iteration. You reached the 255 limit on the 255th iteration. It makes also little sense to do that in the loop if you use always the same color. As a side note, you may consider to use imagefill or imagefilledrectangle. Previous Comments: [2006-10-31 02:50:02] slyc6 at aol dot com Description: Ok the problem is that when you use imagesetpixel in an nested loop it fails to draw the specified pixel. Im trying to make an image mask and need imagecolorallocatealpha to change according to the mask image im using. But in this case i just simply set it to a grey color and an alpha value of 63. But anyway when I run this loop the image draws the pixels up to a certain point. Usually it stops on the second line 1/3 of the way. The way I fixed this porblem was taking imagecolorallocatealpha out of the nested loop and put it in the first loop. In my code I have a for loop using $x nested inside of for loop using $y. So when imagecolorallocatealpha is in the loop of $y I get my problem. But if I move it to $x I dont any problems (but I can't achieve my goal) Reproduce code: --- Expected result: what it should doing is something along the lines of this -- xx xx xx etc... Actual result: -- but I get something like this -- xx xx -- Edit this bug report at http://bugs.php.net/?id=39314&edit=1
#39277 [Opn]: php-cgi does not parse command line arguments when running under Apache
ID: 39277 User updated by: nisoi at mail dot ru Reported By: nisoi at mail dot ru Status: Open Bug Type: CGI related Operating System: FreeBsd 6.1 PHP Version: 4.4.4 New Comment: I just tested this issue under Gentoo Linux. Same things happen: PHP does not pay any attention to command line arguments passed to php-cgi running under Apache. Previous Comments: [2006-10-27 11:02:42] nisoi at mail dot ru Description: PHP-4.4.4-cgi does not parse command line arguments when run under Apache (but parses it when run from shell). Php5 works fine in same situation. I run php-4.4.4 as cgi under Apache/1.3.34. All requests for *.php are redirected to php-cgi with Action php-script /cgi-bin/php4 /cgi-bin/php4 looks like this: === /cgi-bin/php4 ==> #!/usr/local/php4/bin/php-cgi -c/home/scrtest/www/site1/public_html/php-c.ini <== /cgi-bin/php4 === But phpinfo() says that it is using default config from /usr/local/php4/etc/php-cgi.ini. No other arguments are working: neither "-n", neither "-h", nor anything. Even this trick: === /cgi-bin/php4 ==> #!/bin/sh /usr/local/php4/bin/php-cgi -c/home/scrtest/www/site1/public_html/php-c.ini <== /cgi-bin/php4 === does not make php-cgi to take it's arguments. When I run same command from shell, php-cgi parses it's arguments correctly. Reproduce code: --- Expected result: Want to see /home/scrtest/www/site1/public_html/php-c.ini as configuration file. Actual result: -- See /usr/local/php4/etc/php-cgi.ini as configuration file. -- Edit this bug report at http://bugs.php.net/?id=39277&edit=1
#39320 [NEW]: ZEND_HASH_APPLY_STOP causes deletion
From: wharmby at uk dot ibm dot com Operating system: Windows XP PHP version: 5CVS-2006-10-31 (snap) PHP Bug Type: Scripting Engine problem Bug description: ZEND_HASH_APPLY_STOP causes deletion Description: Specifying hash apply call-back function return code of ZEND_HASH_APPLY_STOP results in deletion of current element from subject hash table rather than halting of iteration as expected, i.e ZEND_HASH_APPLY_STOP treated same as ZEND_HASH_APPLY_REMOVE. I spotted this bug reviewing code the engine code whilst reading Sara Golemon's book "Extending and Embedding PHP". The meanings of the various callback return codes are listed on page 99 and the text suggests they can all be used by all the hash_apply_* functions. No comments in code or online documentation on php.net suggest otherwise. The test case below uses zend_hash_apply() but the defect, if indeed it is a defect, exists in all 3 zend_hash_apply functions; namely: ZEND_API void zend_hash_apply(HashTable *ht, apply_func_t apply_func TSRMLS_DC); ZEND_API void zend_hash_apply_with_argument( HashTable *ht, apply_func_arg_t apply_func, void * TSRMLS_DC); ZEND_API void zend_hash_apply_with_arguments( HashTable *ht, apply_func_args_t apply_func, int numargs, ...); All 3 functions delete the current entry on a non-zero return from the "apply_func". I have reviewed the open defects and can see no defect which covers the reported behaviour. I have tried the latest snap-shot build for Windows which at the time was "Oct 31, 2006 09:30 GMT" phpinfo() shows PHP version as "Version => 5.2.1-dev". Problem also persists in latest checked in version of file in CVS. Andy Wharmby IBM United Kingdom Limited Reproduce code: --- Reproduce code is posted here: http://pastebin.ca/230657 Possible fix to zend_hash.c posted here: http://pastebin.ca/230668 Expected result: Test 1: zend_hash_apply with stop colour red Stop_on_red called for element: orange Stop_on_red called for element: green Stop_on_red called for element: blue Stop_on_red called for element: red Array contents after test: orange green blue red yellow purple indigo TEST 1 PASSED Test 2: zend_hash_apply_with_argument with stop colour prurple Stop_on_colour called for element:orange Stop_on_colour called for element:green Stop_on_colour called for element:blue Stop_on_colour called for element:red Stop_on_colour called for element:yellow Stop_on_colour called for element:purple Array contents after test: orange green blue red yellow purple indigo TEST 2 PASSED Test 3: zend_hash_apply_with_arguments with stop colours yellow and black Stop_on_either_colour called for element: orange Stop_on_either_colour called for element: green Stop_on_either_colour called for element: blue Stop_on_either_colour called for element: red Stop_on_either_colour called for element: yellow Array contents after test: orange green blue red yellow purple indigo TEST 3 PASSED Actual result: -- Test 1: zend_hash_apply with stop colour red Stop_on_red called for element: orange Stop_on_red called for element: green Stop_on_red called for element: blue Stop_on_red called for element: red Stop_on_red called for element: yellow Stop_on_red called for element: purple Stop_on_red called for element: indigo Array contents after test: orange green blue yellow purple indigo TEST 1 FAILED Test 2: zend_hash_apply_with_argument with stop colour prurple Stop_on_colour called for element:orange Stop_on_colour called for element:green Stop_on_colour called for element:blue Stop_on_colour called for element:red Stop_on_colour called for element:yellow Stop_on_colour called for element:purple Stop_on_colour called for element:indigo Array contents after test: orange green blue red yellow indigo TEST 2 FAILED Test 3: zend_hash_apply_with_arguments with stop colours yellow and black Stop_on_either_colour called for element: orange Stop_on_either_colour called for element: green Stop_on_either_colour called for element: blue Stop_on_either_colour called for element: red Stop_on_either_colour called for element: yellow Stop_on_either_colour called for element: purple Stop_on_either_colour called for element: indigo Array contents after test: orange green blue red purple indigo TEST 3 FAILED The actual results show that ZEND_HASH_APPLY_STOP is being interpreted as ZEND_HASH_APPLY_REMOVE in all 3 cases; in all cases the stop colour is being removed and the call-back routine is being called for ALL elements of subject hash table. -- Edit bug report at http://bugs.php.net/?id=39320&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39320&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39320
#39314 [Opn->Asn]: imagecolorallocatealpha causing problems
ID: 39314 Updated by: [EMAIL PROTECTED] Reported By: slyc6 at aol dot com -Status: Open +Status: Assigned Bug Type: *General Issues Operating System: Windows XP PHP Version: 5.1.6 -Assigned To: +Assigned To: pajoye Previous Comments: [2006-10-31 02:50:02] slyc6 at aol dot com Description: Ok the problem is that when you use imagesetpixel in an nested loop it fails to draw the specified pixel. Im trying to make an image mask and need imagecolorallocatealpha to change according to the mask image im using. But in this case i just simply set it to a grey color and an alpha value of 63. But anyway when I run this loop the image draws the pixels up to a certain point. Usually it stops on the second line 1/3 of the way. The way I fixed this porblem was taking imagecolorallocatealpha out of the nested loop and put it in the first loop. In my code I have a for loop using $x nested inside of for loop using $y. So when imagecolorallocatealpha is in the loop of $y I get my problem. But if I move it to $x I dont any problems (but I can't achieve my goal) Reproduce code: --- Expected result: what it should doing is something along the lines of this -- xx xx xx etc... Actual result: -- but I get something like this -- xx xx -- Edit this bug report at http://bugs.php.net/?id=39314&edit=1
#39316 [Opn->Fbk]: extension_dir has no effect on Windows
ID: 39316 Updated by: [EMAIL PROTECTED] Reported By: aren at cambre dot biz -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: Windows Server 2003 PHP Version: 5.1.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-10-31 04:49:18] aren at cambre dot biz Description: extension_dir (in php.ini) has no effect in Windows. I installed a relatively clean installation of PHP 5.1.6 on Windows 2003. I configured the extension_dir line in php.ini using all these forms: extension_dir = c:\PHP\ext extension_dir = c:\php\ext extension_dir = c:/PHP/ext extension_dir = "c:\php\ext" Regardless of the form used, php does not even attempt to search the c:\php\ext directory to find extensions. Reproduce code: --- 1. Install php 5.1.6 on a clean Windows system. Only configure what is necessary to get it running. Be sure to set extension_dir to your actual ext directory. (Preferably, c:\php\ext.) Do a hello world php to test functionality. 2. Uncomment this line in php.ini: extension=php_mysql.dll 3. Download the latest phpMyAdmin. Extract files and copy to a directory in your web server. 4. Get File Monitor from sysinternals (www.sysinternals.com). 5. Load File Monitor, and set its filter to php_mysql.dll. (This is so that it just reports on attempts to find php_mysql.dll and not hundreds of other filesystem hits.) 6. Start File Monitor so that it's catching filesystem hits. 7. Browse myPhpAdmin's index.php in a browser. You'll get an error saying that the mysql drivers cannot be used. 8. Go back to File Monitor. Notice how none of the directories searched were the directory specified in extension_dir. Installing mySql is optional. Its presence has no effect on the above problem. (Of course, if the system actually found php_mysql.dll, then it would be a problem if mySql was not installed!) Expected result: phpMyAdmin should find the mySql extension, and File Monitor should confirm that php actually searches the c:\php\ext directory for the extensions. Actual result: -- Php searches all directories in the system path! extension_dir has no effect under Windows. You have to add c:\php AND c:\php\ext to the system path. I think this is likely an application bug because the documentation is quite clear on how extension_dir should be configured. -- Edit this bug report at http://bugs.php.net/?id=39316&edit=1
#39317 [Opn->Bgs]: Fatal error: Database class not found
ID: 39317 Updated by: [EMAIL PROTECTED] Reported By: ldwebtech at yahoo dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: CentOS 4.4 i686 PHP Version: 4.4.4 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. Previous Comments: [2006-10-31 05:50:09] ldwebtech at yahoo dot com Description: when i am trying to install a php script its showing the following error: Fatal error: Database class not found how to rectify this problem . Actual result: -- Fatal error: Database class not found -- Edit this bug report at http://bugs.php.net/?id=39317&edit=1
#39319 [NEW]: Problem to connect to SQLSERVER 2005
From: luiscervantesjane at hotmail dot com
Operating system: WINDOWS 2003
PHP version: 5.1.6
PHP Bug Type: MSSQL related
Bug description: Problem to connect to SQLSERVER 2005
Description:
The web server are running in windows 2003, Version Apache/2.0.55 (Win32)
PHP/5.1.6. And when I try to connect to MSSQL 2005 over windows2003, I
can`t.
If the code move to another server windows 2000, with the same Apache
Version, PHP 5.1.6. The connection is OK.
I belive that there are a problem the connection with SO windows2003 where
are running php.
Thanks
Reproduce code:
---
$SERVER="SATURNO\SATURNO";
$USER="USER";
$PASSWD="PASSWORD";
$link = mssql_connect($SERVER, $USER, $PASSWD) or die ("Could not connect
MSSQL");
mssql_select_db($DATABASE,$link) or die ("Could not select database " .
$DATABASE. " in MSSQL");
$query = "Select * form TABLA";
$result = mssql_query($link,$query);
while ($row = mssql_fetch_array($result)){
print $row['ALU_NOMBRE'] . "";
}
Expected result:
Warning: mssql_connect() [function.mssql-connect]: Unable to connect to
server: SATURNO\SATURNO in C:\WEB\PRUEBAS\SQL2005\index2.php on line 5
Could not connect MSSQL
--
Edit bug report at http://bugs.php.net/?id=39319&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39319&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39319&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39319&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39319&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39319&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39319&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39319&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39319&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39319&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39319&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39319&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39319&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39319&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39319&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39319&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39319&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39319&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39319&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39319&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39319&r=mysqlcfg
#38744 [Com]: PHP5TS.DLL causes w3svc crash and application pool termination
ID: 38744 Comment by: ted at connectingsweden dot com Reported By: jneill at gamedaytv dot com Status: No Feedback Bug Type: Reproducible crash Operating System: Windows 2003 SP 1 PHP Version: 5.1.6 New Comment: Im getting this exact error also... i have disabled the application pool recycle functions in the IIS server it stil happens this emm problem but it takes a couple of days before it does simple idiot fix is to just goto the server and do a load on a php page for the application pool and then it works again for a couple of days. If i reactivate the recycle functions ill end up with counltess of php page downtime sessions where i have to go and reload a php page localy on the server to fix it.. i run 5.1.6 as php rel ver my question is... Is there a older versions of the php releases that do not cause this effect? untill there is a permanent fix for it. Previous Comments: [2006-09-18 17:09:21] opa56 at myownnet dot ch Same error here: A process serving application pool 'mysite1' terminated unexpectedly. The process id was '2828'. The process exit code was '0xc005'. A process serving application pool 'mysite2' terminated unexpectedly. The process id was '3132'. The process exit code was '0xc005'. etc. The error occurs - each time, the w3svc is recycled because of idle-timeout (default 20 min.)or uptime 1740 min. - sinze version 5.1.4 of php If idle-timeout occurs, no script is running at this moment! Only the isapi is loaded. Same error, also if no php.ini exist, means no extensions are loaded [2006-09-15 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-09-14 14:27:41] helder at hightechvision dot com I'm getting precisely the same debug output from IIS Diagnostics Debug Diagnostics Tool running on a Windows Server 2003 SP1 with the build php5.2-win32-200609131430.zip If you want I can provide you crash dumps. [2006-09-07 20:50:59] [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-09-07 20:42:44] jneill at gamedaytv dot com Description: Description: We have been successfully using PHP 5.1.2 for several months in our server environment. Only upgrading PHP to 5.1.6, with no other software upgrades, has resulted in frequent w3svc crashes and subsequent application pool terminations. The system log includes such errors as: --- A process serving application pool 'Site1' terminated unexpectedly. The process id was '5796'. The process exit code was '0xc005'. A process serving application pool 'Site2' terminated unexpectedly. The process id was '5212'. The process exit code was '0x'. A process serving application pool 'DefaultAppPool' terminated unexpectedly. The process id was '5824'. The process exit code was '0xc005'. --- We have run the IIS Diagnostics Debug Diagnostics Tool on these crashes, which has resulted in the following report for each crash: --- Type of Analysis Performed Crash Analysis Machine Name S76217 Operating System Windows Server 2003 Service Pack 1 Number Of Processors 2 Process ID 4736 Process Image c:\WINNT\system32\inetsrv\w3wp.exe System Up-Time 0 day(s) 04:18:05 Process Up-Time 0 day(s) 00:31:08 Thread 16 - System ID 2612 Entry point msvcrt!_endthread+3b Create time 5/16/2006 5:31:43 PM Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.0 Function Arg 1 Arg 2 Arg 3 Source +265c80 02a28890 msvcrt!_endthread+ab 029e7580 kernel32!BaseThreadStart+34 77bcb35a 029e7580 In w3wp__PID__4736__Date__05_16_2006__Time_05_31_45PM__95__Second_Chance_Ex ception_C005.dmp an access violation exception (0xC005) occured on thread 16 when another module attempted to call the following unloaded module: php5ts.dll. --- -- Edit this bug report at http://bugs.php.net/?id=38744&edit=1
