#44820 [Com]: overload() causes Cause
ID: 44820 Comment by: crrodriguez at suse dot de Reported By: neel dot get at gmail dot com Status: Open Bug Type: Scripting Engine problem Operating System: CentOs PHP Version: 4.3.10 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Thanks for your interest in PHP. Previous Comments: [2008-04-24 16:33:32] neel dot get at gmail dot com version Corrected [2008-04-24 16:22:37] neel dot get at gmail dot com Description: running on PHP version 4.3.10 Server for Sourceforge.net Projects This code Returns not output on Browser Lynx says Alert!: Unexpected network read error;connection aborted. Alert!: Unable to access document. If running the same script through PHP CLI Running version (4.3.9) returns expected result on terminal X-Powered-By: PHP/4.3.9 Content-Type: text/plain called create () called enargise () Reproduce code: --- create()."\n"; echo $creation->enargise()."\n"; ?> Expected result: called create () called enargise () Actual result: -- NO output on Browser Lynx reports Alert!: Unexpected network read error;connection aborted. Alert!: Unable to access document. -- Edit this bug report at http://bugs.php.net/?id=44820&edit=1
#44851 [NEW]: Interbase events crash PHP cli with segmentation fault
From: miha at link-go dot si Operating system: linux PHP version: 5.2.5 PHP Bug Type: InterBase related Bug description: Interbase events crash PHP cli with segmentation fault Description: I have a socket server (pear Net_Server) running configuration on my test machine. The server runs OK. Then if I turn on events with ibase_set_event_handler, the server will fail within a few minutes with a segmentation fault. Until that happens everything works like a charm. My cli-based socket server application fails even with an empty event handler (an emty function returning true)! -- Edit bug report at http://bugs.php.net/?id=44851&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44851&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44851&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44851&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44851&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44851&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44851&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44851&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44851&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44851&r=support Expected behavior:http://bugs.php.net/fix.php?id=44851&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44851&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44851&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44851&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44851&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44851&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44851&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44851&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44851&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44851&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44851&r=mysqlcfg
#44850 [Opn]: dbase_open exits with error
ID: 44850
User updated by: kindaian at gmail dot com
Reported By: kindaian at gmail dot com
Status: Open
Bug Type: dBase related
Operating System: Windows XP Pro
PHP Version: 5.2.5
New Comment:
This is the begin (the 256 first characters) of the file (changed the
record number to 1 and the terminator character to 0D, but it didn't
sorted it out):
03 6C 04 02 01 00 00 00 81 00 5B 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 43 4F 44 49 47 4F 00 00 00 00 00 43 00 00 00 00
0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 44 45 53 43 52 49 43 41
4F 00 00 43 00 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
44 45 53 43 5F 41 55 58 00 00 00 43 00 00 00 00 28 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 0D 20 36 30 30 2F 30 2C 39 30 20 20 41 55 54 4F
20 41 44 45 53 49 56 41 2C 20 32 20 54 45 4C 41 53 2C 20 30 2C 39 30 20
4D 4D 20 20 20 20 20 20 20 20 20 20 53 54 49 43 4B 59 20 42 41 43 4B 2C
20 30 2C 39 30 20 6D 6D 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 36 30 30 2F 30 2C 39 35 20 20 41 55 54 4F 20 41 44 45 53
49 56 41 2C 20 32 20 54 45 4C 41 53 2C 20 30
Previous Comments:
[2008-04-28 00:26:01] kindaian at gmail dot com
Description:
I've a dbf with a problem in the array that holds the field
definitions, so when i try to open it it crashes.
I've tryed to open it in DBU and when i try to access the fields, it
exits with "BASE/1132 bound error: array access".
In PHP, it just exits with an error that it can't open the file and
stops execution ("Error reading DBF's number of fields").
The problem is that I've the code enclosed by a try/catch and the
program instead of gracefully execute the catch... just breaks.
Maybe related with the way error handling is handled inside the dbase
functions as pointed out also in the bug #37589 "dbase_open doesnt act
like it should" for another issue.
Reproduce code:
---
try {
$dbf = @dbase_open($file_name, 0);
} catch (Exception $e) {
echo ("Error opening $file_name");
}
Expected result:
I was expecting that the program would print the error message and
carry on.
Actual result:
--
The execution just stops where the error happens, and no more code is
processed.
The error "Error reading DBF's number of fields" is shown in the
browser.
--
Edit this bug report at http://bugs.php.net/?id=44850&edit=1
#44850 [NEW]: dbase_open exits with error
From: kindaian at gmail dot com
Operating system: Windows XP Pro
PHP version: 5.2.5
PHP Bug Type: dBase related
Bug description: dbase_open exits with error
Description:
I've a dbf with a problem in the array that holds the field definitions,
so when i try to open it it crashes.
I've tryed to open it in DBU and when i try to access the fields, it exits
with "BASE/1132 bound error: array access".
In PHP, it just exits with an error that it can't open the file and stops
execution ("Error reading DBF's number of fields").
The problem is that I've the code enclosed by a try/catch and the program
instead of gracefully execute the catch... just breaks.
Maybe related with the way error handling is handled inside the dbase
functions as pointed out also in the bug #37589 "dbase_open doesnt act like
it should" for another issue.
Reproduce code:
---
try {
$dbf = @dbase_open($file_name, 0);
} catch (Exception $e) {
echo ("Error opening $file_name");
}
Expected result:
I was expecting that the program would print the error message and carry
on.
Actual result:
--
The execution just stops where the error happens, and no more code is
processed.
The error "Error reading DBF's number of fields" is shown in the browser.
--
Edit bug report at http://bugs.php.net/?id=44850&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44850&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44850&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44850&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44850&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44850&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44850&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44850&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44850&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44850&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44850&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44850&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44850&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44850&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44850&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44850&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44850&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44850&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44850&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44850&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44850&r=mysqlcfg
#44849 [NEW]: imagecolorclosesthwb() is not avaible on Windows
From: [EMAIL PROTECTED]
Operating system: Windows Vista
PHP version: 5.2.5
PHP Bug Type: GD related
Bug description: imagecolorclosesthwb() is not avaible on Windows
Description:
The imagecolorclosesthwb() function is not avaible on Windows, I spoke to
Pierre on IRC and he said it was a missing /D flag in config.w32
Reproduce code:
---
var_dump(function_exists('imagecolorclosesthwb'));
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit bug report at http://bugs.php.net/?id=44849&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44849&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44849&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44849&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44849&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44849&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44849&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44849&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44849&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44849&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44849&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44849&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44849&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44849&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44849&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44849&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44849&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44849&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44849&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44849&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44849&r=mysqlcfg
#37477 [Com]: htmlentities problem on another greek expression
ID: 37477
Comment by: bitagenda at gmail dot com
Reported By: d dot gourgues at neuf dot fr
Status: No Feedback
Bug Type: Strings related
Operating System: Debian
PHP Version: 5.1.4
New Comment:
Add to this problem that
ERROR
htmlentities expects at most 3 parameters, 4 given
This is in
PHP Version 5.2.0-8+etch10 (Debian) a php BUG of course
Previous Comments:
[2006-06-28 01:00:02] 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-06-20 14:47:06] [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-05-17 15:31:21] d dot gourgues at neuf dot fr
Description:
Hi, I've some expression in database in UTF8.
When i try to use the htmlentities functions
ex : htmlentities("zoo...", ENT_QUOTES, "UTF-8");
the script returns sometimes nothing.
PS : I've tested on a PHP 5.1.2-1.dotdeb.2 (and i can't upgrade at
work)... i will try at home with a PHP 5.1.4 version
Reproduce code:
---
// works always
$str = " ";
echo htmlentities(html_entity_decode
("ζωολογικός".$str."κήπος/πάρκο",
ENT_QUOTES, "UTF-8"), ENT_QUOTES, "UTF-8");
// works sometimes
$str = " ";
echo htmlentities(html_entity_decode
("ζωολογικός".$str."κήπος/πάρκο",
ENT_QUOTES, "UTF-8"), ENT_QUOTES, "UTF-8");
--
Edit this bug report at http://bugs.php.net/?id=37477&edit=1
#44848 [NEW]: autoload fails with complex loading scheme
From: nicolas dot grekas+php at gmail dot com
Operating system: Linux & Windows
PHP version: 5.2.5
PHP Bug Type: Scripting Engine problem
Bug description: autoload fails with complex loading scheme
Description:
Hard to explain, see code... I think that PHP should be able to handle
this kind of loading scheme.
Here is what I thought this code would do :
1. __autoload('A') is called
2. inside this call for A:
2.1 class B is defined, which extends C
2.2 as C is not defined, __autoload('C') is called
2.3 inside this call for C:
2.3.1 class C is defined
2.3.2 (now we have everything needed for class B, haven't we ?)
2.3.3 class A extends B
2.4 we leave the __autoload('C') context
3. we leave the __autoload('A') context
The bug is at step 2.3.3 : "class A extends B" triggers an autoload('B'),
which should not occurs, as B should be already defined, thanks to 2.3.2...
Reproduce code:
---
http://bugs.php.net/?id=44848&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44848&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44848&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44848&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44848&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44848&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44848&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44848&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44848&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44848&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44848&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44848&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44848&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44848&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44848&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44848&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44848&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44848&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44848&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44848&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44848&r=mysqlcfg
#44847 [Bgs]: Imagefill(), x and y do not work
ID: 44847
User updated by: simslim at gmail dot com
Reported By: simslim at gmail dot com
Status: Bogus
Bug Type: GD related
Operating System: Win XP
PHP Version: 5.2.5
Assigned To: pajoye
New Comment:
I'm sorry, I didn't understand that the filling goes too all directions
untill it hits a border.
I hope the manual page about this function can be changed because I
think it's unclear for other people too.
Thanks for the quick reply!
Previous Comments:
[2008-04-27 17:02:44] [EMAIL PROTECTED]
imagefill _fills_ the image until an edge has been met, what you are
trying to do should be done using imagefilledrectangle.
[2008-04-27 16:55:21] simslim at gmail dot com
Description:
I use imagefill to fill a picture, but no matter what I enter as start
x and y, it always fills the whole image (with x and y higher then 0 and
not higher then image sizes)
Reproduce code:
---
header("Content-Type: image/png");
$img= imagecreatetruecolor(100,100);
$red= imagecolorallocate($img,255,0,0);
$green = imagecolorallocate($img,0,255,0);
imagefill($img,0,0,$red);
imagefill($img,50,0,$green);
imagepng($img);
Expected result:
A picture, 100 x 100, with the left half red and the right half green
Actual result:
--
A picture, 100 x 100, completely green
--
Edit this bug report at http://bugs.php.net/?id=44847&edit=1
#44847 [Opn->Bgs]: Imagefill(), x and y do not work
ID: 44847
Updated by: [EMAIL PROTECTED]
Reported By: simslim at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: Win XP
PHP Version: 5.2.5
-Assigned To:
+Assigned To: pajoye
New Comment:
imagefill _fills_ the image until an edge has been met, what you are
trying to do should be done using imagefilledrectangle.
Previous Comments:
[2008-04-27 16:55:21] simslim at gmail dot com
Description:
I use imagefill to fill a picture, but no matter what I enter as start
x and y, it always fills the whole image (with x and y higher then 0 and
not higher then image sizes)
Reproduce code:
---
header("Content-Type: image/png");
$img= imagecreatetruecolor(100,100);
$red= imagecolorallocate($img,255,0,0);
$green = imagecolorallocate($img,0,255,0);
imagefill($img,0,0,$red);
imagefill($img,50,0,$green);
imagepng($img);
Expected result:
A picture, 100 x 100, with the left half red and the right half green
Actual result:
--
A picture, 100 x 100, completely green
--
Edit this bug report at http://bugs.php.net/?id=44847&edit=1
#44847 [NEW]: Imagefill(), x and y do not work
From: simslim at gmail dot com
Operating system: Win XP
PHP version: 5.2.5
PHP Bug Type: GD related
Bug description: Imagefill(), x and y do not work
Description:
I use imagefill to fill a picture, but no matter what I enter as start x
and y, it always fills the whole image (with x and y higher then 0 and not
higher then image sizes)
Reproduce code:
---
header("Content-Type: image/png");
$img= imagecreatetruecolor(100,100);
$red= imagecolorallocate($img,255,0,0);
$green = imagecolorallocate($img,0,255,0);
imagefill($img,0,0,$red);
imagefill($img,50,0,$green);
imagepng($img);
Expected result:
A picture, 100 x 100, with the left half red and the right half green
Actual result:
--
A picture, 100 x 100, completely green
--
Edit bug report at http://bugs.php.net/?id=44847&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44847&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44847&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44847&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44847&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44847&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44847&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44847&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44847&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44847&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44847&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44847&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44847&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44847&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44847&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44847&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44847&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44847&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44847&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44847&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44847&r=mysqlcfg
#44846 [NEW]: Missing MYSQLI_ENUM_FLAG
From: marc at phpmyadmin dot net
Operating system: Linux
PHP version: 5.2.6RC5
PHP Bug Type: MySQLi related
Bug description: Missing MYSQLI_ENUM_FLAG
Description:
In ext/mysqli/mysqli.c, please add
REGISTER_LONG_CONSTANT("MYSQLI_ENUM_FLAG", ENUM_FLAG, CONST_CS |
CONST_PERSISTENT);
and also add a reference to MYSQLI_ENUM_FLAG in the PHP manual:
http://www.php.net/manual/en/mysqli.constants.php
The value of this ENUM_FLAG can be seen in the MySQL source:
mysql-5.0.51a/include/mysql_com.h
Reproduce code:
---
php.n
--
Edit bug report at http://bugs.php.net/?id=44846&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44846&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44846&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44846&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44846&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44846&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44846&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44846&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44846&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44846&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44846&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44846&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44846&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44846&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44846&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44846&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44846&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44846&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44846&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44846&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44846&r=mysqlcfg
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: alienoiduk at yahoo dot com Reported By: graham at directhostinguk dot com Status: No Feedback Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.3 New Comment: You need to install MySQL5.051a for linux and MySQL 5.0.5b1 for windows. If installed the wrong way around there will be a delay in executing. Also copy the correct libmysql.dll to the C:\PHP\ folder I installed MySQL 5.0.51b at C:\Mysql\ therfor the libmysql.dll file you require will be in folder C:\MySQL\lib\opt the file is the Application Extension file size of about 2,000K. This worked on a brand new server running IIS6 windows 2003 server latest download from PHP 5.2.5 and MySQL 5.0.51b did as above no errors no hangup or delays. I am not run MySQLi. Previous Comments: [2008-04-22 14:01:29] newcomer at hotmail dot com We just upgraded to PHP Version 5.2.5. the "Error in my_thread_global_end(): 1 threads didn't exit" appeared no matter the application uses MySQL or not. Replaced the libmysql.dll from V.5.0.45, the error disappear. But the application is running very slow. Switched back to PHP version4. Everything back to normal. [2008-04-16 04:12:17] tristen_e at yahoo dot com This is still a problem: $ php --version PHP 5.2.5 (cli) (built: Nov 8 2007 23:18:51) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies [2008-04-09 15:16:21] jdolecek at NetBSD dot org Downgrading BOTH libmysql.dll AND php_mysql.dll to version bundled with PHP 5.2.1 fixed the issue for me, too. [2008-04-08 20:14:10] spambox at shad dot pp dot ru Same bug just happened to me in this example: C:\>echo "" |php "MSD" Error in my_thread_global_end(): 1 threads didn't exit MySQL extension was enabled in php.ini, but I didn't use any of it's functions in example. PHP is 5.2.5, no other mysql related dll's are available on system. I posted this just to confirm that bug exists on my system too. [2008-03-28 22:23:40] stein at visibone dot com Brilliant, Scottmac, I did have some crufty lurking libmysql.dll's. But I'm still getting the 5 second hang. Using the 5.2.5 php_mysql.dll and php_mysqli.dll's the hang happens with a dirt-simple hello-world. With 5.2.1 it happens if I mysql_connect(). Could it be having both mysql and mysqli enabled? I'm using both for unit testing. -- Bob Stein, VisiBone 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/41350 -- Edit this bug report at http://bugs.php.net/?id=41350&edit=1
#44801 [Fbk->Opn]: Invalid escaping for passthru() in CLI
ID: 44801
User updated by: twm at twmacinta dot com
Reported By: twm at twmacinta dot com
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Red Hat Enterprise Linux ES 3
PHP Version: 5.2.5
Assigned To: fb-req-jani
New Comment:
OK, that's the problem. But given that it is the problem, the test
script "bug22414.phpt", which is part of "make test", is bound to fail
any time safe mode is compiled in. It makes nested calls to the PHP
binary with the "-n" option, which apparently causes safe mode to be
turned on since it ignores the test script's custom "php.ini" in that
case. So in that respect, maybe this is a bug in "bug22414.phpt"?
I'd like to suggest that the manual be annotated to reflect the
changing behavior of the safe mode default. Currently,
http://www.php.net/manual/en/ini.php says that default value for
"safe_mode" in "php.ini" is 0. There is no mention that the default
changes depending on how the binary was compiled. In fact, I had
assumed that the default of 0 only applied when safe mode was compiled
into the binary since it would be meaningless otherwise.
This page on safe mode also indicates that the safe mode features
aren't applied to command line scripts.
http://www.php.net/manual/en/features.safe-mode.php says "Warning: These
PHP restrictions are not valid in executed binaries, of course." That's
doesn't seem entirely correct given that it was affecting passthru() in
the command line scripts referenced in this bug.
Previous Comments:
[2008-04-25 16:29:04] [EMAIL PROTECTED]
Using --enable-safe-mode makes the default be "on". (without this
configure option it defaults to "off").
And in the manual it is mentioned that: "Warning:
With safe mode enabled, the command string is escaped with
escapeshellcmd(). Thus, echo y | echo x becomes echo y \| echo x."
The question remains: Did you really turn off safe-mode in php.ini and
was it really turned off? (check with phpinfo())
[2008-04-24 19:48:19] twm at twmacinta dot com
Aha, that set off a spark. I think I found something useful...
The test script actually worked when I tried this:
./configure --disable-all --disable-cgi
Then, I tried no flags at all, and it still worked:
./configure
So I went through all of the flags I used originally and discovered
that the problem appears when all I add is the safe-mode flag:
./configure --enable-safe-mode
Here's the output:
Before: 'Tim'\''s Test'
After: sh: line 1: /usr/local/php/bin/echo: No such file or directory
Note that it was looking for "echo" at a different path. When I
created the directory that it was looking for and copied "echo" there,
then I got the same incorrect output as before:
Before: 'Tim'\''s Test'
After: Tim\s Test'
So the problem occurs when safe-mode is compiled into the executable
even though I am not using safe mode when running the script. I'm using
"php -n" which should avoid safe mode (right?) and my "php.ini" also
turns safe mode off. I checked the other versions of PHP which I
reported on earlier, and the versions which behaved incorrectly had safe
mode compiled in but turned off, and those that behaved correctly did
not have safe mode compiled in at all.
[2008-04-24 18:01:39] [EMAIL PROTECTED]
Can you try with this instead:
# rm -f config.cache
# ./configure --disable-all --disable-cgi
ie. Eliminate everything but the core. :)
[2008-04-24 17:52:47] twm at twmacinta dot com
I was actually using the "-n" flag from the start, so that moving part
was already eliminated.
Here are my "./configure" and "make install" commands:
CONF_OLD_PREFIX=/usr
CONF_PREFIX=/var/tmp2/php5_take2/targ
CONF_SYSCONFDIR=${CONF_PREFIX}/etc
CONF_BINDIR=${CONF_PREFIX}/bin
./configure \
--prefix=${CONF_PREFIX} \
--with-config-file-path=${CONF_SYSCONFDIR} \
--enable-force-cgi-redirect \
--enable-fastcgi \
--disable-debug \
--enable-pic \
--disable-rpath \
--enable-inline-optimization \
--with-bz2 \
--with-curl \
--with-dom=${CONF_PREFIX} \
--with-exec-dir=${CONF_BINDIR} \
--with-freetype-dir=${CONF_PREFIX} \
--with-png-dir=${CONF_PREFIX} \
--with-gd \
--enable-gd-native-ttf \
--with-ttf \
--with-gdbm \
--with-gettext \
--with-db4 \
--with-ncurses \
--with-gmp \
--with-iconv \
--with-jpeg-dir=${CONF_PREFIX} \
--with-mm \
--with-openssl \
--with-png \
--with-pspell \
--with-regex=system \
--with-xml \
--with-domxml \
#44217 [Com]: Output after stdout/stderr closed cause immediate exit
ID: 44217
Comment by: duane at e164 dot org
Reported By: exe at travian dot org
Status: Open
Bug Type: Filesystem function related
Operating System: GNU/Linux Kernel 2.6.18
PHP Version: 5.2.5
New Comment:
The solution to stopping this output is rather simple. After you close
the stdin/stdout/stderr open 3 new file descriptors to /dev/null and all
output goes bye bye. eg.
fclose(STDIN);
fclose(STDOUT);
fclose(STDERR);
$fp1 = fopen('/dev/null', 'r');
$fp2 = fopen('/dev/null', 'w');
$fp3 = fopen('/dev/null', 'w');
Previous Comments:
[2008-02-25 11:54:22] exe at travian dot org
I'd expect php to discard every output after STDOUT is closed, instead
of doing a silent exit (which is hard to track because no error handler
or shutdown function is called). Another option (if output in this
situation is considered to be an error) would be to trigger a
warning/fatal and/or call the shutdown function. This would, at least,
make it possible to track this issue.
I have to close STDOUT and STDERR in a daemonized processes to detach
from the controlling terminal.
[2008-02-24 00:40:01] [EMAIL PROTECTED]
Another bug #44218 describes some more expected behaviour caused by
closing the input/output streams.
NOTE: Correct manual page:
http://www.php.net/manual/en/wrappers.php.php
[2008-02-24 00:34:08] [EMAIL PROTECTED]
That's quite expected since you're still trying to output to STDOUT.
Why do you want to close STDOUT anyway?
See also: http://www.php.net/wrappers.php
[2008-02-22 17:32:15] exe at travian dot org
Description:
If STDOUT and/or STDERR are closed, output by the php script cause the
interpreter to exit immediately.
According to strace output, php tries to write to the closed STDOUT
file handle, causing a "Bad file descriptor" error and exit of the
interpreter:
[...]
close(1)= 0
[...]
write(1, "foo", 3) = -1 EBADF (Bad file
descriptor)
close(0)= 0
close(2)= 0
[...]
exit_group(0) = ?
Process 19177 detached
Reproduce code:
---
Expected result:
No output, php sleeping for 10 seconds.
Actual result:
--
php exits immediately, strace shows an "Bad file descriptor" on the
write() try to STDOUT:
[...]
read(3, "http://bugs.php.net/?id=44217&edit=1
