#29249 [Com]: imagettfbbox / imagettfbbox returning wrong values w/ linebreaks
ID: 29249 Comment by: spam at dtdsoft dot com Reported By: kees at tweakers dot net Status: No Feedback Bug Type: GD related Operating System: Linux PHP Version: 5.0.0 New Comment: This bug is still present in PHP 5.2.0 (Running on Windows XP) I am posting this to reactiveate the bug and make it known that it is still present. ~DtD BTW> I fixed it by multiplying the height by substr_count($string,"\n")+1) Previous Comments: [2005-01-22 01:00:17] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-01-15 00:42:59] [EMAIL PROTECTED] I think you need to pass the string with double quotes: bounds = imagettfbbox(8, 0, 'tahoma.ttf', "j\nj"); [2004-07-19 03:26:46] kees at tweakers dot net Actual result should be: -- Both will give the same result, a box of x: 15 y: 12. [2004-07-19 03:24:20] kees at tweakers dot net Description: The imagettfbbox / imagettftext should return an array with the boundaries on texts. This works fine with a single string, but if you use a multiline string (with \n in it) it fails to report the actual size, and returns the size / box of a single line. The string _is_ writen normally on the image, ie; with a newline instead of an \n, but the sizes are wrong. Reproduce code: --- // string with a line break, try imagettftext, it'll put the correct string on the image, but return the wrong results $bounds = imagettfbbox(8, 0, 'tahoma.ttf', 'j\nj'); print_r($bounds); // no line break here, just a \ instead of a /, which is the same size. $bounds = imagettfbbox(8, 0, 'tahoma.ttf', 'j/nj'); print_r($bounds); Expected result: The first line should return something like a box with an x/y of 3 / 26 (or close), the second result should return (and does ;)) an x/y box of 15 / 12. Actual result: -- Both will give the same result, a box of x: 15 y: 26. -- Edit this bug report at http://bugs.php.net/?id=29249&edit=1
#40260 [Fbk->Opn]: PDO causing segfault in PHP
ID: 40260
User updated by: kyle at grishlan dot com
Reported By: kyle at grishlan dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Linux-Gentoo
PHP Version: 5.2.0
New Comment:
Using 5.2 appears to fix this bug, thank you.
Previous Comments:
[2007-01-28 01:12:30] [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
[2007-01-28 00:19:39] kyle at grishlan dot com
Description:
I have a PDO object connecting to a MySQL database, and I pass the
object to the __construct function of a new object. In the __construct
function, I attempt to make prepared statement with the PDO object, and
if I then exit(1) or die(), without unsetting the PDOStatement object,
PHP segfaults.
This is a similar bug to http://bugs.php.net/bug.php?id=37445 (In that
it has the same final few functions in the backtrace), but I don't
believe it to be the same issue. I have also tried (per that bug's
comments) mysql_statement.c versions 1.48.2.12, 1.48.2.13, 1.48.2.14,
and 1.48.2.14.2.2, but they've all reproduced the problem.
My PHP is version 5.1.6-r6 (I'm not running 5.2+ as it's not currently
in the gentoo repository.
Reproduce code:
---
prepare("SELECT * FROM my_table_name");
$stmt->execute();
while ($row = $stmt->fetch())
print_r($row);
$stmt->closeCursor();
// Commenting this out makes PHP segfault
unset($stmt);
// Commenting this out (if commented above) fixes the
segfault
exit(1);
}
};
$pdo = new PDO('mysql:host=localhost;dbname=my_db_name', 'root', '');
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, TRUE);
$myclass = new MyClass($pdo);
?>
Expected result:
No output.
Actual result:
--
Segmentation fault (backtrace provided below)
(gdb) backt
#0 0xb76566ae in mysql_more_results (mysql=0x5a5a5a5a) at
libmysql.c:5136
#1 0x081cd839 in pdo_mysql_stmt_dtor (stmt=0x87fb374)
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/ext/pdo_mysql/mysql_statement.c:71
#2 0x081c5897 in free_statement (stmt=0x87fb374)
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/ext/pdo/pdo_stmt.c:2200
#3 0x08309d58 in zend_objects_store_free_object_storage
(objects=0x86815ec)
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/Zend/zend_objects_API.c:86
#4 0x082e23bb in shutdown_executor ()
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/Zend/zend_execute_API.c:281
#5 0x082eddfd in zend_deactivate ()
at /var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/Zend/zend.c:854
#6 0x082aa5a3 in php_request_shutdown (dummy=0x0)
at /var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/main/main.c:1292
#7 0x0837e7aa in main (argc=2, argv=0xbf910804)
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/sapi/cli/php_cli.c:1246
--
Edit this bug report at http://bugs.php.net/?id=40260&edit=1
#40228 [Asn->Fbk]: extractTo not extracting empty directories
ID: 40228
Updated by: [EMAIL PROTECTED]
Reported By: php-bugs at spuetz dot ath dot cx
-Status: Assigned
+Status: Feedback
Bug Type: Zip Related
Operating System: Linux
PHP Version: 5.2.0
Assigned To: pajoye
New Comment:
It is fixed in PECL CVS. I will merge into PHP as soon as possible.
You can try the fix using the pecl cvs version. I will merge into PHP
as soon as possible.
Previous Comments:
[2007-01-25 08:44:19] php-bugs at spuetz dot ath dot cx
http://mas.screenwork-dev.de/test.zip
md5 hash is 5f681fa09b179d4763421ea724b3a207
[2007-01-25 00:21:27] [EMAIL PROTECTED]
Can you provide a link to the "test.zip" archive please?
Thanks,
[2007-01-25 00:19:26] php-bugs at spuetz dot ath dot cx
It still doesn't work with:
$ php -v
PHP 5.2.1RC4-dev (cli) (built: Jan 25 2007 01:13:23)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
[2007-01-24 23:53:55] [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
[2007-01-24 23:50:22] php-bugs at spuetz dot ath dot cx
Description:
I have a issue with extractTo(), it's not extracting empty directories.
Reproduce code:
---
$ mkdir -p test/empty
$ zip -r test.zip test
adding: test/ (stored 0%)
adding: test/empty/ (stored 0%)
$ rm -rf test
$ php -r '$zip = new ZipArchive(); $zip->open("test.zip");
$zip->extractTo("./");'
Expected result:
unzip works as expected:
$ unzip test.zip
Archive: test.zip
creating: test/
creating: test/empty/
find
.
./test
./test/empty
./test.zip
Actual result:
--
$ find
.
./test
./test.zip
--
Edit this bug report at http://bugs.php.net/?id=40228&edit=1
#40261 [Opn]: Extremely slow data handling in specific situation
ID: 40261
User updated by: thuejk at gmail dot com
Reported By: thuejk at gmail dot com
Status: Open
Bug Type: Performance problem
Operating System: Linux
PHP Version: 5.2.0
New Comment:
On second though, black boxes are not good for testing. A simpler timer
added...
Previous Comments:
[2007-01-28 01:47:01] thuejk at gmail dot com
I have made it a bit shorter.
I left the DebugStats class in, it is useful. Just treat it as a black
box. I can garantie that the two calls into it does not account for the
8 seconds performance problem...
[2007-01-28 01:30:33] [EMAIL PROTECTED]
Could please modify the script, so that it would be _short_ but
complete?
[2007-01-28 01:25:13] thuejk at gmail dot com
I added the requested changes to the linked file
http://thuejk.dk/test.php.txt
[2007-01-28 01:15:25] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-01-28 00:30:02] thuejk at gmail dot com
Description:
I have some code which produces unacceptible performance in a specific
situation. Making a completely trivial change improves performance a
hundred-fold or more.
The problem is 100% reproducible.
The code looks something like:
/* pseudocode*/
function get_data_from_pgsql(){
...
$map = Array();
foreach ($rows as $row) {
$map = row[index];
}
return $map;
}
$data1 = get_data_from_pgsql
$data2 = get_data_from_pgsql
One run with 1 rows of result took 8.77 seconds, which is clearly
silly. Making the extremely trivial change of moving the code block
foreach ($rows as $row) {
$map = row[index];
}
out of the function get_data_from_pgsql(), the code suddently only
takes 0.1 seconds to run (factor 90)! Having more rows in the result
makes the factor difference larger; it seems to increase
quadratically.
Not saving the return values in $data1 and $data2 also improves
performance immensely.
PHP 5.1.5 did not have this problem (or at least it was much smaller).
Reproduce code:
---
http://thuejk.dk/test.php.txt
You need a running postgresql database with one table, which has at
least 1 entries.
change the line
$translate_outside_function = false;
at the top of the file to see the difference mentioned above.
--
Edit this bug report at http://bugs.php.net/?id=40261&edit=1
#40261 [Fbk->Opn]: Extremely slow data handling in specific situation
ID: 40261
User updated by: thuejk at gmail dot com
Reported By: thuejk at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Performance problem
Operating System: Linux
PHP Version: 5.2.0
New Comment:
I have made it a bit shorter.
I left the DebugStats class in, it is useful. Just treat it as a black
box. I can garantie that the two calls into it does not account for the
8 seconds performance problem...
Previous Comments:
[2007-01-28 01:30:33] [EMAIL PROTECTED]
Could please modify the script, so that it would be _short_ but
complete?
[2007-01-28 01:25:13] thuejk at gmail dot com
I added the requested changes to the linked file
http://thuejk.dk/test.php.txt
[2007-01-28 01:15:25] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-01-28 00:30:02] thuejk at gmail dot com
Description:
I have some code which produces unacceptible performance in a specific
situation. Making a completely trivial change improves performance a
hundred-fold or more.
The problem is 100% reproducible.
The code looks something like:
/* pseudocode*/
function get_data_from_pgsql(){
...
$map = Array();
foreach ($rows as $row) {
$map = row[index];
}
return $map;
}
$data1 = get_data_from_pgsql
$data2 = get_data_from_pgsql
One run with 1 rows of result took 8.77 seconds, which is clearly
silly. Making the extremely trivial change of moving the code block
foreach ($rows as $row) {
$map = row[index];
}
out of the function get_data_from_pgsql(), the code suddently only
takes 0.1 seconds to run (factor 90)! Having more rows in the result
makes the factor difference larger; it seems to increase
quadratically.
Not saving the return values in $data1 and $data2 also improves
performance immensely.
PHP 5.1.5 did not have this problem (or at least it was much smaller).
Reproduce code:
---
http://thuejk.dk/test.php.txt
You need a running postgresql database with one table, which has at
least 1 entries.
change the line
$translate_outside_function = false;
at the top of the file to see the difference mentioned above.
--
Edit this bug report at http://bugs.php.net/?id=40261&edit=1
#40261 [Opn->Fbk]: Extremely slow data handling in specific situation
ID: 40261
Updated by: [EMAIL PROTECTED]
Reported By: thuejk at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Performance problem
Operating System: Linux
PHP Version: 5.2.0
New Comment:
Could please modify the script, so that it would be _short_ but
complete?
Previous Comments:
[2007-01-28 01:25:13] thuejk at gmail dot com
I added the requested changes to the linked file
http://thuejk.dk/test.php.txt
[2007-01-28 01:15:25] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-01-28 00:30:02] thuejk at gmail dot com
Description:
I have some code which produces unacceptible performance in a specific
situation. Making a completely trivial change improves performance a
hundred-fold or more.
The problem is 100% reproducible.
The code looks something like:
/* pseudocode*/
function get_data_from_pgsql(){
...
$map = Array();
foreach ($rows as $row) {
$map = row[index];
}
return $map;
}
$data1 = get_data_from_pgsql
$data2 = get_data_from_pgsql
One run with 1 rows of result took 8.77 seconds, which is clearly
silly. Making the extremely trivial change of moving the code block
foreach ($rows as $row) {
$map = row[index];
}
out of the function get_data_from_pgsql(), the code suddently only
takes 0.1 seconds to run (factor 90)! Having more rows in the result
makes the factor difference larger; it seems to increase
quadratically.
Not saving the return values in $data1 and $data2 also improves
performance immensely.
PHP 5.1.5 did not have this problem (or at least it was much smaller).
Reproduce code:
---
http://thuejk.dk/test.php.txt
You need a running postgresql database with one table, which has at
least 1 entries.
change the line
$translate_outside_function = false;
at the top of the file to see the difference mentioned above.
--
Edit this bug report at http://bugs.php.net/?id=40261&edit=1
#40261 [Fbk->Opn]: Extremely slow data handling in specific situation
ID: 40261
User updated by: thuejk at gmail dot com
Reported By: thuejk at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Performance problem
Operating System: Linux
PHP Version: 5.2.0
New Comment:
I added the requested changes to the linked file
http://thuejk.dk/test.php.txt
Previous Comments:
[2007-01-28 01:15:25] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-01-28 00:30:02] thuejk at gmail dot com
Description:
I have some code which produces unacceptible performance in a specific
situation. Making a completely trivial change improves performance a
hundred-fold or more.
The problem is 100% reproducible.
The code looks something like:
/* pseudocode*/
function get_data_from_pgsql(){
...
$map = Array();
foreach ($rows as $row) {
$map = row[index];
}
return $map;
}
$data1 = get_data_from_pgsql
$data2 = get_data_from_pgsql
One run with 1 rows of result took 8.77 seconds, which is clearly
silly. Making the extremely trivial change of moving the code block
foreach ($rows as $row) {
$map = row[index];
}
out of the function get_data_from_pgsql(), the code suddently only
takes 0.1 seconds to run (factor 90)! Having more rows in the result
makes the factor difference larger; it seems to increase
quadratically.
Not saving the return values in $data1 and $data2 also improves
performance immensely.
PHP 5.1.5 did not have this problem (or at least it was much smaller).
Reproduce code:
---
http://thuejk.dk/test.php.txt
You need a running postgresql database with one table, which has at
least 1 entries.
change the line
$translate_outside_function = false;
at the top of the file to see the difference mentioned above.
--
Edit this bug report at http://bugs.php.net/?id=40261&edit=1
#40261 [Opn->Fbk]: Extremely slow data handling in specific situation
ID: 40261
Updated by: [EMAIL PROTECTED]
Reported By: thuejk at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Performance problem
Operating System: Linux
PHP Version: 5.2.0
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2007-01-28 00:30:02] thuejk at gmail dot com
Description:
I have some code which produces unacceptible performance in a specific
situation. Making a completely trivial change improves performance a
hundred-fold or more.
The problem is 100% reproducible.
The code looks something like:
/* pseudocode*/
function get_data_from_pgsql(){
...
$map = Array();
foreach ($rows as $row) {
$map = row[index];
}
return $map;
}
$data1 = get_data_from_pgsql
$data2 = get_data_from_pgsql
One run with 1 rows of result took 8.77 seconds, which is clearly
silly. Making the extremely trivial change of moving the code block
foreach ($rows as $row) {
$map = row[index];
}
out of the function get_data_from_pgsql(), the code suddently only
takes 0.1 seconds to run (factor 90)! Having more rows in the result
makes the factor difference larger; it seems to increase
quadratically.
Not saving the return values in $data1 and $data2 also improves
performance immensely.
PHP 5.1.5 did not have this problem (or at least it was much smaller).
Reproduce code:
---
http://thuejk.dk/test.php.txt
You need a running postgresql database with one table, which has at
least 1 entries.
change the line
$translate_outside_function = false;
at the top of the file to see the difference mentioned above.
--
Edit this bug report at http://bugs.php.net/?id=40261&edit=1
#40260 [Opn->Fbk]: PDO causing segfault in PHP
ID: 40260
Updated by: [EMAIL PROTECTED]
Reported By: kyle at grishlan dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Linux-Gentoo
PHP Version: 5.2.0
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:
[2007-01-28 00:19:39] kyle at grishlan dot com
Description:
I have a PDO object connecting to a MySQL database, and I pass the
object to the __construct function of a new object. In the __construct
function, I attempt to make prepared statement with the PDO object, and
if I then exit(1) or die(), without unsetting the PDOStatement object,
PHP segfaults.
This is a similar bug to http://bugs.php.net/bug.php?id=37445 (In that
it has the same final few functions in the backtrace), but I don't
believe it to be the same issue. I have also tried (per that bug's
comments) mysql_statement.c versions 1.48.2.12, 1.48.2.13, 1.48.2.14,
and 1.48.2.14.2.2, but they've all reproduced the problem.
My PHP is version 5.1.6-r6 (I'm not running 5.2+ as it's not currently
in the gentoo repository.
Reproduce code:
---
prepare("SELECT * FROM my_table_name");
$stmt->execute();
while ($row = $stmt->fetch())
print_r($row);
$stmt->closeCursor();
// Commenting this out makes PHP segfault
unset($stmt);
// Commenting this out (if commented above) fixes the
segfault
exit(1);
}
};
$pdo = new PDO('mysql:host=localhost;dbname=my_db_name', 'root', '');
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, TRUE);
$myclass = new MyClass($pdo);
?>
Expected result:
No output.
Actual result:
--
Segmentation fault (backtrace provided below)
(gdb) backt
#0 0xb76566ae in mysql_more_results (mysql=0x5a5a5a5a) at
libmysql.c:5136
#1 0x081cd839 in pdo_mysql_stmt_dtor (stmt=0x87fb374)
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/ext/pdo_mysql/mysql_statement.c:71
#2 0x081c5897 in free_statement (stmt=0x87fb374)
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/ext/pdo/pdo_stmt.c:2200
#3 0x08309d58 in zend_objects_store_free_object_storage
(objects=0x86815ec)
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/Zend/zend_objects_API.c:86
#4 0x082e23bb in shutdown_executor ()
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/Zend/zend_execute_API.c:281
#5 0x082eddfd in zend_deactivate ()
at /var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/Zend/zend.c:854
#6 0x082aa5a3 in php_request_shutdown (dummy=0x0)
at /var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/main/main.c:1292
#7 0x0837e7aa in main (argc=2, argv=0xbf910804)
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/sapi/cli/php_cli.c:1246
--
Edit this bug report at http://bugs.php.net/?id=40260&edit=1
#40261 [NEW]: Extremely slow data handling in specific situation
From: thuejk at gmail dot com
Operating system: Linux
PHP version: 5.2.0
PHP Bug Type: Performance problem
Bug description: Extremely slow data handling in specific situation
Description:
I have some code which produces unacceptible performance in a specific
situation. Making a completely trivial change improves performance a
hundred-fold or more.
The problem is 100% reproducible.
The code looks something like:
/* pseudocode*/
function get_data_from_pgsql(){
...
$map = Array();
foreach ($rows as $row) {
$map = row[index];
}
return $map;
}
$data1 = get_data_from_pgsql
$data2 = get_data_from_pgsql
One run with 1 rows of result took 8.77 seconds, which is clearly
silly. Making the extremely trivial change of moving the code block
foreach ($rows as $row) {
$map = row[index];
}
out of the function get_data_from_pgsql(), the code suddently only takes
0.1 seconds to run (factor 90)! Having more rows in the result makes the
factor difference larger; it seems to increase quadratically.
Not saving the return values in $data1 and $data2 also improves
performance immensely.
PHP 5.1.5 did not have this problem (or at least it was much smaller).
Reproduce code:
---
http://thuejk.dk/test.php.txt
You need a running postgresql database with one table, which has at least
1 entries.
change the line
$translate_outside_function = false;
at the top of the file to see the difference mentioned above.
--
Edit bug report at http://bugs.php.net/?id=40261&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40261&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40261&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40261&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40261&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40261&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40261&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40261&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40261&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40261&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40261&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40261&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40261&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40261&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40261&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40261&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40261&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40261&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40261&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40261&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40261&r=mysqlcfg
#40260 [NEW]: PDO causing segfault in PHP
From: kyle at grishlan dot com
Operating system: Linux-Gentoo
PHP version: 5.2.0
PHP Bug Type: PDO related
Bug description: PDO causing segfault in PHP
Description:
I have a PDO object connecting to a MySQL database, and I pass the object
to the __construct function of a new object. In the __construct function,
I attempt to make prepared statement with the PDO object, and if I then
exit(1) or die(), without unsetting the PDOStatement object, PHP
segfaults.
This is a similar bug to http://bugs.php.net/bug.php?id=37445 (In that it
has the same final few functions in the backtrace), but I don't believe it
to be the same issue. I have also tried (per that bug's comments)
mysql_statement.c versions 1.48.2.12, 1.48.2.13, 1.48.2.14, and
1.48.2.14.2.2, but they've all reproduced the problem.
My PHP is version 5.1.6-r6 (I'm not running 5.2+ as it's not currently in
the gentoo repository.
Reproduce code:
---
prepare("SELECT * FROM my_table_name");
$stmt->execute();
while ($row = $stmt->fetch())
print_r($row);
$stmt->closeCursor();
// Commenting this out makes PHP segfault
unset($stmt);
// Commenting this out (if commented above) fixes the
segfault
exit(1);
}
};
$pdo = new PDO('mysql:host=localhost;dbname=my_db_name', 'root', '');
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, TRUE);
$myclass = new MyClass($pdo);
?>
Expected result:
No output.
Actual result:
--
Segmentation fault (backtrace provided below)
(gdb) backt
#0 0xb76566ae in mysql_more_results (mysql=0x5a5a5a5a) at
libmysql.c:5136
#1 0x081cd839 in pdo_mysql_stmt_dtor (stmt=0x87fb374)
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/ext/pdo_mysql/mysql_statement.c:71
#2 0x081c5897 in free_statement (stmt=0x87fb374)
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/ext/pdo/pdo_stmt.c:2200
#3 0x08309d58 in zend_objects_store_free_object_storage
(objects=0x86815ec)
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/Zend/zend_objects_API.c:86
#4 0x082e23bb in shutdown_executor ()
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/Zend/zend_execute_API.c:281
#5 0x082eddfd in zend_deactivate ()
at /var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/Zend/zend.c:854
#6 0x082aa5a3 in php_request_shutdown (dummy=0x0)
at /var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/main/main.c:1292
#7 0x0837e7aa in main (argc=2, argv=0xbf910804)
at
/var/tmp/portage/php-5.1.6-r6/work/php-5.1.6/sapi/cli/php_cli.c:1246
--
Edit bug report at http://bugs.php.net/?id=40260&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40260&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40260&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40260&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40260&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40260&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40260&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40260&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40260&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40260&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40260&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40260&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40260&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40260&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40260&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40260&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40260&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40260&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40260&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40260&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40260&r=mysqlcfg
#40259 [Opn->Asn]: ob_start call many times - memory error
ID: 40259 Updated by: [EMAIL PROTECTED] Reported By: tomwys at o2 dot pl -Status: Open +Status: Assigned Bug Type: Output Control Operating System: Linux PHP Version: 5.2.0 -Assigned To: +Assigned To: mike New Comment: Mike, this looks like a stack overflow to me (note that ob_flush() is used, not ob_end_flush() so we got insane amount of nested buffers). Do you think you can do something about it? Previous Comments: [2007-01-27 22:13:21] tomwys at o2 dot pl Description: I have tested this code on two machines. I have memory error or endless loop. On first machine code fails from $count = 385 on second machine from $count = 1633. Reproduce code: --- Expected result: 123456789101112[etc.] Actual result: -- First machine: 1[there is endless loop and 100% CPU] Second machine: 1*** glibc detected *** double free or corruption (top): 0x04c9c370 *** Aborted -- Edit this bug report at http://bugs.php.net/?id=40259&edit=1
#40259 [NEW]: ob_start call many times - memory error
From: tomwys at o2 dot pl Operating system: Linux PHP version: 5.2.0 PHP Bug Type: Output Control Bug description: ob_start call many times - memory error Description: I have tested this code on two machines. I have memory error or endless loop. On first machine code fails from $count = 385 on second machine from $count = 1633. Reproduce code: --- Expected result: 123456789101112[etc.] Actual result: -- First machine: 1[there is endless loop and 100% CPU] Second machine: 1*** glibc detected *** double free or corruption (top): 0x04c9c370 *** Aborted -- Edit bug report at http://bugs.php.net/?id=40259&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40259&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40259&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40259&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40259&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40259&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40259&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40259&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40259&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40259&r=support Expected behavior:http://bugs.php.net/fix.php?id=40259&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40259&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40259&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40259&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40259&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40259&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40259&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40259&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40259&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40259&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40259&r=mysqlcfg
#40257 [Bgs]: stream_context_create() causes memory leaks
ID: 40257 User updated by: angry dot slipper at gmail dot com Reported By: angry dot slipper at gmail dot com Status: Bogus Bug Type: Streams related Operating System: Linux Fedora 4 -PHP Version: 5.2.1RC4 +PHP Version: 5.2.1RC5 New Comment: You could destroy contexts when all streams using it are closed. So when I call fclose() my previously defined $context gets unset freeing up RAM... I think that would solve the whole thing. Previous Comments: [2007-01-27 16:01:38] angry dot slipper at gmail dot com I have a daemon written in PHP which connects to remote servers via fopen() sending POST data. How do I clean up RAM? I need this daemon to run for months without restarting it. PS: I can’t use CURL, cause I need to read from stream with dynamically changed buffer. [2007-01-27 15:32:43] [EMAIL PROTECTED] All memory leaks are reported automatically. stream_context_create() creates stream context and adds it to the resource list, which is freed on shutdown. You cannot free the context with unset(), because there might be open streams using it. [2007-01-27 15:25:29] angry dot slipper at gmail dot com Description: stream_context_create() causes memory leaks. PHP version is actualy 5.2.1RC5 - latest available. Reproduce code: --- #!/www/httpd/php/cli -ne array( 'method'=>"POST", 'request_fulluri'=>"POST http://www.google.com HTTP/1.0", 'header' => 'Content-type: application/x-www-form-urlencoded', 'content' => $postdata ) ); $context=stream_context_create($options); unset($context,$options); echo "current: ",memory_get_usage()," delta: ",(memory_get_usage()-$prev)."\n"; $prev=memory_get_usage(); } ?> Expected result: "current: 74496 delta: 0" line repeated. Actual result: -- current: 87368 delta: 87368 current: 18 delta: 12520 <...many lines here> current: 1319348 delta: 12440 As you can clearly see each iteration eatch 12kb of RAM, which it shouldn't. If you comment the $context=stream_context_create($options); line out, delta in the example above will always be at 0. -- Edit this bug report at http://bugs.php.net/?id=40257&edit=1
#40257 [Bgs]: stream_context_create() causes memory leaks
ID: 40257 User updated by: angry dot slipper at gmail dot com Reported By: angry dot slipper at gmail dot com Status: Bogus Bug Type: Streams related Operating System: Linux Fedora 4 PHP Version: 5.2.1RC4 New Comment: I have a daemon written in PHP which connects to remote servers via fopen() sending POST data. How do I clean up RAM? I need this daemon to run for months without restarting it. PS: I can’t use CURL, cause I need to read from stream with dynamically changed buffer. Previous Comments: [2007-01-27 15:32:43] [EMAIL PROTECTED] All memory leaks are reported automatically. stream_context_create() creates stream context and adds it to the resource list, which is freed on shutdown. You cannot free the context with unset(), because there might be open streams using it. [2007-01-27 15:25:29] angry dot slipper at gmail dot com Description: stream_context_create() causes memory leaks. PHP version is actualy 5.2.1RC5 - latest available. Reproduce code: --- #!/www/httpd/php/cli -ne array( 'method'=>"POST", 'request_fulluri'=>"POST http://www.google.com HTTP/1.0", 'header' => 'Content-type: application/x-www-form-urlencoded', 'content' => $postdata ) ); $context=stream_context_create($options); unset($context,$options); echo "current: ",memory_get_usage()," delta: ",(memory_get_usage()-$prev)."\n"; $prev=memory_get_usage(); } ?> Expected result: "current: 74496 delta: 0" line repeated. Actual result: -- current: 87368 delta: 87368 current: 18 delta: 12520 <...many lines here> current: 1319348 delta: 12440 As you can clearly see each iteration eatch 12kb of RAM, which it shouldn't. If you comment the $context=stream_context_create($options); line out, delta in the example above will always be at 0. -- Edit this bug report at http://bugs.php.net/?id=40257&edit=1
#40256 [Opn->Bgs]: PHP & Apache segfaults when using curl
ID: 40256 Updated by: [EMAIL PROTECTED] Reported By: pentarh at gmail dot com -Status: Open +Status: Bogus Bug Type: cURL related Operating System: FreeBSD 6.2 PHP Version: 4.4.4 New Comment: Upgrade mysql client to the latest available version, AFAIK it's fixed there. Not PHP problem anyway. Previous Comments: [2007-01-27 15:43:23] pentarh at gmail dot com you right. it compiles well with either curl or mysql. i removed --with-mysql and "make install" worked without segfault. But i need both curl and mysql. what should i do? [2007-01-27 15:29:41] [EMAIL PROTECTED] Remove --with-mysql from the configure line to make sure your problems are not caused by conflict between YaSSL used in MySQL and OpenSSL. [2007-01-27 15:17:45] pentarh at gmail dot com Description: OS: FreeBSD 6.2 am64 trying to compile latest PHP 4.4.4 (also tried fresh snapshot php4-STABLE-200701271330) with curl 7.16.0 ./configure \ --with-gd=/usr/local \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/local/mysql \ --with-mysql-sock=/tmp/mysql.sock \ --with-freetype-dir=/usr/local \ --enable-gd-native-ttf \ --with-jpeg=/usr/local \ --with-jpeg-dir=/usr/local/include \ --with-png-dir=/usr/local/include \ --with-zlib-dir=/usr/local/lib \ --enable-ftp \ --enable-sockets \ --with-curl=/usr/local after make install got the error: # make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp4.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp4.la /usr/local/apache2/modules/ cp .libs/libphp4.so /usr/local/apache2/modules/libphp4.so cp .libs/libphp4.lai /usr/local/apache2/modules/libphp4.la libtool: install: warning: remember to run `libtool --finish /usr/work/php4-STABLE-200701271330/libs' chmod 755 /usr/local/apache2/modules/libphp4.so [activating module `php4' in /usr/local/apache2/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ Segmentation fault (core dumped) *** Error code 139 Apache does segfault on start with libphp4.so activated. These all problems appear when using --with-curl backtrace of php CLI segfault #0 0x0008012e0ab8 in ENGINE_add () from /lib/libcrypto.so.4 #1 0x0008012834b6 in ENGINE_load_cswift () from /lib/libcrypto.so.4 #2 0x00080127683e in ENGINE_load_builtin_engines () from /lib/libcrypto.so.4 #3 0x000800fac309 in Curl_ossl_init () at ssluse.c:559 #4 0x000800fb496d in curl_global_init (flags=1) at easy.c:229 #5 0x00469973 in zm_startup_curl (type=9360897, module_number=35, tsrm_ls=0x23) at /usr/work/php4-STABLE-200701271330/ext/curl/curl.c:487 #6 0x0054909c in zend_startup_module (module=0x717720) at /usr/work/php4-STABLE-200701271330/Zend/zend_API.c:1006 #7 0x00510325 in php_startup_extensions (ptr=0x72a530, count=19892511) at /usr/work/php4-STABLE-200701271330/main/main.c:1056 #8 0x00510970 in php_module_startup (sf=0x723e00, additional_modules=0x0, num_additional_modules=0) at /usr/work/php4-STABLE-200701271330/main/main.c:1230 #9 0x00564aae in main (argc=16, argv=0x7fffe8c8) at /usr/work/php4-STABLE-200701271330/sapi/cli/php_cli.c:588 Reproduce code: --- ./configure \ --with-gd=/usr/local \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/local/mysql \ --with-mysql-sock=/tmp/mysql.sock \ --with-freetype-dir=/usr/local \ --enable-gd-native-ttf \ --with-jpeg=/usr/local \ --with-jpeg-dir=/usr/local/include \ --with-png-dir=/usr/local/include \ --with-zlib-dir=/usr/local/lib \ --enable-ftp \ --enable-sockets \ --with-curl=/usr/local make make install Expected result: no segfault Actual result: -- segfault -- Edit this bug report at http://bugs.php.net/?id=40256&edit=1
#40256 [Fbk->Opn]: PHP & Apache segfaults when using curl
ID: 40256 User updated by: pentarh at gmail dot com Reported By: pentarh at gmail dot com -Status: Feedback +Status: Open Bug Type: cURL related Operating System: FreeBSD 6.2 PHP Version: 4.4.4 New Comment: you right. it compiles well with either curl or mysql. i removed --with-mysql and "make install" worked without segfault. But i need both curl and mysql. what should i do? Previous Comments: [2007-01-27 15:29:41] [EMAIL PROTECTED] Remove --with-mysql from the configure line to make sure your problems are not caused by conflict between YaSSL used in MySQL and OpenSSL. [2007-01-27 15:17:45] pentarh at gmail dot com Description: OS: FreeBSD 6.2 am64 trying to compile latest PHP 4.4.4 (also tried fresh snapshot php4-STABLE-200701271330) with curl 7.16.0 ./configure \ --with-gd=/usr/local \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/local/mysql \ --with-mysql-sock=/tmp/mysql.sock \ --with-freetype-dir=/usr/local \ --enable-gd-native-ttf \ --with-jpeg=/usr/local \ --with-jpeg-dir=/usr/local/include \ --with-png-dir=/usr/local/include \ --with-zlib-dir=/usr/local/lib \ --enable-ftp \ --enable-sockets \ --with-curl=/usr/local after make install got the error: # make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp4.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp4.la /usr/local/apache2/modules/ cp .libs/libphp4.so /usr/local/apache2/modules/libphp4.so cp .libs/libphp4.lai /usr/local/apache2/modules/libphp4.la libtool: install: warning: remember to run `libtool --finish /usr/work/php4-STABLE-200701271330/libs' chmod 755 /usr/local/apache2/modules/libphp4.so [activating module `php4' in /usr/local/apache2/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ Segmentation fault (core dumped) *** Error code 139 Apache does segfault on start with libphp4.so activated. These all problems appear when using --with-curl backtrace of php CLI segfault #0 0x0008012e0ab8 in ENGINE_add () from /lib/libcrypto.so.4 #1 0x0008012834b6 in ENGINE_load_cswift () from /lib/libcrypto.so.4 #2 0x00080127683e in ENGINE_load_builtin_engines () from /lib/libcrypto.so.4 #3 0x000800fac309 in Curl_ossl_init () at ssluse.c:559 #4 0x000800fb496d in curl_global_init (flags=1) at easy.c:229 #5 0x00469973 in zm_startup_curl (type=9360897, module_number=35, tsrm_ls=0x23) at /usr/work/php4-STABLE-200701271330/ext/curl/curl.c:487 #6 0x0054909c in zend_startup_module (module=0x717720) at /usr/work/php4-STABLE-200701271330/Zend/zend_API.c:1006 #7 0x00510325 in php_startup_extensions (ptr=0x72a530, count=19892511) at /usr/work/php4-STABLE-200701271330/main/main.c:1056 #8 0x00510970 in php_module_startup (sf=0x723e00, additional_modules=0x0, num_additional_modules=0) at /usr/work/php4-STABLE-200701271330/main/main.c:1230 #9 0x00564aae in main (argc=16, argv=0x7fffe8c8) at /usr/work/php4-STABLE-200701271330/sapi/cli/php_cli.c:588 Reproduce code: --- ./configure \ --with-gd=/usr/local \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/local/mysql \ --with-mysql-sock=/tmp/mysql.sock \ --with-freetype-dir=/usr/local \ --enable-gd-native-ttf \ --with-jpeg=/usr/local \ --with-jpeg-dir=/usr/local/include \ --with-png-dir=/usr/local/include \ --with-zlib-dir=/usr/local/lib \ --enable-ftp \ --enable-sockets \ --with-curl=/usr/local make make install Expected result: no segfault Actual result: -- segfault -- Edit this bug report at http://bugs.php.net/?id=40256&edit=1
#40257 [Opn->Bgs]: stream_context_create() causes memory leaks
ID: 40257 Updated by: [EMAIL PROTECTED] Reported By: angry dot slipper at gmail dot com -Status: Open +Status: Bogus Bug Type: Streams related Operating System: Linux Fedora 4 PHP Version: 5.2.1RC4 New Comment: All memory leaks are reported automatically. stream_context_create() creates stream context and adds it to the resource list, which is freed on shutdown. You cannot free the context with unset(), because there might be open streams using it. Previous Comments: [2007-01-27 15:25:29] angry dot slipper at gmail dot com Description: stream_context_create() causes memory leaks. PHP version is actualy 5.2.1RC5 - latest available. Reproduce code: --- #!/www/httpd/php/cli -ne array( 'method'=>"POST", 'request_fulluri'=>"POST http://www.google.com HTTP/1.0", 'header' => 'Content-type: application/x-www-form-urlencoded', 'content' => $postdata ) ); $context=stream_context_create($options); unset($context,$options); echo "current: ",memory_get_usage()," delta: ",(memory_get_usage()-$prev)."\n"; $prev=memory_get_usage(); } ?> Expected result: "current: 74496 delta: 0" line repeated. Actual result: -- current: 87368 delta: 87368 current: 18 delta: 12520 <...many lines here> current: 1319348 delta: 12440 As you can clearly see each iteration eatch 12kb of RAM, which it shouldn't. If you comment the $context=stream_context_create($options); line out, delta in the example above will always be at 0. -- Edit this bug report at http://bugs.php.net/?id=40257&edit=1
#40256 [Opn->Fbk]: PHP & Apache segfaults when using curl
ID: 40256 Updated by: [EMAIL PROTECTED] Reported By: pentarh at gmail dot com -Status: Open +Status: Feedback Bug Type: cURL related Operating System: FreeBSD 6.2 PHP Version: 4.4.4 New Comment: Remove --with-mysql from the configure line to make sure your problems are not caused by conflict between YaSSL used in MySQL and OpenSSL. Previous Comments: [2007-01-27 15:17:45] pentarh at gmail dot com Description: OS: FreeBSD 6.2 am64 trying to compile latest PHP 4.4.4 (also tried fresh snapshot php4-STABLE-200701271330) with curl 7.16.0 ./configure \ --with-gd=/usr/local \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/local/mysql \ --with-mysql-sock=/tmp/mysql.sock \ --with-freetype-dir=/usr/local \ --enable-gd-native-ttf \ --with-jpeg=/usr/local \ --with-jpeg-dir=/usr/local/include \ --with-png-dir=/usr/local/include \ --with-zlib-dir=/usr/local/lib \ --enable-ftp \ --enable-sockets \ --with-curl=/usr/local after make install got the error: # make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp4.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp4.la /usr/local/apache2/modules/ cp .libs/libphp4.so /usr/local/apache2/modules/libphp4.so cp .libs/libphp4.lai /usr/local/apache2/modules/libphp4.la libtool: install: warning: remember to run `libtool --finish /usr/work/php4-STABLE-200701271330/libs' chmod 755 /usr/local/apache2/modules/libphp4.so [activating module `php4' in /usr/local/apache2/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ Segmentation fault (core dumped) *** Error code 139 Apache does segfault on start with libphp4.so activated. These all problems appear when using --with-curl backtrace of php CLI segfault #0 0x0008012e0ab8 in ENGINE_add () from /lib/libcrypto.so.4 #1 0x0008012834b6 in ENGINE_load_cswift () from /lib/libcrypto.so.4 #2 0x00080127683e in ENGINE_load_builtin_engines () from /lib/libcrypto.so.4 #3 0x000800fac309 in Curl_ossl_init () at ssluse.c:559 #4 0x000800fb496d in curl_global_init (flags=1) at easy.c:229 #5 0x00469973 in zm_startup_curl (type=9360897, module_number=35, tsrm_ls=0x23) at /usr/work/php4-STABLE-200701271330/ext/curl/curl.c:487 #6 0x0054909c in zend_startup_module (module=0x717720) at /usr/work/php4-STABLE-200701271330/Zend/zend_API.c:1006 #7 0x00510325 in php_startup_extensions (ptr=0x72a530, count=19892511) at /usr/work/php4-STABLE-200701271330/main/main.c:1056 #8 0x00510970 in php_module_startup (sf=0x723e00, additional_modules=0x0, num_additional_modules=0) at /usr/work/php4-STABLE-200701271330/main/main.c:1230 #9 0x00564aae in main (argc=16, argv=0x7fffe8c8) at /usr/work/php4-STABLE-200701271330/sapi/cli/php_cli.c:588 Reproduce code: --- ./configure \ --with-gd=/usr/local \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/local/mysql \ --with-mysql-sock=/tmp/mysql.sock \ --with-freetype-dir=/usr/local \ --enable-gd-native-ttf \ --with-jpeg=/usr/local \ --with-jpeg-dir=/usr/local/include \ --with-png-dir=/usr/local/include \ --with-zlib-dir=/usr/local/lib \ --enable-ftp \ --enable-sockets \ --with-curl=/usr/local make make install Expected result: no segfault Actual result: -- segfault -- Edit this bug report at http://bugs.php.net/?id=40256&edit=1
#35872 [Com]: CLI errors upon exit if class is left on IE
ID: 35872
Comment by: wharmby at uk dot ibm dot com
Reported By: csaba at alum dot mit dot edu
Status: Assigned
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.1.1
Assigned To: wez
New Comment:
I will take a look at this one next
Previous Comments:
[2006-01-02 15:32:12] csaba at alum dot mit dot edu
Description:
If IE is left open when a PHP script ends, and we have affixed a class
instance to IE, CLI generates an error.
Csaba Gabor from Vienna
Reproduce code:
---
visible = true;// show it
$ie->Navigate2("about:blank");// give IE empty DOM
while ($ie->readyState<4) usleep(1); // wait for ready
class frob { }// dummy class
$frob = new frob; // instantiate it
$window=$ie->document->parentWindow; // window ref
$window->execScript("window.myclass=false"); // always allocate ie
vars
$window->myclass = $frob; // pathway to PHP
$window->alert ("Program is ending"); // proof of no errors to here
//$window->myclass = null; // CLI errors if this commented out
?>
Expected result:
PHP is quite good about cleaning up after itself. I expect PHP to
nicely finish and leave IE up, without and CLI error dialogs asking if
I want to send a report to Microsoft.
Actual result:
--
After dismissing the "Program is ending" alert box, I get the dreaded
CLI error dialog asking if I want to send a report to Microsoft.
--
Edit this bug report at http://bugs.php.net/?id=35872&edit=1
#40257 [NEW]: stream_context_create() causes memory leaks
From: angry dot slipper at gmail dot com Operating system: Linux Fedora 4 PHP version: 5.2.1RC4 PHP Bug Type: Streams related Bug description: stream_context_create() causes memory leaks Description: stream_context_create() causes memory leaks. PHP version is actualy 5.2.1RC5 - latest available. Reproduce code: --- #!/www/httpd/php/cli -ne array( 'method'=>"POST", 'request_fulluri'=>"POST http://www.google.com HTTP/1.0", 'header' => 'Content-type: application/x-www-form-urlencoded', 'content' => $postdata ) ); $context=stream_context_create($options); unset($context,$options); echo "current: ",memory_get_usage()," delta: ",(memory_get_usage()-$prev)."\n"; $prev=memory_get_usage(); } ?> Expected result: "current: 74496 delta: 0" line repeated. Actual result: -- current: 87368 delta: 87368 current: 18 delta: 12520 <...many lines here> current: 1319348 delta: 12440 As you can clearly see each iteration eatch 12kb of RAM, which it shouldn't. If you comment the $context=stream_context_create($options); line out, delta in the example above will always be at 0. -- Edit bug report at http://bugs.php.net/?id=40257&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40257&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40257&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40257&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40257&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40257&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40257&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40257&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40257&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40257&r=support Expected behavior:http://bugs.php.net/fix.php?id=40257&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40257&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40257&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40257&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40257&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40257&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40257&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40257&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40257&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40257&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40257&r=mysqlcfg
#40256 [NEW]: PHP & Apache segfaults when using curl
From: pentarh at gmail dot com Operating system: FreeBSD 6.2 PHP version: 4.4.4 PHP Bug Type: cURL related Bug description: PHP & Apache segfaults when using curl Description: OS: FreeBSD 6.2 am64 trying to compile latest PHP 4.4.4 (also tried fresh snapshot php4-STABLE-200701271330) with curl 7.16.0 ./configure \ --with-gd=/usr/local \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/local/mysql \ --with-mysql-sock=/tmp/mysql.sock \ --with-freetype-dir=/usr/local \ --enable-gd-native-ttf \ --with-jpeg=/usr/local \ --with-jpeg-dir=/usr/local/include \ --with-png-dir=/usr/local/include \ --with-zlib-dir=/usr/local/lib \ --enable-ftp \ --enable-sockets \ --with-curl=/usr/local after make install got the error: # make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp4.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp4.la /usr/local/apache2/modules/ cp .libs/libphp4.so /usr/local/apache2/modules/libphp4.so cp .libs/libphp4.lai /usr/local/apache2/modules/libphp4.la libtool: install: warning: remember to run `libtool --finish /usr/work/php4-STABLE-200701271330/libs' chmod 755 /usr/local/apache2/modules/libphp4.so [activating module `php4' in /usr/local/apache2/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ Segmentation fault (core dumped) *** Error code 139 Apache does segfault on start with libphp4.so activated. These all problems appear when using --with-curl backtrace of php CLI segfault #0 0x0008012e0ab8 in ENGINE_add () from /lib/libcrypto.so.4 #1 0x0008012834b6 in ENGINE_load_cswift () from /lib/libcrypto.so.4 #2 0x00080127683e in ENGINE_load_builtin_engines () from /lib/libcrypto.so.4 #3 0x000800fac309 in Curl_ossl_init () at ssluse.c:559 #4 0x000800fb496d in curl_global_init (flags=1) at easy.c:229 #5 0x00469973 in zm_startup_curl (type=9360897, module_number=35, tsrm_ls=0x23) at /usr/work/php4-STABLE-200701271330/ext/curl/curl.c:487 #6 0x0054909c in zend_startup_module (module=0x717720) at /usr/work/php4-STABLE-200701271330/Zend/zend_API.c:1006 #7 0x00510325 in php_startup_extensions (ptr=0x72a530, count=19892511) at /usr/work/php4-STABLE-200701271330/main/main.c:1056 #8 0x00510970 in php_module_startup (sf=0x723e00, additional_modules=0x0, num_additional_modules=0) at /usr/work/php4-STABLE-200701271330/main/main.c:1230 #9 0x00564aae in main (argc=16, argv=0x7fffe8c8) at /usr/work/php4-STABLE-200701271330/sapi/cli/php_cli.c:588 Reproduce code: --- ./configure \ --with-gd=/usr/local \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/local/mysql \ --with-mysql-sock=/tmp/mysql.sock \ --with-freetype-dir=/usr/local \ --enable-gd-native-ttf \ --with-jpeg=/usr/local \ --with-jpeg-dir=/usr/local/include \ --with-png-dir=/usr/local/include \ --with-zlib-dir=/usr/local/lib \ --enable-ftp \ --enable-sockets \ --with-curl=/usr/local make make install Expected result: no segfault Actual result: -- segfault -- Edit bug report at http://bugs.php.net/?id=40256&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40256&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40256&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40256&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40256&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40256&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40256&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40256&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40256&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40256&r=support Expected behavior:http://bugs.php.net/fix.php?id=40256&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40256&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40256&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40256&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40256&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40256&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40256&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40256&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40256&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40256&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40256&r=mysqlcfg
#40253 [Opn->Fbk]: Bug with classes!
ID: 40253 Updated by: [EMAIL PROTECTED] Reported By: seregwethrin at gmail dot com -Status: Open +Status: Feedback -Bug Type: Scripting Engine problem +Bug Type: Unknown/Other Function Operating System: Windows Server 2003 PHP Version: 5.2.0 New Comment: Cannot reproduce or see any other problems with the code you've provided. Previous Comments: [2007-01-27 00:10:31] seregwethrin at gmail dot com Description: I've tested this with Apache 2.0.59 and PHP 5.2.0 There's an critical class error. When you want to insert a predefined variable (i've get error with $_SESSION) as class var like $this->mysession If you can't see this error i can send a video about error. Reproduce code: --- db = $db; $this->eC = $eC; $this->sess = $_SESSION; //error line } } ?> Expected result: Page loading loading and loading forever... No error, no log (apache and php log files are clear), no warning, and page loading... Nothing shows at the page. Actual result: -- I'll install PHP 5.1.2 and there's no error at 5.1.2. So there's and bug at php 5.2.0 (i'm sure) -- Edit this bug report at http://bugs.php.net/?id=40253&edit=1
#38921 [Opn->Bgs]: pdo lost the first row data:with firebird blob data
ID: 38921
Updated by: [EMAIL PROTECTED]
Reported By: achun dot shx at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: InterBase related
Operating System: windows
PHP Version: 5.1.6
New Comment:
Confirmed, see bug #35386.
Previous Comments:
[2007-01-27 00:50:57] drew dot winther at netce dot com
This is a dupe of http://bugs.php.net/bug.php?id=35386
[2006-09-22 09:24:31] achun dot shx at gmail dot com
Description:
on firebird/interbase table.
pdo fetch data .
lost the first row data when the field type is blob.
php 5.11/5.12 too
Reproduce code:
---
//sql code
CREATE TABLE test (
ID INTEGER,
DAT BLOB SUB_TYPE 1 SEGMENT SIZE 80
);
//inset any data
INSERT INTO test (ID,DAT) VALUES (1,'aaa');
INSERT INTO test (ID,DAT) VALUES (2,'bbb');
//php code
$dbh = new PDO("firebird:dbname=xxx",'SYSDBA','masterkey');
$sth=$dbh->query('SELECT * from test;');
while ($row=$sth->fetch(2)){
print_r($row);
}
//lost the first row data VALUES (1,'aaa')
Array
(
[ID] =>
[DAT] =>
)
Array
(
[ID] => 2
[DAT] => bbb
)
--
Edit this bug report at http://bugs.php.net/?id=38921&edit=1
#40252 [Opn->Bgs]: $_GET superglobals do not work within included files
ID: 40252 Updated by: [EMAIL PROTECTED] Reported By: jonathan dot cowher at gmail dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP Pro SP2 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: [2007-01-27 00:07:37] jonathan dot cowher at gmail dot com Description: The $_GET superglobals are not available when called from included files. Reproduce code: --- - included file --- Expected result: The value of $myToken is outputed to the screen. Actual result: -- $myToken does not have any value associated with. I even tried using print_r($_GET) which returns an empty array. I have tried upgrading to PHP5 as well, but I have the same issue. -- Edit this bug report at http://bugs.php.net/?id=40252&edit=1
