Bug #61947 [Com]: curl Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=61947edit=1 ID: 61947 Comment by: ceo at l-i-e dot com Reported by:ly...@php.net Summary:curl Segmentation fault Status: Open Type: Bug Package:cURL related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I've got 9 more of these backtraces if you want them. And about 8 of these with no backtrace or anything at all: [Fri May 04 10:59:37 2012] [notice] child pid 24011 exit signal Segmentation fault (11) [Fri May 04 11:10:00 2012] [notice] child pid 24050 exit signal Segmentation fault (11) [Fri May 04 11:10:03 2012] [notice] child pid 24044 exit signal Segmentation fault (11) [Fri May 04 18:23:31 2012] [notice] child pid 27659 exit signal Segmentation fault (11) [Fri May 04 19:15:25 2012] [notice] child pid 27830 exit signal Segmentation fault (11) [Fri May 04 19:15:34 2012] [notice] child pid 27832 exit signal Segmentation fault (11) [Fri May 04 19:17:53 2012] [notice] child pid 26396 exit signal Segmentation fault (11) [Fri May 04 20:17:11 2012] [notice] child pid 28059 exit signal Segmentation fault (11) Those look more like apache crashes, I presume... PHP may have been the root cause, however, if something is scrambling RAM. Previous Comments: [2012-05-05 04:52:36] ly...@php.net Description: libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 It's PHP 5.1.3, so you may not care, but that's what was handed to me on the GoDaddy server by my client, and I hesitate to upgrade until we take the issue up with GoDaddy first. In the meantime, since I have a stacktrace with at least some debugging symbols in it, and it specifically mentions Curl_cookie_cleanup, I thought it might be something useful, even if it's an older PHP version. curl with CURLOPT_COOKIEJAR and CURLOPT_COOKIE file. I'm using curl_multi functions, so I guess it could be a factor. I'm hitting the same URL with different cookie files and log files, create with tempnam. I would assume that using two curl handles with the same cookie file and/or log file would be a Bad Idea. I have tail all the /tmp/curllog* files. Some are just empty. Others have nothing interesting at the end. I suppose the empty one could be the ones that correspond to the segfaults, but don't quite see how that info would be useful... Unless it narrows down a portion of the code. Test script: --- Could be this one: curl_setopt($curl, CURLOPT_RETURNTRANSFER, TRUE) or ($errors[] = 'RETURNTRANSFER'); curl_setopt($curl, CURLOPT_FOLLOWLOCATION, TRUE) or ($errors[] = 'FOLLOWLOCATION'); curl_setopt($curl, CURLOPT_HEADER, FALSE) or ($errors[] = 'HEADER'); curl_setopt($curl, CURLOPT_HTTPGET, TRUE) or ($errors[] = 'HTTPGET'); curl_setopt($curl, CURLOPT_TIMEOUT, 60) or ($errors[] = 'TIMEOUT'); curl_setopt($curl, CURLOPT_COOKIEFILE, $depart_cookies) or ($errors[] = 'COOKIEFILE'); curl_setopt($curl, CURLOPT_COOKIEJAR, dirname(__FILE__) . /$direction.txt) or ($errors[] = 'COOKIEJAR'); curl_setopt($curl, CURLOPT_VERBOSE, TRUE) or ($errors[] = 'VERBOSE'); $log = fopen($curllog, 'a+') or ($errors[] = FOPEN $curllog); curl_setopt($curl, CURLOPT_STDERR, $log) or ($errors[] = 'STDERR'); Or it could be that one above with the following changes to the $curl handle: curl_setopt($curl, CURLOPT_POST, TRUE); curl_setopt($curl, CURLOPT_POSTFIELDS, $post_data); I will try to error_log something in between to narrow it down. Expected result: PHP to not crash. Actual result: -- *** glibc detected *** /usr/sbin/httpd: free(): corrupted unsorted chunks: 0xb87a8508 *** === Backtrace: = /lib/libc.so.6[0xb7bbd5a5] /lib/libc.so.6(cfree+0x59)[0xb7bbd9e9] /usr/lib/libcurl.so.3[0xb72e37ae] /usr/lib/libcurl.so.3(Curl_cookie_cleanup+0x3a)[0xb72e391a] /usr/lib/libcurl.so.3(Curl_close+0x127)[0xb72f44e7] /usr/lib/libcurl.so.3(curl_easy_cleanup+0x21)[0xb72ff421] /usr/lib/httpd/modules/libphp5.so[0xb7478e77] /usr/lib/httpd/modules/libphp5.so(list_entry_destructor+0xa3)[0xb75dd2c3] /usr/lib/httpd/modules/libphp5.so(zend_hash_del_key_or_index+0x221)[0xb75dc751] /usr/lib/httpd/modules/libphp5.so(_zend_list_delete+0x8a)[0xb75dd55a] /usr/lib/httpd/modules/libphp5.so(_zval_dtor_func+0x9a)[0xb75cfefa] /usr/lib/httpd/modules/libphp5.so(_zval_ptr_dtor+0x78)[0xb75c4598] /usr/lib/httpd/modules/libphp5.so(zend_hash_destroy+0x47)[0xb75da697] /usr/lib/httpd/modules/libphp5.so(_zval_dtor_func+0x50)[0xb75cfeb0] /usr/lib/httpd/modules/libphp5.so(_zval_ptr_dtor+0x78)[0xb75c4598] /usr/lib/httpd/modules/libphp5.so(zend_hash_destroy+0x47)[0xb75da697] /usr
Bug #54062 [Com]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
Comment by: ceo at l-i-e dot com
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
Status: Open
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I have never known this to be the case.
...
$usleep = 200;
...
usleep($usleep);
...
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
almost never or never?
Not really the same...
Not sure PHP even processes and abort in the middle of usleep.
2 seconds is a long time in a normal request.
Try shorter usleep.
And when you *do* get an abort, call exit to really really really END
the script, bypassing any other shutdown functions.
Previous Comments:
[2011-02-21 15:44:03] james dot mk dot green at gmail dot com
Description:
Referencing http://php.net/manual/en/features.connection-handling.php
I understand that providing PHP is writing to or reading from the web
server connection, a registered shutdown function should be called
should the client abort.
I have never known this to be the case.
I attach a simple script. It attempts to sleep then write back to the
client. It has a registered shutdown function that checks
connection_status() and connection_aborted(). According to my syslog
however, the full script executes followed by the shutdown function
which says the user is still connected, despite my pressing the browser
stop button immediately after placing the request.
I have tested this on Windows using Lighttpd with PHP 5.2, and on Ubuntu
with Apache preforking PHP 5.3. Both exhibit the same behaviour.
These tests were conducted with ignore_user_abort(true) and (false) - no
difference observed so I removed it.
Test script:
---
?php
syslog(LOG_DEBUG, 'Connection opened');
register_shutdown_function('shutdown');
$usleep = 200;
for ($i=0; $i 100; $i++) {
$str[$i] = '';
for ($x=0; $x 1000; $x++) {
$str[$i] .= 'flubber';
}
}
if (isset($_REQUEST['usleep'])) {
$usleep = (int) $_REQUEST['usleep'];
}
usleep($usleep);
syslog(LOG_DEBUG, 'Completed usleep()');
echo Thanks for waiting\n;
print_r($str);
ob_end_flush();
syslog(LOG_DEBUG, 'ob_end_flush() called');
flush();
syslog(LOG_DEBUG, 'Have flushed()');
// We get to this part regardless of having already pressed STOP
function shutdown()
{
echo Thanks for waiting\n;
flush();
syslog(LOG_DEBUG, 'Echo completed');
//sleep(1);
syslog(LOG_DEBUG, 'Have slept');
syslog(LOG_DEBUG, 'Shutdown detected.');
syslog(LOG_DEBUG, The result of connection_status() is: .
connection_status());
// The above is almost always 0
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
// This almost always happens!
syslog(LOG_DEBUG, 'The connection remains');
}
}
Expected result:
syslog entries should stop when PHP writes to the client socket and
notes that the client has sent an abort signal. Then, the shutdown
function should show that the connection_status() is no longer 0, and
that the connection_aborted() method returns true.
Actual result:
--
syslog entries continue to Have flushed(), then show that The result of
connection_status() is: 0. and The connection remains.
This should not be the case. Perhaps Apache is not sending the
appropriate signal, yet neither is Lighttpd..?
--
Edit this bug report at http://bugs.php.net/bug.php?id=54062edit=1
Bug #53242 [Com]: count() slow for global / static arrays
Edit report at http://bugs.php.net/bug.php?id=53242edit=1
ID: 53242
Comment by: ceo at l-i-e dot com
Reported by:einars at gmail dot com
Summary:count() slow for global / static arrays
Status: Bogus
Type: Bug
Package:Performance problem
Operating System: Arch Linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Call me crazy, but once you declare it global in the function, having a
local one seems kind of silly...
Why not just have the one zval?...
From a guy who knows very little of php internals, but can't figure out
the purpose of a local $items when it's been declared global in the
function body.
And static should be its own zval, not interacting in any way shape or
form with any zval in any other scope... So it should have a refcount
2 as well...
Previous Comments:
[2010-11-05 02:40:02] cataphr...@php.net
To be expected.
When you do global $items; the underlying zval has its refcount
incremented to 2 since now it's referred to by the global symbol $items
and the local symbol $items and the is_ref flag is set.
Since sizeof does not receive its argument by reference and you're
giving it an is_ref zval, a separation is forced and the value if
copied. Since $items refers to a big variable (50k+ items), the
performance penalty is big.
To cut the story short: use $foo = $GLOBALS['items'].
[2010-11-04 17:50:28] einars at gmail dot com
Description:
When the arrays are defined global or static, the sizeof() / count
method suddenly gets very slow.
Test script:
---
?php
$items = range(0, 5);
$times = 200;
$time = microtime(true);
for ($i = 0; $i $times; $i++) {
$foo = sizeof($items);
}
printf(Non-global access: %.2fs\n, microtime(true) - $time);
$time = microtime(true);
for ($i = 0; $i $times; $i++) {
test_global();
}
printf(Global access: %.2fs\n, microtime(true) - $time);
function test_global() {
global $items;
$foo = sizeof($items);
}
Expected result:
% php array-test.php
Non-global access: 0.00s
Global access: 0.00s
Actual result:
--
% php array-test.php
Non-global access: 0.00s
Global access: 2.73s
--
Edit this bug report at http://bugs.php.net/bug.php?id=53242edit=1
Bug #52266 [Com]: ldap_search Operations error for SizeLimit $results['count']
Edit report at http://bugs.php.net/bug.php?id=52266edit=1 ID: 52266 Comment by: ceo at l-i-e dot com Reported by: ceo at l-i-e dot com Summary: ldap_search Operations error for SizeLimit $results['count'] Status: Bogus Type: Bug Package: LDAP related Operating System: Mac OS X PHP Version: 5.3.2 New Comment: A User Contributed note suggested using 2, and I was foolish enough to try it. Other errors later corrected masked the issue at hand, and I thought it was still broken with 0 for AD 2003. I apologize for the noise. Previous Comments: [2010-07-08 12:29:16] patrickalla...@php.net Use ldap_set_option($ldapConn, LDAP_OPT_REFERRALS, 0); when connecting to AD server 2003 and searching in the whole AD schema. By the way, '2' is not a valid value for LDAP_OPT_REFERRALS which expect a value of 0 or 1. [2010-07-08 12:26:51] patrickalla...@php.net 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 Use ldap_set_option($ldapConn, LDAP_OPT_REFERRALS, 0); when connecting to AD server 2003 and searching in the whole AD schema. By the way, '2' is not a valid value for LDAP_OPT_REFERRALS which expect a value of 0 or 1. [2010-07-08 10:19:13] gra...@php.net According to the contributed notes in http://www.php.net/manual/en/function.ldap- search.php, LDAP_OPT_REFERRALS should be set to 0 and not 2 as you have in your test case. When set to 0 I don't see the Operations Error message. I also have it set this way to enable search in AD for a rudimentary phonebook. [2010-07-06 18:57:49] ceo at l-i-e dot com The AD version has been confirmed to be 2003. [2010-07-06 17:52:44] ceo at l-i-e dot com PS The same searches work fine from ldapsearch command line tool provided by OpenLDAP. Thus, logically, the error must reside in PHP's extension... 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/bug.php?id=52266 -- Edit this bug report at http://bugs.php.net/bug.php?id=52266edit=1
[PHP-BUG] Bug #52266 [NEW]: ldap_search Operations error for SizeLimit $results['count']
From: Operating system: Mac OS X PHP version: 5.3.2 Package: LDAP related Bug Type: Bug Bug description:ldap_search Operations error for SizeLimit $results['count'] Description: NOTE: *** It's actually PHP 5.3.1, from mac ports. Sorry. But I don't find anything related in bug searching, nor in the ChangeLog for 5.3.2, so pretty sure it's still active bug. *** Attempting to work with Active Directory via OpenLDAP/PHP. Search for '(cn=*)' works fine. Search for '(cn=*ynch)' fails with ldap_search: Search: Operations error Further analysis reveals that providing the fourth parameter, SizeLimit, which is equal to or less than the number of results, works fine. Larger numbers fail, in the same way as no limit. Of course, one doesn't generally know how many results are in there, so this is not really a good work-around... I believe the AD server is 2003 version, but it could be newer. The AD server is reputed to have 50,000 entries in it, which may be relevant. Test script: --- http://6112northwolcott.com/ldap/ldap.phps Expected result: I expect it to give me 16 results, no matter what number I put for the fourth parameter, or for none at all. Actual result: -- http://6112northwolcott.com/ldap/ldap.txt -- Edit bug report at http://bugs.php.net/bug.php?id=52266edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52266r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52266r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52266r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52266r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52266r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52266r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52266r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52266r=needscript Try newer version: http://bugs.php.net/fix.php?id=52266r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52266r=support Expected behavior: http://bugs.php.net/fix.php?id=52266r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52266r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52266r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52266r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52266r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52266r=dst IIS Stability: http://bugs.php.net/fix.php?id=52266r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52266r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52266r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52266r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52266r=mysqlcfg
Bug #52266 [Com]: ldap_search Operations error for SizeLimit $results['count']
Edit report at http://bugs.php.net/bug.php?id=52266edit=1 ID: 52266 Comment by: ceo at l-i-e dot com Reported by: ceo at l-i-e dot com Summary: ldap_search Operations error for SizeLimit $results['count'] Status: Open Type: Bug Package: LDAP related Operating System: Mac OS X PHP Version: 5.3.2 New Comment: PS The same searches work fine from ldapsearch command line tool provided by OpenLDAP. Thus, logically, the error must reside in PHP's extension... Previous Comments: [2010-07-06 17:51:19] ceo at l-i-e dot com Description: NOTE: *** It's actually PHP 5.3.1, from mac ports. Sorry. But I don't find anything related in bug searching, nor in the ChangeLog for 5.3.2, so pretty sure it's still active bug. *** Attempting to work with Active Directory via OpenLDAP/PHP. Search for '(cn=*)' works fine. Search for '(cn=*ynch)' fails with ldap_search: Search: Operations error Further analysis reveals that providing the fourth parameter, SizeLimit, which is equal to or less than the number of results, works fine. Larger numbers fail, in the same way as no limit. Of course, one doesn't generally know how many results are in there, so this is not really a good work-around... I believe the AD server is 2003 version, but it could be newer. The AD server is reputed to have 50,000 entries in it, which may be relevant. Test script: --- http://6112northwolcott.com/ldap/ldap.phps Expected result: I expect it to give me 16 results, no matter what number I put for the fourth parameter, or for none at all. Actual result: -- http://6112northwolcott.com/ldap/ldap.txt -- Edit this bug report at http://bugs.php.net/bug.php?id=52266edit=1
Bug #52266 [Com]: ldap_search Operations error for SizeLimit $results['count']
Edit report at http://bugs.php.net/bug.php?id=52266edit=1 ID: 52266 Comment by: ceo at l-i-e dot com Reported by: ceo at l-i-e dot com Summary: ldap_search Operations error for SizeLimit $results['count'] Status: Open Type: Bug Package: LDAP related Operating System: Mac OS X PHP Version: 5.3.2 New Comment: The AD version has been confirmed to be 2003. Previous Comments: [2010-07-06 17:52:44] ceo at l-i-e dot com PS The same searches work fine from ldapsearch command line tool provided by OpenLDAP. Thus, logically, the error must reside in PHP's extension... [2010-07-06 17:51:19] ceo at l-i-e dot com Description: NOTE: *** It's actually PHP 5.3.1, from mac ports. Sorry. But I don't find anything related in bug searching, nor in the ChangeLog for 5.3.2, so pretty sure it's still active bug. *** Attempting to work with Active Directory via OpenLDAP/PHP. Search for '(cn=*)' works fine. Search for '(cn=*ynch)' fails with ldap_search: Search: Operations error Further analysis reveals that providing the fourth parameter, SizeLimit, which is equal to or less than the number of results, works fine. Larger numbers fail, in the same way as no limit. Of course, one doesn't generally know how many results are in there, so this is not really a good work-around... I believe the AD server is 2003 version, but it could be newer. The AD server is reputed to have 50,000 entries in it, which may be relevant. Test script: --- http://6112northwolcott.com/ldap/ldap.phps Expected result: I expect it to give me 16 results, no matter what number I put for the fourth parameter, or for none at all. Actual result: -- http://6112northwolcott.com/ldap/ldap.txt -- Edit this bug report at http://bugs.php.net/bug.php?id=52266edit=1
#50610 [Bgs]: imagerotate transparent gif some angles invert new background
ID: 50610 User updated by: ceo at l-i-e dot com Reported By: ceo at l-i-e dot com Status: Bogus Bug Type: GD related Operating System: N/A -PHP Version: 5.2.6 +PHP Version: 5.3.2-dev New Comment: I have confirmed this bug remains in 5.3.2-dev on a localhost box. Previous Comments: [2009-12-30 08:49:19] j...@php.net Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. [2009-12-30 05:59:51] ceo at l-i-e dot com Description: imagerotate for a transparent input GIF, trying to output a transparent output GIF. At various angles it will fill the new / expanded background with the wrong (non-transparent black) color. This may be the same as http://bugs.php.net/bug.php?id=44429 but I can't tell without the other guy's image either... It could also be related to http://bugs.php.net/bug.php?id=39366 somehow, but that pre-dates this quite a bit, and is supposedly fixed in CVS (now SVN). Plus that's PNG not GIF, though there may be shared code at work. I do have a nice repro for you below. NOTE: This happened to me in PHP 5.2.5, and it's conceivable that it has been fixed, but it has also been confirmed in 5.2.6 by Jochem Maas: [quote] I tested on PHP5.2.6, with the following GD installed: GD Version bundled (2.0.34 compatible) FreeType Support enabled FreeType Linkage with freetype FreeType Version 2.3.7 GIF Read Support enabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Support enabled XPM Support enabled XBM Support enabled I get the same result as you. I played with it a bit and the issue 'seems' to revolve around transparency in the original gif. I got the following code to output what you want but I have no idea if it's usable for you (you may be relying on the transparency in the original gif): Reproduce code: --- http://www.6112northwolcott.com/dogfight/rotate.phps Expected result: All the images in the actual result should have white / transparent backgrounds, unless I'm being particularly dense today. Actual result: -- http://www.6112northwolcott.com/dogfight/rotate.htm -- Edit this bug report at http://bugs.php.net/?id=50610edit=1
#50610 [Fbk-Opn]: imagerotate transparent gif some angles invert new background
ID: 50610 User updated by: ceo at l-i-e dot com Reported By: ceo at l-i-e dot com -Status: Feedback +Status: Open Bug Type: GD related Operating System: N/A PHP Version: 5.3.2-dev New Comment: Adding imagesavealpha($rotated, 1); at line 7, immediately after imagerotate but before imagegif does not have any visible effect. I.e., it's still broken. Previous Comments: [2009-12-30 23:51:01] j...@php.net How about bug #41624 ? [2009-12-30 17:12:02] ceo at l-i-e dot com I have confirmed this bug remains in 5.3.2-dev on a localhost box. [2009-12-30 05:59:51] ceo at l-i-e dot com Description: imagerotate for a transparent input GIF, trying to output a transparent output GIF. At various angles it will fill the new / expanded background with the wrong (non-transparent black) color. This may be the same as http://bugs.php.net/bug.php?id=44429 but I can't tell without the other guy's image either... It could also be related to http://bugs.php.net/bug.php?id=39366 somehow, but that pre-dates this quite a bit, and is supposedly fixed in CVS (now SVN). Plus that's PNG not GIF, though there may be shared code at work. I do have a nice repro for you below. NOTE: This happened to me in PHP 5.2.5, and it's conceivable that it has been fixed, but it has also been confirmed in 5.2.6 by Jochem Maas: [quote] I tested on PHP5.2.6, with the following GD installed: GD Version bundled (2.0.34 compatible) FreeType Support enabled FreeType Linkage with freetype FreeType Version 2.3.7 GIF Read Support enabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Support enabled XPM Support enabled XBM Support enabled I get the same result as you. I played with it a bit and the issue 'seems' to revolve around transparency in the original gif. I got the following code to output what you want but I have no idea if it's usable for you (you may be relying on the transparency in the original gif): Reproduce code: --- http://www.6112northwolcott.com/dogfight/rotate.phps Expected result: All the images in the actual result should have white / transparent backgrounds, unless I'm being particularly dense today. Actual result: -- http://www.6112northwolcott.com/dogfight/rotate.htm -- Edit this bug report at http://bugs.php.net/?id=50610edit=1
#50610 [NEW]: imagerotate transparent gif some angles invert new background
From: ceo at l-i-e dot com Operating system: N/A PHP version: 5.2.12 PHP Bug Type: GD related Bug description: imagerotate transparent gif some angles invert new background Description: imagerotate for a transparent input GIF, trying to output a transparent output GIF. At various angles it will fill the new / expanded background with the wrong (non-transparent black) color. This may be the same as http://bugs.php.net/bug.php?id=44429 but I can't tell without the other guy's image either... It could also be related to http://bugs.php.net/bug.php?id=39366 somehow, but that pre-dates this quite a bit, and is supposedly fixed in CVS (now SVN). Plus that's PNG not GIF, though there may be shared code at work. I do have a nice repro for you below. NOTE: This happened to me in PHP 5.2.5, and it's conceivable that it has been fixed, but it has also been confirmed in 5.2.6 by Jochem Maas: [quote] I tested on PHP5.2.6, with the following GD installed: GD Version bundled (2.0.34 compatible) FreeType Support enabled FreeType Linkage with freetype FreeType Version 2.3.7 GIF Read Support enabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Support enabled XPM Support enabled XBM Support enabled I get the same result as you. I played with it a bit and the issue 'seems' to revolve around transparency in the original gif. I got the following code to output what you want but I have no idea if it's usable for you (you may be relying on the transparency in the original gif): Reproduce code: --- http://www.6112northwolcott.com/dogfight/rotate.phps Expected result: All the images in the actual result should have white / transparent backgrounds, unless I'm being particularly dense today. Actual result: -- http://www.6112northwolcott.com/dogfight/rotate.htm -- Edit bug report at http://bugs.php.net/?id=50610edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50610r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50610r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50610r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50610r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50610r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50610r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50610r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50610r=needscript Try newer version: http://bugs.php.net/fix.php?id=50610r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50610r=support Expected behavior: http://bugs.php.net/fix.php?id=50610r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50610r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50610r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50610r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50610r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50610r=dst IIS Stability: http://bugs.php.net/fix.php?id=50610r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50610r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50610r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50610r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50610r=mysqlcfg
#45455 [NEW]: highlight_file could take start/length line numbers for excerpts
From: ceo at l-i-e dot com Operating system: N/A PHP version: 5.2.6 PHP Bug Type: Feature/Change Request Bug description: highlight_file could take start/length line numbers for excerpts Description: I would find highlight_file much more useful, particularly for writing on-line tutorials, articles, etc if it would take a line number and count optional arguments, to print out only an excerpt of the file. One could then intersperse bits of code and commentary very easily with original source files instead of having to keep code snippets in sync as you develop/author an article. One can, of course, play games with explode(br / and array_slice, but it's a bit of a pain, really. It would also be extra nifty if line numbers could be added on the left with yet another optional arg, and maybe even an arg for absolute|relative numbering for the snippets. PHP Rocks! -- Edit bug report at http://bugs.php.net/?id=45455edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45455r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45455r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45455r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45455r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45455r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45455r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45455r=needscript Try newer version:http://bugs.php.net/fix.php?id=45455r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45455r=support Expected behavior:http://bugs.php.net/fix.php?id=45455r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45455r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45455r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45455r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45455r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45455r=dst IIS Stability:http://bugs.php.net/fix.php?id=45455r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45455r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45455r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45455r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45455r=mysqlcfg
#42041 [NEW]: zend_language_scanner.c: No such file or directory
From: ceo at l-i-e dot com Operating system: Gentoo Linux PHP version: 5.2.3 PHP Bug Type: Compile Failure Bug description: zend_language_scanner.c: No such file or directory Description: Compiling from CVS. buildconf seemed to go okay... I'm using: autoconf: 2.13 automake: 1.5 libtool: 1.4.3 as documented here: http://www.php.net/anoncvs.php Though the version numbers of autoconf, automake, and libtool seem irrelevant, as I get the same results with current (according to Gentoo portage tree) versions... Reproduce code: --- Everything from here to the ./configure line may be irrelevant... On Gentoo, I used: emerge automake emerge autoconf emerge wget Then use wget to download libtool-1.4.3 from ftp.gnu.org wget installer requires newer auto[mumble] than php requires. :-( Usual source compile of libtool, since Gentoo has no libtool-1.4.3 in its portage tree. tar -xzvf libtool-1.4.3.tar.gz cd libtool-1.4.3 ./configure make make install Then, you have to symlink /usr/bin/libtool to /usr/local/bin/libtool, and I presumed it would be good to do libtoolize as well, so I did. emerge --unmerge autoconf emerge --unmerge automake emerge =autoconf-2.13 emerge =automake-1.5 Whew. This may or may not be Gentoo build specific, so all the preceding may be irrelevant... Grab -r PHP_5_2 from CVS. ./buildconf ./configure \ --enable-fastcgi \ --enable-debug \ --with-pgsql \ --disable-xml \ --disable-libxml \ --disable-simplexml \ --disable-xmlreader \ --disable-exmlwriter \ --disable-dom \ --without-pear make I really wanted to K.I.S.S. and have just PostgreSQL for this particular build. Expected result: The usual output of make, which I forgot what it is, even though I've seen it dozens of times. Actual result: -- php5/Zend/zend_language_scanner.c: No such file or directory -- Edit bug report at http://bugs.php.net/?id=42041edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42041r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42041r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42041r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42041r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42041r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42041r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42041r=needscript Try newer version:http://bugs.php.net/fix.php?id=42041r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42041r=support Expected behavior:http://bugs.php.net/fix.php?id=42041r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42041r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42041r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42041r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42041r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42041r=dst IIS Stability:http://bugs.php.net/fix.php?id=42041r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42041r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42041r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42041r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42041r=mysqlcfg
#42041 [Opn]: zend_language_scanner.c: No such file or directory
ID: 42041 User updated by: ceo at l-i-e dot com Reported By: ceo at l-i-e dot com Status: Open Bug Type: Compile Failure Operating System: Gentoo Linux PHP Version: 5.2.3 New Comment: Please re-classify this as a Documentation Feature Request. Downgrading flex to 2.5.4a-r6 did the trick. The documentation is quite explicit about autoconf/automake/libtool versions being crucial, which actually isn't crucial, at least for Gentoo. flex has no + after it is the only clue that you can't use current flex. It would be nice if the flex version was also stressed. Or if it just worked with flex 2.5.33 in the first place. :-) Previous Comments: [2007-07-19 06:13:51] ceo at l-i-e dot com Description: Compiling from CVS. buildconf seemed to go okay... I'm using: autoconf: 2.13 automake: 1.5 libtool: 1.4.3 as documented here: http://www.php.net/anoncvs.php Though the version numbers of autoconf, automake, and libtool seem irrelevant, as I get the same results with current (according to Gentoo portage tree) versions... Reproduce code: --- Everything from here to the ./configure line may be irrelevant... On Gentoo, I used: emerge automake emerge autoconf emerge wget Then use wget to download libtool-1.4.3 from ftp.gnu.org wget installer requires newer auto[mumble] than php requires. :-( Usual source compile of libtool, since Gentoo has no libtool-1.4.3 in its portage tree. tar -xzvf libtool-1.4.3.tar.gz cd libtool-1.4.3 ./configure make make install Then, you have to symlink /usr/bin/libtool to /usr/local/bin/libtool, and I presumed it would be good to do libtoolize as well, so I did. emerge --unmerge autoconf emerge --unmerge automake emerge =autoconf-2.13 emerge =automake-1.5 Whew. This may or may not be Gentoo build specific, so all the preceding may be irrelevant... Grab -r PHP_5_2 from CVS. ./buildconf ./configure \ --enable-fastcgi \ --enable-debug \ --with-pgsql \ --disable-xml \ --disable-libxml \ --disable-simplexml \ --disable-xmlreader \ --disable-exmlwriter \ --disable-dom \ --without-pear make I really wanted to K.I.S.S. and have just PostgreSQL for this particular build. Expected result: The usual output of make, which I forgot what it is, even though I've seen it dozens of times. Actual result: -- php5/Zend/zend_language_scanner.c: No such file or directory -- Edit this bug report at http://bugs.php.net/?id=42041edit=1
#41330 [NEW]: mail errors should be exposed to userland
From: ceo at l-i-e dot com Operating system: all PHP version: 5.2.2 PHP Bug Type: Feature/Change Request Bug description: mail errors should be exposed to userland Description: If the mail function fails, and returns false, there oughta be a mail_error() function that feeds back whatever the OS said was wrong. -- Edit bug report at http://bugs.php.net/?id=41330edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41330r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41330r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41330r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41330r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41330r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41330r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41330r=needscript Try newer version:http://bugs.php.net/fix.php?id=41330r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41330r=support Expected behavior:http://bugs.php.net/fix.php?id=41330r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41330r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41330r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41330r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41330r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41330r=dst IIS Stability:http://bugs.php.net/fix.php?id=41330r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41330r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41330r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41330r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41330r=mysqlcfg
#40470 [NEW]: Invalid session id should specify actual ID
From: ceo at l-i-e dot com Operating system: all PHP version: 5.2.1 PHP Bug Type: Feature/Change Request Bug description: Invalid session id should specify actual ID Description: A message such as this: [04-Dec-2006 18:21:56] PHP Warning: Unknown: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in Unknown on line 0 should be improved to specify the actual invalid ID. A busy site with many sessions will need that info to trace down the bug quickly. Expected result: Something like this: [04-Dec-2006 18:21:56] PHP Warning: Unknown: The session id '$#!^' contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=40470edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40470r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40470r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40470r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40470r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40470r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40470r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40470r=needscript Try newer version:http://bugs.php.net/fix.php?id=40470r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40470r=support Expected behavior:http://bugs.php.net/fix.php?id=40470r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40470r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40470r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40470r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40470r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40470r=dst IIS Stability:http://bugs.php.net/fix.php?id=40470r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40470r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40470r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40470r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40470r=mysqlcfg
#39880 [Fbk-Opn]: imap_open('/localfile') fails
ID: 39880
User updated by: ceo at l-i-e dot com
Reported By: ceo at l-i-e dot com
-Status: Feedback
+Status: Open
Bug Type: IMAP related
Operating System: Windows
PHP Version: 5.2.0
New Comment:
So I should be bugging the IMAP folks?
Some c-client (whatever that is) folks?
I have no idea what you're asking for, actually.
All I know is, the function works as documented in Linux, and fails to
work as documented in Windows.
Doesn't seem like it should be rocket science to read a simple text
file instead of opening up a network connection and all that...
What am I missing here?
I'm happy to take this issue elsewhere, but it's a Black Box to me, and
imap_open() is my only doorway.
Previous Comments:
[2006-12-19 09:07:24] [EMAIL PROTECTED]
This is what I see - the underlying c-client function is unable to open
a file. Right?
Why do you think it's PHP problem?
[2006-12-18 22:29:18] ceo at l-i-e dot com
Description:
imap_open('/localfile', '', '')
fails on Windows, but works on Linux.
I get this in the error log for Windows:
[Mon Dec 18 16:18:56 2006] [error] [client 127.0.0.1] PHP Warning:
imap_open() [a href='function.imap-open'function.i
map-open/a]: Couldn't open stream
C:/www/complaints.com/data/testdos.mbox in
C:\\www\\complaints.com\\imap_bug.php on
line 9
[Mon Dec 18 16:18:56 2006] [error] [client 127.0.0.1] PHP Notice:
Unknown: Can't open mailbox C:/www/complaints.com/dat
a/testdos.mbox: no such mailbox (errflg=2) in Unknown on line 0
Note that it's neither a path nor permissions problem, as fopen(...,
'r') and fgets() succeed.
Also note that it is not a cr/lf problem as the testunix.mbox and
testdos.mbox files are identical except for ^M at the ends.
Linux happily works with either line-ending.
Windows just plain doesn't work.
The Linux box is running 5.1.4, while the Windows is running 5.2.0, so
it *could* be a change from 5.1.4 to 5.2.0
Reproduce code:
---
http://acousticdemo.com/complaints/imap_bug.phps
Expected result:
Linux Output:
http://acousticdemo.com/complaints/imap_bug.php
Actual result:
--
Line 1 of testdos.mbox: From Richard Lynch Fri Dec 15 17:13:48 2006
Line 1 of testunix.mbox: From Richard Lynch Fri Dec 15 17:13:48 2006
Failed to imap_open(C:/www/complaints.com/data/testdos.mbox)
array(1) {
[0]=
string(75) Can't open mailbox
C:/www/complaints.com/data/testdos.mbox: no such mailbox
}
bool(false)
messages in C:/www/complaints.com/data/testdos.mbox:
bool(false)
bool(false)
Failed to imap_open(C:/www/complaints.com/data/testunix.mbox)
bool(false)
array(1) {
[0]=
string(76) Can't open mailbox
C:/www/complaints.com/data/testunix.mbox: no such mailbox
}
messages in C:/www/complaints.com/data/testunix.mbox:
--
Edit this bug report at http://bugs.php.net/?id=39880edit=1
#39880 [NEW]: imap_open('/localfile') fails
From: ceo at l-i-e dot com
Operating system: Windows
PHP version: 5.2.0
PHP Bug Type: IMAP related
Bug description: imap_open('/localfile') fails
Description:
imap_open('/localfile', '', '')
fails on Windows, but works on Linux.
I get this in the error log for Windows:
[Mon Dec 18 16:18:56 2006] [error] [client 127.0.0.1] PHP Warning:
imap_open() [a href='function.imap-open'function.i
map-open/a]: Couldn't open stream
C:/www/complaints.com/data/testdos.mbox in
C:\\www\\complaints.com\\imap_bug.php on
line 9
[Mon Dec 18 16:18:56 2006] [error] [client 127.0.0.1] PHP Notice:
Unknown: Can't open mailbox C:/www/complaints.com/dat
a/testdos.mbox: no such mailbox (errflg=2) in Unknown on line 0
Note that it's neither a path nor permissions problem, as fopen(..., 'r')
and fgets() succeed.
Also note that it is not a cr/lf problem as the testunix.mbox and
testdos.mbox files are identical except for ^M at the ends.
Linux happily works with either line-ending.
Windows just plain doesn't work.
The Linux box is running 5.1.4, while the Windows is running 5.2.0, so it
*could* be a change from 5.1.4 to 5.2.0
Reproduce code:
---
http://acousticdemo.com/complaints/imap_bug.phps
Expected result:
Linux Output:
http://acousticdemo.com/complaints/imap_bug.php
Actual result:
--
Line 1 of testdos.mbox: From Richard Lynch Fri Dec 15 17:13:48 2006
Line 1 of testunix.mbox: From Richard Lynch Fri Dec 15 17:13:48 2006
Failed to imap_open(C:/www/complaints.com/data/testdos.mbox)
array(1) {
[0]=
string(75) Can't open mailbox C:/www/complaints.com/data/testdos.mbox:
no such mailbox
}
bool(false)
messages in C:/www/complaints.com/data/testdos.mbox:
bool(false)
bool(false)
Failed to imap_open(C:/www/complaints.com/data/testunix.mbox)
bool(false)
array(1) {
[0]=
string(76) Can't open mailbox C:/www/complaints.com/data/testunix.mbox:
no such mailbox
}
messages in C:/www/complaints.com/data/testunix.mbox:
--
Edit bug report at http://bugs.php.net/?id=39880edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39880r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39880r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39880r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39880r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39880r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39880r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39880r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39880r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39880r=support
Expected behavior:http://bugs.php.net/fix.php?id=39880r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39880r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39880r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39880r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39880r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39880r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39880r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39880r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39880r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39880r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39880r=mysqlcfg
#39091 [Com]: Need to force variables to be declared
ID: 39091 Comment by: ceo at l-i-e dot com Reported By: addw at phcomp dot co dot uk Status: Open Bug Type: Feature/Change Request Operating System: any PHP Version: 5.2.0RC5 New Comment: Turn error_reporting to E_ALL, and you have exactly what you asked for, and so much more. Previous Comments: [2006-10-09 10:40:48] addw at phcomp dot co dot uk Description: Could we not use 'var' to declare variables outside of functions and have a config option or file related pragma that made not declaring a variable an error ? Yes: there would be a problem with existing code, so why not force variable declaration iff/after a 'var' declaration is seen. If you really want to do it properly, then we could use 'private' or 'static' to declare variables with the scope of the file that they are declared in (like in C). The most recent bug reference that I can find for this is: 14285 (Nov 2001). This is a MUST HAVE, it is the single most dangerous mis-feature of PHP. Don't get me wrong - I like PHP, but just hanker after perl's use strict - great at pointing out typeos. -- Edit this bug report at http://bugs.php.net/?id=39091edit=1
#37079 [NEW]: libicuuc.so.34 not found
From: ceo at l-i-e dot com Operating system: FreeBSD 5.3 PHP version: 6CVS-2006-04-14 (CVS) PHP Bug Type: *Compile Issues Bug description: libicuuc.so.34 not found Description: Configure complains that libicu18n.so.34 can't find libicuuc.so.34 when they are sitting right next to each other. Reproduce code: --- Install 5.0.4 in /usr/local Uninstall ICU from /usr/local, if you have it. cd ~/ cvs co -r 6 You need ICU, and don't have it in /usr/local, and don't/can't put it there. Compile ICU from source in ~/icu Use a configure line like mine: ./configure --enable-debug --enable-maintainer-zts --prefix=/www/acousticdemo.com/cvs/usr/local --with-icu-dir=/www/acousticdemo.com/cvs/usr/local --with-libxml-dir=/usr/local,shared --includedir=/www/acousticdemo.com/cvs/usr/local/include:/usr/local/include --libdir=/www/acousticdemo.com/cvs/usr/local/lib:/usr/local/lib $@ Change /www/acousticdemo.com/cvs to your own home, of course. [Optional?] Comment out the broken test for libxml2 working build. [another bug, not relevant, almost-for-sure] make Now, even though libicu18n.so.34 and libicuuc.34.so are sitting in the same lib directory, it complains that libicu18n.so.34 can't find libicuuc.34.so and it needs it. Expected result: I guess I'd expect that if it can find libicu18n to find out that it needs libicuuc then it ought to find the libicuuc sitting right next to it. But maybe that's not how it all work... -- Edit bug report at http://bugs.php.net/?id=37079edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37079r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37079r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37079r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37079r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37079r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37079r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37079r=needscript Try newer version:http://bugs.php.net/fix.php?id=37079r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37079r=support Expected behavior:http://bugs.php.net/fix.php?id=37079r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37079r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37079r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37079r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37079r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37079r=dst IIS Stability:http://bugs.php.net/fix.php?id=37079r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37079r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37079r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37079r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37079r=mysqlcfg
#37061 [NEW]: Zend HashTable getting corrupted
From: ceo at l-i-e dot com Operating system: 5.3-RELEASE PHP version: 5.1.2 PHP Bug Type: Reproducible crash Bug description: Zend HashTable getting corrupted Description: It's a LONG script, but it always ends up in: Zend/zend_hash.c:66 (give or take lines changed in CVS) zend_output_debug_string(1, %s(%d) : ht=%p is being cleaned, file, line, ht); and then it just quits, with no other error output. I *suspect* that the root cause is in something like this: curl_setopt($curl, CURLOPT_BINARYTRANSFER, 1); curl_setopt($curl, CURLOPT_URL, 'http://example.com/example.jpg'); $jpeg = curl_exec($curl); //ASSUME that the server bounces us around with 302s and gives: htmlheadmeta http-equiv=Refresh src=0;http://example.com/;/headbody/body/html curl_setopt($curl, CURLOPT_BINARYTRANSFER, 0); curl_setopt($curl, CURLOPT_URL, 'http://example.com'); $html = curl_exec($curl); At this point, I get warnings about $html not being zero-terminated if I try to use it, and, sure enough, it's got garbage characters at the end. I SUSPECT that the curl handle is getting forced into non-binary mode because of the 302s and the fact that plain/text comes out at the end of that -- And I SUSPECT that this somehow gets the curl handle's binary status out of sync somehow with itself, and gets curl all confused. All of this, however, is just my suspicion... It COULD be the OCR GD stuff I'm doing... But something is definitely corrupting thing somewhere. Hopefully somebody who understand backtrace better than I can track it down... Reproduce code: --- http://acousticdemo.com/info.com/overture/overture.phps http://acousticdemo.com/info.com/overture/overture.inc.phps I am happy to provide my login/password to [EMAIL PROTECTED] if you can't reproduce and want to run this from CLI under gdb and see it in action. I've already done that, and can reproduce it in gdb. It just takes awhile to get to that state, and my short scripts are not yet causing the bug. :-( Also happens in: php_5.1.2 (release) php5.1-200604071630 php5.1-200604102030 Take your pick. Expected result: Ideally, it would just work and continue on, keeping track of strings and binary strings without me worrying about it. I'd settle for an E_ERROR for conditions where a server returns plain-text instead of binary expected. Or even an E_ERROR when the strings are known to be corrupted. But a silent failure with only C errors under --with-debug is pretty harsh. Actual result: -- Silent script end prematurely under normal CLI. --with-debug and gdb get me this: #0 _zend_is_inconsistent (ht=0x83e14a4, file=0x823e6b4 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c, line=752) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c:67 #1 0x081a899f in zend_hash_copy (target=0x83e0ca4, source=0x83e14a4, pCopyConstructor=0x819d0cc zval_add_ref, tmp=0xbfbfc950, size=4) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c:752 #2 0x0819d1ed in _zval_copy_ctor_func (zvalue=0x839ce64, __zend_filename=0x823d6b0 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.h, __zend_lineno=45) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.c:134 #3 0x0819da97 in _zval_copy_ctor (zvalue=0x839ce64, __zend_filename=0x823d628 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend.c, __zend_lineno=1009) at zend_variables.h:45 #4 0x0819ec52 in zend_error (type=2, format=0x823d488 String is not zero-terminated (%s) (source: %s:%d)) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend.c:1009 #5 0x0819cfb9 in _zval_dtor_func (zvalue=0x84c68a4, __zend_filename=0x823c3e0 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.h, __zend_lineno=35) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.c:35 #6 0x081919cb in _zval_dtor (zvalue=0x84c68a4, __zend_filename=0x823c344 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_execute_API.c, __zend_lineno=395) at zend_variables.h:35 #7 0x08191b84 in _zval_ptr_dtor (zval_ptr=0x83e0730, __zend_filename=0x823d4bc /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.c, __zend_lineno=175) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_execute_API.c:395 #8 0x0819d2f7 in _zval_ptr_dtor_wrapper (zval_ptr=0x83e0730) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.c:175 #9 0x081a8338 in zend_hash_clean (ht=0x83e14a4) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c:547 #10 0x081bcae1 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfbfd3e0) at zend_vm_execute.h:255 #11 0x081bd2f1 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfbfd3e0) at zend_vm_execute.h:322 #12 0x081bc486 in execute (op_array=0x8387124) at zend_vm_execute.h:92 #13 0x0819ef70 in zend_execute_scripts (type=8, retval=0x0
#37061 [Fbk-Opn]: Zend HashTable getting corrupted
ID: 37061 User updated by: ceo at l-i-e dot com Reported By: ceo at l-i-e dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash -Operating System: 5.3-RELEASE +Operating System: FreeBSD 5.3-RELEASE PHP Version: 5.1.2 New Comment: Corrected typo of OS. Sorry. Previous Comments: [2006-04-12 22:09:19] [EMAIL PROTECTED] 5.3-RELEASE Is it AIX 5.3 or ..? Try to build PHP with --enable-debug and --disable-zend-memory-manager and then run it through `valgrind --tool=memcheck` (see http://valgrind.org). And if you put the valgrind log somewhere in the net, that would give us a lot of useful information. Though, a short but complete reproduce script would be even better. [2006-04-12 22:03:23] ceo at l-i-e dot com Description: It's a LONG script, but it always ends up in: Zend/zend_hash.c:66 (give or take lines changed in CVS) zend_output_debug_string(1, %s(%d) : ht=%p is being cleaned, file, line, ht); and then it just quits, with no other error output. I *suspect* that the root cause is in something like this: curl_setopt($curl, CURLOPT_BINARYTRANSFER, 1); curl_setopt($curl, CURLOPT_URL, 'http://example.com/example.jpg'); $jpeg = curl_exec($curl); //ASSUME that the server bounces us around with 302s and gives: htmlheadmeta http-equiv=Refresh src=0;http://example.com/;/headbody/body/html curl_setopt($curl, CURLOPT_BINARYTRANSFER, 0); curl_setopt($curl, CURLOPT_URL, 'http://example.com'); $html = curl_exec($curl); At this point, I get warnings about $html not being zero-terminated if I try to use it, and, sure enough, it's got garbage characters at the end. I SUSPECT that the curl handle is getting forced into non-binary mode because of the 302s and the fact that plain/text comes out at the end of that -- And I SUSPECT that this somehow gets the curl handle's binary status out of sync somehow with itself, and gets curl all confused. All of this, however, is just my suspicion... It COULD be the OCR GD stuff I'm doing... But something is definitely corrupting thing somewhere. Hopefully somebody who understand backtrace better than I can track it down... Reproduce code: --- http://acousticdemo.com/info.com/overture/overture.phps http://acousticdemo.com/info.com/overture/overture.inc.phps I am happy to provide my login/password to [EMAIL PROTECTED] if you can't reproduce and want to run this from CLI under gdb and see it in action. I've already done that, and can reproduce it in gdb. It just takes awhile to get to that state, and my short scripts are not yet causing the bug. :-( Also happens in: php_5.1.2 (release) php5.1-200604071630 php5.1-200604102030 Take your pick. Expected result: Ideally, it would just work and continue on, keeping track of strings and binary strings without me worrying about it. I'd settle for an E_ERROR for conditions where a server returns plain-text instead of binary expected. Or even an E_ERROR when the strings are known to be corrupted. But a silent failure with only C errors under --with-debug is pretty harsh. Actual result: -- Silent script end prematurely under normal CLI. --with-debug and gdb get me this: #0 _zend_is_inconsistent (ht=0x83e14a4, file=0x823e6b4 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c, line=752) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c:67 #1 0x081a899f in zend_hash_copy (target=0x83e0ca4, source=0x83e14a4, pCopyConstructor=0x819d0cc zval_add_ref, tmp=0xbfbfc950, size=4) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c:752 #2 0x0819d1ed in _zval_copy_ctor_func (zvalue=0x839ce64, __zend_filename=0x823d6b0 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.h, __zend_lineno=45) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.c:134 #3 0x0819da97 in _zval_copy_ctor (zvalue=0x839ce64, __zend_filename=0x823d628 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend.c, __zend_lineno=1009) at zend_variables.h:45 #4 0x0819ec52 in zend_error (type=2, format=0x823d488 String is not zero-terminated (%s) (source: %s:%d)) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend.c:1009 #5 0x0819cfb9 in _zval_dtor_func (zvalue=0x84c68a4, __zend_filename=0x823c3e0 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.h, __zend_lineno=35) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.c:35 #6 0x081919cb in _zval_dtor (zvalue=0x84c68a4, __zend_filename=0x823c344 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_execute_API.c, __zend_lineno=395) at zend_variables.h:35 #7 0x08191b84 in _zval_ptr_dtor (zval_ptr=0x83e0730, __zend_filename=0x823d4bc /www/acousticdemo.com
#37061 [Opn]: Zend HashTable getting corrupted
ID: 37061 User updated by: ceo at l-i-e dot com Reported By: ceo at l-i-e dot com Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 5.3-RELEASE PHP Version: 5.1.2 New Comment: Just to keep you readers posted: Compiling --without-zend-memory-manager is easy, and it still terminates prematurely. valgrind, however, will take some time... From source yields: checking for a supported CPU/OS combination... no (i386-freebsd5.3) configure: error: Valgrind is platform specific. Sorry. Please consider doing a port. It's in the ports tree, but I'm not root, so I've asked for it to get installed. Or maybe I could convince ports tree to install it in my homedir somehow? I'll search for a way to do that. Previous Comments: [2006-04-12 22:24:09] ceo at l-i-e dot com Corrected typo of OS. Sorry. [2006-04-12 22:09:19] [EMAIL PROTECTED] 5.3-RELEASE Is it AIX 5.3 or ..? Try to build PHP with --enable-debug and --disable-zend-memory-manager and then run it through `valgrind --tool=memcheck` (see http://valgrind.org). And if you put the valgrind log somewhere in the net, that would give us a lot of useful information. Though, a short but complete reproduce script would be even better. [2006-04-12 22:03:23] ceo at l-i-e dot com Description: It's a LONG script, but it always ends up in: Zend/zend_hash.c:66 (give or take lines changed in CVS) zend_output_debug_string(1, %s(%d) : ht=%p is being cleaned, file, line, ht); and then it just quits, with no other error output. I *suspect* that the root cause is in something like this: curl_setopt($curl, CURLOPT_BINARYTRANSFER, 1); curl_setopt($curl, CURLOPT_URL, 'http://example.com/example.jpg'); $jpeg = curl_exec($curl); //ASSUME that the server bounces us around with 302s and gives: htmlheadmeta http-equiv=Refresh src=0;http://example.com/;/headbody/body/html curl_setopt($curl, CURLOPT_BINARYTRANSFER, 0); curl_setopt($curl, CURLOPT_URL, 'http://example.com'); $html = curl_exec($curl); At this point, I get warnings about $html not being zero-terminated if I try to use it, and, sure enough, it's got garbage characters at the end. I SUSPECT that the curl handle is getting forced into non-binary mode because of the 302s and the fact that plain/text comes out at the end of that -- And I SUSPECT that this somehow gets the curl handle's binary status out of sync somehow with itself, and gets curl all confused. All of this, however, is just my suspicion... It COULD be the OCR GD stuff I'm doing... But something is definitely corrupting thing somewhere. Hopefully somebody who understand backtrace better than I can track it down... Reproduce code: --- http://acousticdemo.com/info.com/overture/overture.phps http://acousticdemo.com/info.com/overture/overture.inc.phps I am happy to provide my login/password to [EMAIL PROTECTED] if you can't reproduce and want to run this from CLI under gdb and see it in action. I've already done that, and can reproduce it in gdb. It just takes awhile to get to that state, and my short scripts are not yet causing the bug. :-( Also happens in: php_5.1.2 (release) php5.1-200604071630 php5.1-200604102030 Take your pick. Expected result: Ideally, it would just work and continue on, keeping track of strings and binary strings without me worrying about it. I'd settle for an E_ERROR for conditions where a server returns plain-text instead of binary expected. Or even an E_ERROR when the strings are known to be corrupted. But a silent failure with only C errors under --with-debug is pretty harsh. Actual result: -- Silent script end prematurely under normal CLI. --with-debug and gdb get me this: #0 _zend_is_inconsistent (ht=0x83e14a4, file=0x823e6b4 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c, line=752) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c:67 #1 0x081a899f in zend_hash_copy (target=0x83e0ca4, source=0x83e14a4, pCopyConstructor=0x819d0cc zval_add_ref, tmp=0xbfbfc950, size=4) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c:752 #2 0x0819d1ed in _zval_copy_ctor_func (zvalue=0x839ce64, __zend_filename=0x823d6b0 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.h, __zend_lineno=45) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.c:134 #3 0x0819da97 in _zval_copy_ctor (zvalue=0x839ce64, __zend_filename=0x823d628 /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend.c, __zend_lineno=1009) at zend_variables.h:45 #4 0x0819ec52 in zend_error (type=2, format=0x823d488 String is not zero-terminated (%s) (source: %s:%d)) at /www/acousticdemo.com/php_cvs
#37061 [Fbk-Opn]: Zend HashTable getting corrupted
ID: 37061 User updated by: ceo at l-i-e dot com Reported By: ceo at l-i-e dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 5.3-RELEASE PHP Version: 5.1.2 New Comment: Okay. HERE is a short (35 lines) script which will yield: Warning: String is not zero-terminated I don't think the strings involved should have any problem being zero-terminated -- They are just HTML plain-text. This MAY not solve this bug, but it's an easy avenue to explore, and MAY solve the root cause of this bug, if my suspicions are correct. http://acousticdemo.com/binarytransfer.phps NOTE: You'll have to run it from CLI (or CGI) and --enable-debug to get the messages. Note that the strings ONLY get not zero-terminated if you do the CURLOPT_BINARYTRANFER part of the script. Comment out that middle section, and warnings go away. Surely this should not behave like this, right? Previous Comments: [2006-04-12 23:17:22] [EMAIL PROTECTED] No need to install it in the system or use some ports. Just grab the latest valgrind sources and compile them in your own HOME directory. IIRC latest relase compiled on FreeBSD just fine. [2006-04-12 23:06:54] ceo at l-i-e dot com Just to keep you readers posted: Compiling --without-zend-memory-manager is easy, and it still terminates prematurely. valgrind, however, will take some time... From source yields: checking for a supported CPU/OS combination... no (i386-freebsd5.3) configure: error: Valgrind is platform specific. Sorry. Please consider doing a port. It's in the ports tree, but I'm not root, so I've asked for it to get installed. Or maybe I could convince ports tree to install it in my homedir somehow? I'll search for a way to do that. [2006-04-12 22:24:09] ceo at l-i-e dot com Corrected typo of OS. Sorry. [2006-04-12 22:09:19] [EMAIL PROTECTED] 5.3-RELEASE Is it AIX 5.3 or ..? Try to build PHP with --enable-debug and --disable-zend-memory-manager and then run it through `valgrind --tool=memcheck` (see http://valgrind.org). And if you put the valgrind log somewhere in the net, that would give us a lot of useful information. Though, a short but complete reproduce script would be even better. [2006-04-12 22:03:23] ceo at l-i-e dot com Description: It's a LONG script, but it always ends up in: Zend/zend_hash.c:66 (give or take lines changed in CVS) zend_output_debug_string(1, %s(%d) : ht=%p is being cleaned, file, line, ht); and then it just quits, with no other error output. I *suspect* that the root cause is in something like this: curl_setopt($curl, CURLOPT_BINARYTRANSFER, 1); curl_setopt($curl, CURLOPT_URL, 'http://example.com/example.jpg'); $jpeg = curl_exec($curl); //ASSUME that the server bounces us around with 302s and gives: htmlheadmeta http-equiv=Refresh src=0;http://example.com/;/headbody/body/html curl_setopt($curl, CURLOPT_BINARYTRANSFER, 0); curl_setopt($curl, CURLOPT_URL, 'http://example.com'); $html = curl_exec($curl); At this point, I get warnings about $html not being zero-terminated if I try to use it, and, sure enough, it's got garbage characters at the end. I SUSPECT that the curl handle is getting forced into non-binary mode because of the 302s and the fact that plain/text comes out at the end of that -- And I SUSPECT that this somehow gets the curl handle's binary status out of sync somehow with itself, and gets curl all confused. All of this, however, is just my suspicion... It COULD be the OCR GD stuff I'm doing... But something is definitely corrupting thing somewhere. Hopefully somebody who understand backtrace better than I can track it down... Reproduce code: --- http://acousticdemo.com/info.com/overture/overture.phps http://acousticdemo.com/info.com/overture/overture.inc.phps I am happy to provide my login/password to [EMAIL PROTECTED] if you can't reproduce and want to run this from CLI under gdb and see it in action. I've already done that, and can reproduce it in gdb. It just takes awhile to get to that state, and my short scripts are not yet causing the bug. :-( Also happens in: php_5.1.2 (release) php5.1-200604071630 php5.1-200604102030 Take your pick. Expected result: Ideally, it would just work and continue on, keeping track of strings and binary strings without me worrying about it. I'd settle for an E_ERROR for conditions where a server returns plain-text instead of binary expected. Or even an E_ERROR when the strings are known to be corrupted. But a silent failure with only C errors under --with-debug
#37061 [Opn]: Zend HashTable getting corrupted
ID: 37061 User updated by: ceo at l-i-e dot com Reported By: ceo at l-i-e dot com Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 5.3-RELEASE PHP Version: 5.1.2 New Comment: Errr. To be 100% clear: The $html strings should not be non-zero-terminated. $jpeg makes perfect sense as non-zero-terminated, to me. Previous Comments: [2006-04-12 23:38:56] ceo at l-i-e dot com Okay. HERE is a short (35 lines) script which will yield: Warning: String is not zero-terminated I don't think the strings involved should have any problem being zero-terminated -- They are just HTML plain-text. This MAY not solve this bug, but it's an easy avenue to explore, and MAY solve the root cause of this bug, if my suspicions are correct. http://acousticdemo.com/binarytransfer.phps NOTE: You'll have to run it from CLI (or CGI) and --enable-debug to get the messages. Note that the strings ONLY get not zero-terminated if you do the CURLOPT_BINARYTRANFER part of the script. Comment out that middle section, and warnings go away. Surely this should not behave like this, right? [2006-04-12 23:17:22] [EMAIL PROTECTED] No need to install it in the system or use some ports. Just grab the latest valgrind sources and compile them in your own HOME directory. IIRC latest relase compiled on FreeBSD just fine. [2006-04-12 23:06:54] ceo at l-i-e dot com Just to keep you readers posted: Compiling --without-zend-memory-manager is easy, and it still terminates prematurely. valgrind, however, will take some time... From source yields: checking for a supported CPU/OS combination... no (i386-freebsd5.3) configure: error: Valgrind is platform specific. Sorry. Please consider doing a port. It's in the ports tree, but I'm not root, so I've asked for it to get installed. Or maybe I could convince ports tree to install it in my homedir somehow? I'll search for a way to do that. [2006-04-12 22:24:09] ceo at l-i-e dot com Corrected typo of OS. Sorry. [2006-04-12 22:09:19] [EMAIL PROTECTED] 5.3-RELEASE Is it AIX 5.3 or ..? Try to build PHP with --enable-debug and --disable-zend-memory-manager and then run it through `valgrind --tool=memcheck` (see http://valgrind.org). And if you put the valgrind log somewhere in the net, that would give us a lot of useful information. Though, a short but complete reproduce script would be even better. 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/37061 -- Edit this bug report at http://bugs.php.net/?id=37061edit=1
#37061 [Fbk-Opn]: Zend HashTable getting corrupted
ID: 37061 User updated by: ceo at l-i-e dot com Reported By: ceo at l-i-e dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 5.3-RELEASE PHP Version: 5.1.2 New Comment: Jeez, I'm fumbling today. http://acousticdemo.com/info.com/overture/binarytransfer.phps Previous Comments: [2006-04-13 00:05:57] [EMAIL PROTECTED] 404 not found... [2006-04-12 23:47:48] ceo at l-i-e dot com Errr. To be 100% clear: The $html strings should not be non-zero-terminated. $jpeg makes perfect sense as non-zero-terminated, to me. [2006-04-12 23:38:56] ceo at l-i-e dot com Okay. HERE is a short (35 lines) script which will yield: Warning: String is not zero-terminated I don't think the strings involved should have any problem being zero-terminated -- They are just HTML plain-text. This MAY not solve this bug, but it's an easy avenue to explore, and MAY solve the root cause of this bug, if my suspicions are correct. http://acousticdemo.com/binarytransfer.phps NOTE: You'll have to run it from CLI (or CGI) and --enable-debug to get the messages. Note that the strings ONLY get not zero-terminated if you do the CURLOPT_BINARYTRANFER part of the script. Comment out that middle section, and warnings go away. Surely this should not behave like this, right? [2006-04-12 23:17:22] [EMAIL PROTECTED] No need to install it in the system or use some ports. Just grab the latest valgrind sources and compile them in your own HOME directory. IIRC latest relase compiled on FreeBSD just fine. [2006-04-12 23:06:54] ceo at l-i-e dot com Just to keep you readers posted: Compiling --without-zend-memory-manager is easy, and it still terminates prematurely. valgrind, however, will take some time... From source yields: checking for a supported CPU/OS combination... no (i386-freebsd5.3) configure: error: Valgrind is platform specific. Sorry. Please consider doing a port. It's in the ports tree, but I'm not root, so I've asked for it to get installed. Or maybe I could convince ports tree to install it in my homedir somehow? I'll search for a way to do that. 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/37061 -- Edit this bug report at http://bugs.php.net/?id=37061edit=1
#37005 [Asn]: munged JPEG + imagecreatefromstring segfault
ID: 37005
User updated by: ceo at l-i-e dot com
Reported By: ceo at l-i-e dot com
Status: Assigned
Bug Type: GD related
Operating System: FreeBSD o11.hostbaby.com 5.3-REL
PHP Version: 5.1.2
Assigned To: pajoye
New Comment:
On Tue, April 11, 2006 7:45 am, Pierre wrote:
On Mon, 10 Apr 2006 20:20:04 -0500 (CDT)
Richard Lynch [EMAIL PROTECTED] wrote:
Just FYI:
Some progress...
A snap from today (php5.1-200604102030) doesn't segfault, per se...
But it ends up doing this sometimes, in my monster script:
/www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c(752)
: ht=0x83e20a4 is being cleaned
I also get a lot of string not zero-terminated warnings, but that
may be expected when one calls stristr or file_put_contents on a
binary string (a JPEG string suitable input for
imagecreatefromstring)
If I'm reading PHP source code correctly, that ht %p is begin
cleaned is followed immediately by a call to zend_bailout()
If that means what I think it does, it might explain why my script
is
just sort of ending without much else in the way of error
messages...
I know we're probably now long out of the GD section of PHP, so I'm
trying through PHP-Dev for now...
Keep it in a bug report is actually the best way.
I'll be cc-ing this into the bug report, then.
But wanted to let you know things are not quite copascetic, in case
it
really was something in the guts of GD scrambling memory?
The acousticdemo.com username/password remain available
indefinitely,
if it's useful.
But I can only generate this problem now with a rather large
script :-(
Which one? The problem in overture.php?
Yes.
It it now reaches a point where it (usually) prints out:
ht=0x012345678 is being clean
and then it just sort of ends, with no error message at all.
My previous example with php -a and the sample (corrupt) image no
longer crashes at script end.
So this problem is solved. Or d
Truthfully, it seems more like it's been moved to a different section
of code, at least to me...
But my real script doesn't work any better, really.
cd web/info.com/overture/
~/php_cvs/php5.1-200604102030/sapi/cli/php overture.php out.txt
Data used in the script is stored in pages/ for review if that
helps
any.
Attempts so far to reproduce the bug now with small scripts have
failed miserably. :-(
What does not work?
It code simply ends without running to completion, with no error
messages, or with the ht %p being cleaned error message, which, in
PHP CVS source, is immediately followed by a call to 'zend_bailout()'
That looks bad to this naive reader. :-)
What is this exec call at the top of your script?
That's just a hack to not run the script 2 times at once, if it runs
very long time and then cron calls it again.
Unless you are testing 2 processes of the script in parallel (don't do
that) you can just ignore it. Or I'll rip it out, since I should use a
lock file, really.
What does exactly this script? A short explanation should help to
catch
the problem.
curl reads a page that has a CAPTCHA on it
curl reads the JPEG with CURLOPT_BINARYTRANSFER (right?)
OCR the CAPTCHA:
imagecreatefromstring()
de-noise
down-sample to black/white
convert to ASCII art pixel-by-pixel imagecolorat
compute min distance from known characters in 'dictionary'
(known characters are also ASCII art)
POST back the guess of the CAPTCHA
It's pretty much an anti-CAPTCHA hack...
Previous Comments:
[2006-04-08 21:52:03] ceo at l-i-e dot com
Yes, I am using the PHP CGI I personally compiled.
/www/acousticdemo.com/php_cvs/php5.1-200604071630/usr/local/bin/php -a
is what I did to test
/www/acousticdemo.com/php_cvs/php5.1-200604071630/usr/local/bin/php -v
yields:
PHP 5.1.3RC3 (cgi) (built: Apr 7 2006 19:23:50) (DEBUG)
-m shows:
curl
date
gd
libxml
pcre
Reflection
SPL
standard
zlib
-i | grep GD yields:
GD Support enabled
GD Version bundled (2.0.28 compatible)
I can call imagecreatefromjpeg() and imagejpeg() but it segfaults when
I hit ^D to exit the script.
I have also tested 5.1.2 (from php.net/downloads.php) and it has the
same issues.
My webhost has 5.0.4 installed from the ports, so there's no way I'm
running his when it say 5.1.3RC3 for -v
[2006-04-07 18:44:17] [EMAIL PROTECTED]
Sorry, but it is confusing.
Give this snippet:
$image = imagecreatefromjpeg('088b1cc1662339d5008fd3d67ec7cf01.jpg');
imagejpeg($image);
Did you try it on freebsd using the PHP sources and not the BSD ports?
The backtrace has nothing to do with GD or the image functions. Please
confirm that you use the PHP sources and the bundled GD and not the BSD
ports.
[2006-04-07 18:35:57] ceo at l-i-e dot com
Yes, in fact, I *CAN* stumble my
#37005 [Fbk-Opn]: munged JPEG + imagecreatefromstring segfault
ID: 37005
User updated by: ceo at l-i-e dot com
Reported By: ceo at l-i-e dot com
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: FreeBSD o11.hostbaby.com 5.3-REL
PHP Version: 5.1.2
Assigned To: pajoye
New Comment:
Yes, I am using the PHP CGI I personally compiled.
/www/acousticdemo.com/php_cvs/php5.1-200604071630/usr/local/bin/php -a
is what I did to test
/www/acousticdemo.com/php_cvs/php5.1-200604071630/usr/local/bin/php -v
yields:
PHP 5.1.3RC3 (cgi) (built: Apr 7 2006 19:23:50) (DEBUG)
-m shows:
curl
date
gd
libxml
pcre
Reflection
SPL
standard
zlib
-i | grep GD yields:
GD Support enabled
GD Version bundled (2.0.28 compatible)
I can call imagecreatefromjpeg() and imagejpeg() but it segfaults when
I hit ^D to exit the script.
I have also tested 5.1.2 (from php.net/downloads.php) and it has the
same issues.
My webhost has 5.0.4 installed from the ports, so there's no way I'm
running his when it say 5.1.3RC3 for -v
Previous Comments:
[2006-04-07 18:44:17] [EMAIL PROTECTED]
Sorry, but it is confusing.
Give this snippet:
$image = imagecreatefromjpeg('088b1cc1662339d5008fd3d67ec7cf01.jpg');
imagejpeg($image);
Did you try it on freebsd using the PHP sources and not the BSD ports?
The backtrace has nothing to do with GD or the image functions. Please
confirm that you use the PHP sources and the bundled GD and not the BSD
ports.
[2006-04-07 18:35:57] ceo at l-i-e dot com
Yes, in fact, I *CAN* stumble my way through a backtrace.
This GDB was configured as i386-marcel-freebsd...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.2...done.
Loaded symbols for /lib/libcrypt.so.2
Reading symbols from /usr/local/lib/libpng.so.5...done.
Loaded symbols for /usr/local/lib/libpng.so.5
Reading symbols from /lib/libz.so.2...done.
Loaded symbols for /lib/libz.so.2
Reading symbols from /usr/local/lib/libjpeg.so.9...done.
Loaded symbols for /usr/local/lib/libjpeg.so.9
Reading symbols from /lib/libm.so.3...done.
Loaded symbols for /lib/libm.so.3
Reading symbols from /usr/local/lib/libxml2.so.5...done.
Loaded symbols for /usr/local/lib/libxml2.so.5
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x08164cd1 in execute (op_array=0x832700c) at zend_vm_execute.h:92
#2 0x0814d652 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at
/www/acousticdemo.com/php_cvs/php5.1-200604071630/Zend/zend.c:1109
#3 0x081199c4 in php_execute_script (primary_file=0xbfbfeb80) at
/www/acousticdemo.com/php_cvs/php5.1-200604071630/main/main.c:1728
#4 0x081c621b in main (argc=2, argv=0xbfbfec10) at
/www/acousticdemo.com/php_cvs/php5.1-200604071630/sapi/cgi/cgi_main.c:1603
[2006-04-07 18:27:14] ceo at l-i-e dot com
I was using this file as my test input:
088b1cc1662339d5008fd3d67ec7cf01.jpg
Note that it DOES output the image okay now, or, at least, it looks
okay in a browser, but a core dump happens when you try to exit PHP
with EOF (^D).
Sample code:
?php $image =
imagecreatefromjpeg('088b1cc1662339d5008fd3d67ec7cf01.jpg');?
?php imagejpeg($image, 'cvs2.jpg');?
Using 5.1.2 (not snapshot) on Windows, I got messages similar to what
you see.
C: php -v
PHP 5.1.2 (cli) (built: Jan 11 2006 16:40:00)
This MAY be specific to FreeBSD, then...
[2006-04-07 18:22:52] ceo at l-i-e dot com
Progress.
Using the snapshot and its bundled GD.
I can now create the JPEG from the corrupted file, which is way more
than I expected, honestly.
I can also do imagejpeg($image, 'cvs1.jpg') and get it out.
But, then, as soon as I ^D to get out of the interpreter, it
core-dumped on me...
This was repeatable, twice in a row.
You can find the images, the cvs-generated images, and the core dumps
here:
http://www.acousticdemo.com/info.com/overture/jpeg_crashed/
I dunno if core dumps can be used across machines, but I could maybe
stumble my way through a backtrace thingie, if it would help...
[2006-04-07 12:41:10] [EMAIL PROTECTED]
If the segfault still occurs using the CVS snapshot, please provide a
script with one or many images to reproduce the segfauls. CURL or any
other things are not GD related and will not be considered in this
bug.
However I tried your images and it is correctly proceeded:
Processing: 7512e7d01fc3894e106ca66db2d36064
#37005 [Fbk-Opn]: munged JPEG + imagecreatefromstring segfault
ID: 37005 User updated by: ceo at l-i-e dot com Reported By: ceo at l-i-e dot com -Status: Feedback +Status: Open Bug Type: GD related Operating System: FreeBSD o11.hostbaby.com 5.3-REL PHP Version: 5.1.2 Assigned To: pajoye New Comment: Progress. Using the snapshot and its bundled GD. I can now create the JPEG from the corrupted file, which is way more than I expected, honestly. I can also do imagejpeg($image, 'cvs1.jpg') and get it out. But, then, as soon as I ^D to get out of the interpreter, it core-dumped on me... This was repeatable, twice in a row. You can find the images, the cvs-generated images, and the core dumps here: http://www.acousticdemo.com/info.com/overture/jpeg_crashed/ I dunno if core dumps can be used across machines, but I could maybe stumble my way through a backtrace thingie, if it would help... Previous Comments: [2006-04-07 12:41:10] [EMAIL PROTECTED] If the segfault still occurs using the CVS snapshot, please provide a script with one or many images to reproduce the segfauls. CURL or any other things are not GD related and will not be considered in this bug. However I tried your images and it is correctly proceeded: Processing: 7512e7d01fc3894e106ca66db2d36064.jpg Warning: imagecreatefromstring(): Data is not in a recognized format in /home/pierre/projects/php/37005/37005.php on line .. [2006-04-07 08:34:57] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2006-04-07 05:28:24] ceo at l-i-e dot com Description: This *MAY* be the same as the bug fixed by the new GD functions, what with GD free-ing RAM that PHP had allocated, but I suspect it is not... Suppose a user is naive enough to not use CURLOPT_BINARYTRANSFER when using curl to get an image. Suppose they then pass that image string into imagecreatefromstring() Then that user will get a segfault, most of the time. Though not always. Granted, this is pretty dumb thing to do, once you understand what CURLOPT_BINARYTRANSFER is for in the first place. But, before you grok that, it's a pretty common mistake. Or, even if you understood it, but somehow mis-coded, or forgot it the next time you wrote some similar code, you end up with segfaults. And common mistakes, in an ideal world, should not segfault, but should produce an E_ERROR (or similar). Reproduce code: --- The original code was your basic: [Untested, really, but...] ?php $curl = curl_init(); curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1); curl_setopt($curl, CURLOPT_URL, 'http://bugs.php.net/gifs/logo-bug.gif'); $image_string = curl_exec($curl); $image = imagecreatefromstring($image_string); ? It may be JPEG only, so you'd need to try different images instead of the self-referenctial GIF from this page. However, you may find it easier to just snag this jpeg: http://acousticdemo.com/info.com/overture/jpeg_crashed/088b1cc1662339d5008fd3d67ec7cf01.jpg which I saved from the above, and work with it. If you simply snag that, and do: ?php imagecreatefromstring($YOURFILE);? it will segfault. I can do it from the command line every time with that file. Yes, it *IS* a corrupt JPEG, almost for sure. But I'm hoping it's corrupt in a detectable way, if you know what I mean, and we can change the 'segfault' behaviour into E_ERROR behaviour. Mozilla seems quite content to display a rendering which looks right even for that corrupt image, which gives me hope that it is a detectable error -- but also makes debugging quite difficult, since you have an image that looks right but that PHP segfaults on, every time. Here are some more sample (corrupt) images, for your convenience for testing: http://acousticdemo.com/info.com/overture/jpeg_crashed/ Expected result: I expected E_ERROR for an invalid JPEG. I don't expect it to fix the image the way the browsers do, though. The scripter should be educated via E_ERROR to fix their code, rather than have PHP fix it for, say, JPEGs, but then it fails for any custom proprietary binary data. Actual result: -- segfault -- Edit this bug report at http://bugs.php.net/?id=37005edit=1
#37005 [Opn]: munged JPEG + imagecreatefromstring segfault
ID: 37005
User updated by: ceo at l-i-e dot com
Reported By: ceo at l-i-e dot com
Status: Open
Bug Type: GD related
Operating System: FreeBSD o11.hostbaby.com 5.3-REL
PHP Version: 5.1.2
Assigned To: pajoye
New Comment:
I was using this file as my test input:
088b1cc1662339d5008fd3d67ec7cf01.jpg
Note that it DOES output the image okay now, or, at least, it looks
okay in a browser, but a core dump happens when you try to exit PHP
with EOF (^D).
Sample code:
?php $image =
imagecreatefromjpeg('088b1cc1662339d5008fd3d67ec7cf01.jpg');?
?php imagejpeg($image, 'cvs2.jpg');?
Using 5.1.2 (not snapshot) on Windows, I got messages similar to what
you see.
C: php -v
PHP 5.1.2 (cli) (built: Jan 11 2006 16:40:00)
This MAY be specific to FreeBSD, then...
Previous Comments:
[2006-04-07 18:22:52] ceo at l-i-e dot com
Progress.
Using the snapshot and its bundled GD.
I can now create the JPEG from the corrupted file, which is way more
than I expected, honestly.
I can also do imagejpeg($image, 'cvs1.jpg') and get it out.
But, then, as soon as I ^D to get out of the interpreter, it
core-dumped on me...
This was repeatable, twice in a row.
You can find the images, the cvs-generated images, and the core dumps
here:
http://www.acousticdemo.com/info.com/overture/jpeg_crashed/
I dunno if core dumps can be used across machines, but I could maybe
stumble my way through a backtrace thingie, if it would help...
[2006-04-07 12:41:10] [EMAIL PROTECTED]
If the segfault still occurs using the CVS snapshot, please provide a
script with one or many images to reproduce the segfauls. CURL or any
other things are not GD related and will not be considered in this
bug.
However I tried your images and it is correctly proceeded:
Processing: 7512e7d01fc3894e106ca66db2d36064.jpg
Warning: imagecreatefromstring(): Data is not in a recognized format in
/home/pierre/projects/php/37005/37005.php on line ..
[2006-04-07 08:34:57] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-04-07 05:28:24] ceo at l-i-e dot com
Description:
This *MAY* be the same as the bug fixed by the new GD functions, what
with GD free-ing RAM that PHP had allocated, but I suspect it is
not...
Suppose a user is naive enough to not use CURLOPT_BINARYTRANSFER when
using curl to get an image.
Suppose they then pass that image string into imagecreatefromstring()
Then that user will get a segfault, most of the time.
Though not always.
Granted, this is pretty dumb thing to do, once you understand what
CURLOPT_BINARYTRANSFER is for in the first place.
But, before you grok that, it's a pretty common mistake.
Or, even if you understood it, but somehow mis-coded, or forgot it the
next time you wrote some similar code, you end up with segfaults.
And common mistakes, in an ideal world, should not segfault, but should
produce an E_ERROR (or similar).
Reproduce code:
---
The original code was your basic:
[Untested, really, but...]
?php
$curl = curl_init();
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curl, CURLOPT_URL,
'http://bugs.php.net/gifs/logo-bug.gif');
$image_string = curl_exec($curl);
$image = imagecreatefromstring($image_string);
?
It may be JPEG only, so you'd need to try different images instead of
the self-referenctial GIF from this page.
However, you may find it easier to just snag this jpeg:
http://acousticdemo.com/info.com/overture/jpeg_crashed/088b1cc1662339d5008fd3d67ec7cf01.jpg
which I saved from the above, and work with it.
If you simply snag that, and do:
?php imagecreatefromstring($YOURFILE);?
it will segfault.
I can do it from the command line every time with that file.
Yes, it *IS* a corrupt JPEG, almost for sure.
But I'm hoping it's corrupt in a detectable way, if you know what I
mean, and we can change the 'segfault' behaviour into E_ERROR
behaviour.
Mozilla seems quite content to display a rendering which looks right
even for that corrupt image, which gives me hope that it is a
detectable error -- but also makes debugging quite difficult, since you
have an image that looks right but that PHP segfaults on, every time.
Here are some more sample (corrupt) images, for your convenience for
testing:
http://acousticdemo.com/info.com/overture/jpeg_crashed/
Expected result:
I expected E_ERROR for an invalid JPEG.
I don't expect it to fix the image the way the browsers do, though.
The scripter should be educated via E_ERROR to fix their code, rather
than have PHP fix it for, say, JPEGs
#37005 [Opn]: munged JPEG + imagecreatefromstring segfault
ID: 37005
User updated by: ceo at l-i-e dot com
Reported By: ceo at l-i-e dot com
Status: Open
Bug Type: GD related
Operating System: FreeBSD o11.hostbaby.com 5.3-REL
PHP Version: 5.1.2
Assigned To: pajoye
New Comment:
Yes, in fact, I *CAN* stumble my way through a backtrace.
This GDB was configured as i386-marcel-freebsd...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.2...done.
Loaded symbols for /lib/libcrypt.so.2
Reading symbols from /usr/local/lib/libpng.so.5...done.
Loaded symbols for /usr/local/lib/libpng.so.5
Reading symbols from /lib/libz.so.2...done.
Loaded symbols for /lib/libz.so.2
Reading symbols from /usr/local/lib/libjpeg.so.9...done.
Loaded symbols for /usr/local/lib/libjpeg.so.9
Reading symbols from /lib/libm.so.3...done.
Loaded symbols for /lib/libm.so.3
Reading symbols from /usr/local/lib/libxml2.so.5...done.
Loaded symbols for /usr/local/lib/libxml2.so.5
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x08164cd1 in execute (op_array=0x832700c) at zend_vm_execute.h:92
#2 0x0814d652 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at
/www/acousticdemo.com/php_cvs/php5.1-200604071630/Zend/zend.c:1109
#3 0x081199c4 in php_execute_script (primary_file=0xbfbfeb80) at
/www/acousticdemo.com/php_cvs/php5.1-200604071630/main/main.c:1728
#4 0x081c621b in main (argc=2, argv=0xbfbfec10) at
/www/acousticdemo.com/php_cvs/php5.1-200604071630/sapi/cgi/cgi_main.c:1603
Previous Comments:
[2006-04-07 18:27:14] ceo at l-i-e dot com
I was using this file as my test input:
088b1cc1662339d5008fd3d67ec7cf01.jpg
Note that it DOES output the image okay now, or, at least, it looks
okay in a browser, but a core dump happens when you try to exit PHP
with EOF (^D).
Sample code:
?php $image =
imagecreatefromjpeg('088b1cc1662339d5008fd3d67ec7cf01.jpg');?
?php imagejpeg($image, 'cvs2.jpg');?
Using 5.1.2 (not snapshot) on Windows, I got messages similar to what
you see.
C: php -v
PHP 5.1.2 (cli) (built: Jan 11 2006 16:40:00)
This MAY be specific to FreeBSD, then...
[2006-04-07 18:22:52] ceo at l-i-e dot com
Progress.
Using the snapshot and its bundled GD.
I can now create the JPEG from the corrupted file, which is way more
than I expected, honestly.
I can also do imagejpeg($image, 'cvs1.jpg') and get it out.
But, then, as soon as I ^D to get out of the interpreter, it
core-dumped on me...
This was repeatable, twice in a row.
You can find the images, the cvs-generated images, and the core dumps
here:
http://www.acousticdemo.com/info.com/overture/jpeg_crashed/
I dunno if core dumps can be used across machines, but I could maybe
stumble my way through a backtrace thingie, if it would help...
[2006-04-07 12:41:10] [EMAIL PROTECTED]
If the segfault still occurs using the CVS snapshot, please provide a
script with one or many images to reproduce the segfauls. CURL or any
other things are not GD related and will not be considered in this
bug.
However I tried your images and it is correctly proceeded:
Processing: 7512e7d01fc3894e106ca66db2d36064.jpg
Warning: imagecreatefromstring(): Data is not in a recognized format in
/home/pierre/projects/php/37005/37005.php on line ..
[2006-04-07 08:34:57] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-04-07 05:28:24] ceo at l-i-e dot com
Description:
This *MAY* be the same as the bug fixed by the new GD functions, what
with GD free-ing RAM that PHP had allocated, but I suspect it is
not...
Suppose a user is naive enough to not use CURLOPT_BINARYTRANSFER when
using curl to get an image.
Suppose they then pass that image string into imagecreatefromstring()
Then that user will get a segfault, most of the time.
Though not always.
Granted, this is pretty dumb thing to do, once you understand what
CURLOPT_BINARYTRANSFER is for in the first place.
But, before you grok that, it's a pretty common mistake.
Or, even if you understood it, but somehow mis-coded, or forgot it the
next time you wrote some similar code, you end up with segfaults.
And common mistakes, in an ideal world, should not segfault, but should
produce an E_ERROR
#37005 [NEW]: munged JPEG + imagecreatefromstring segfault
From: ceo at l-i-e dot com Operating system: FreeBSD o11.hostbaby.com 5.3-REL PHP version: 5.1.2 PHP Bug Type: GD related Bug description: munged JPEG + imagecreatefromstring segfault Description: This *MAY* be the same as the bug fixed by the new GD functions, what with GD free-ing RAM that PHP had allocated, but I suspect it is not... Suppose a user is naive enough to not use CURLOPT_BINARYTRANSFER when using curl to get an image. Suppose they then pass that image string into imagecreatefromstring() Then that user will get a segfault, most of the time. Though not always. Granted, this is pretty dumb thing to do, once you understand what CURLOPT_BINARYTRANSFER is for in the first place. But, before you grok that, it's a pretty common mistake. Or, even if you understood it, but somehow mis-coded, or forgot it the next time you wrote some similar code, you end up with segfaults. And common mistakes, in an ideal world, should not segfault, but should produce an E_ERROR (or similar). Reproduce code: --- The original code was your basic: [Untested, really, but...] ?php $curl = curl_init(); curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1); curl_setopt($curl, CURLOPT_URL, 'http://bugs.php.net/gifs/logo-bug.gif'); $image_string = curl_exec($curl); $image = imagecreatefromstring($image_string); ? It may be JPEG only, so you'd need to try different images instead of the self-referenctial GIF from this page. However, you may find it easier to just snag this jpeg: http://acousticdemo.com/info.com/overture/jpeg_crashed/088b1cc1662339d5008fd3d67ec7cf01.jpg which I saved from the above, and work with it. If you simply snag that, and do: ?php imagecreatefromstring($YOURFILE);? it will segfault. I can do it from the command line every time with that file. Yes, it *IS* a corrupt JPEG, almost for sure. But I'm hoping it's corrupt in a detectable way, if you know what I mean, and we can change the 'segfault' behaviour into E_ERROR behaviour. Mozilla seems quite content to display a rendering which looks right even for that corrupt image, which gives me hope that it is a detectable error -- but also makes debugging quite difficult, since you have an image that looks right but that PHP segfaults on, every time. Here are some more sample (corrupt) images, for your convenience for testing: http://acousticdemo.com/info.com/overture/jpeg_crashed/ Expected result: I expected E_ERROR for an invalid JPEG. I don't expect it to fix the image the way the browsers do, though. The scripter should be educated via E_ERROR to fix their code, rather than have PHP fix it for, say, JPEGs, but then it fails for any custom proprietary binary data. Actual result: -- segfault -- Edit bug report at http://bugs.php.net/?id=37005edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37005r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37005r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37005r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37005r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37005r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37005r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37005r=needscript Try newer version:http://bugs.php.net/fix.php?id=37005r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37005r=support Expected behavior:http://bugs.php.net/fix.php?id=37005r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37005r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37005r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37005r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37005r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37005r=dst IIS Stability:http://bugs.php.net/fix.php?id=37005r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37005r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37005r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37005r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37005r=mysqlcfg
#36138 [NEW]: utf8_decode fails ; UTF-8 headers work
From: ceo at l-i-e dot com Operating system: FreeBSD 5.3 PHP version: 4.4.2 PHP Bug Type: *Languages/Translation Bug description: utf8_decode fails ; UTF-8 headers work Description: I'm not an expert in multi-lingual character encoding sets stuff, but... This version uses PHP's utf8_decode, and I get funky useless characters: http://acousticdemo.com/info.com/answers/answers.php?qkw=Catherine+de+Mediciutf8_decode=1 This version sends a charset UTF-8 header (Mozilla based) and a META charset UTF-8 (MS IE) and it works: http://acousticdemo.com/info.com/answers/answers.php?qkw=Catherine+de+Medici This was actually in 4.4.0 and also in 5.0.4, so it MIGHT be fixed in CVS -- but I have no control over the versions of PHP on the servers involved, and am unlikely to have such control in the future... Best I can do, sorry. Reproduce code: --- http://acousticdemo.com/info.com/answers/answers.phps You will not, however, be able to run the code on your own box, because your IP isn't allowed to get that content... I can maybe hook you up with Answers.com, or I can do whatever it takes to get you the raw data for this one page, or... Expected result: I expected PHP's UTF8 decoding function to work as well as the browser's. Actual result: -- I get a lot of funky characters that just aren't right. I can't guarantee that it's not the data that is bad, but the browser is handling it, so... -- Edit bug report at http://bugs.php.net/?id=36138edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36138r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36138r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36138r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36138r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36138r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36138r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36138r=needscript Try newer version:http://bugs.php.net/fix.php?id=36138r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36138r=support Expected behavior:http://bugs.php.net/fix.php?id=36138r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36138r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36138r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36138r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36138r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36138r=dst IIS Stability:http://bugs.php.net/fix.php?id=36138r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36138r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36138r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36138r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36138r=mysqlcfg
#36072 [NEW]: stream_set_connection_timeout()
From: ceo at l-i-e dot com
Operating system: All
PHP version: 5.1.2
PHP Bug Type: Feature/Change Request
Bug description: stream_set_connection_timeout()
Description:
I love the simplicity of fopen() that takes most URLs / files / whatever
and does what I want.
Do whatever it takes to start sending me the data.
I NEED the ability to set the time-out for the opening, as well as the
time-out after the stream has opened.
I'm stuck with duplicating whatever code is down in fopen() in my own PHP
code to detect and initiate protocol specific minutia because fopen() has
no user-configurable timeout, but fsockopen doesn't do all that.
$parts = parse_url($url);
extract($parts);
switch($scheme){
case 'http': fputs(GET $path HTTP/1.0\n); fputs(Host: $host\n);
break;
case 'ftp': fputs(GET $path\n); break;
.
.
.
}
I REALLY don't want to re-invent the wheel here, when I know that code is
down in the guts of fopen()
A function stream_set_connection_timeout() to let me tell PHP how long
fopen() should wait would make life way more better for many users, I
believe.
Expected result:
The PHP Dev Team is going to add this function because YOU ROCK!
:-)
--
Edit bug report at http://bugs.php.net/?id=36072edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36072r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36072r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36072r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36072r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36072r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36072r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36072r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36072r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36072r=support
Expected behavior:http://bugs.php.net/fix.php?id=36072r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36072r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36072r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36072r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36072r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36072r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36072r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36072r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36072r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36072r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36072r=mysqlcfg
#36072 [Bgs-Opn]: stream_set_connection_timeout()
ID: 36072
User updated by: ceo at l-i-e dot com
Reported By: ceo at l-i-e dot com
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: *
PHP Version: *
New Comment:
E. If you read the actual Feature Request, I think it's pretty
clear that RTFM stream_set_timeout won't cut it...
stream_set_timeout is useful only AFTER a stream is open.
fopen() gives no control (tho fsockopen() does) over connection
timeout.
But fsockopen is missing all the great stuff in fopen() that takes care
of.
I really don't think I'm being an idiot here... Honest.
Previous Comments:
[2006-01-18 21:24:49] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
RTFM: stream_set_timeout(), context of fopen(), streams section in
manual
[2006-01-18 21:16:55] ceo at l-i-e dot com
Description:
I love the simplicity of fopen() that takes most URLs / files /
whatever and does what I want.
Do whatever it takes to start sending me the data.
I NEED the ability to set the time-out for the opening, as well as the
time-out after the stream has opened.
I'm stuck with duplicating whatever code is down in fopen() in my own
PHP code to detect and initiate protocol specific minutia because
fopen() has no user-configurable timeout, but fsockopen doesn't do all
that.
$parts = parse_url($url);
extract($parts);
switch($scheme){
case 'http': fputs(GET $path HTTP/1.0\n); fputs(Host: $host\n);
break;
case 'ftp': fputs(GET $path\n); break;
.
.
.
}
I REALLY don't want to re-invent the wheel here, when I know that code
is down in the guts of fopen()
A function stream_set_connection_timeout() to let me tell PHP how long
fopen() should wait would make life way more better for many users, I
believe.
Expected result:
The PHP Dev Team is going to add this function because YOU ROCK!
:-)
--
Edit this bug report at http://bugs.php.net/?id=36072edit=1
#33267 [Bgs-Opn]: DES_CRYPTED_LENGTH
ID: 33267 User updated by: ceo at l-i-e dot com Reported By: ceo at l-i-e dot com -Status: Bogus +Status: Open -Bug Type: Documentation problem +Bug Type: Feature/Change Request Operating System: All -PHP Version: Irrelevant +PHP Version: PHP 5.1 New Comment: Sorry! I must have missed the menu selection by a one-off error... It's definitely a Feature Request, not Documentation. Previous Comments: [2005-06-08 00:02:55] [EMAIL PROTECTED] This sort of thing doesn't belong in the PHP docs. [2005-06-07 23:40:48] ceo at l-i-e dot com Description: It would be Really Nifty if there were constants for the output lengths of the various CRYPT algorithms. EG: MD5_CRYPTED_LENGTH 32 Cuz I can never remember how long the various crypt thingies go, and I always need to build the table to hold them, so I spend an hour digging around for the number I need. -- Edit this bug report at http://bugs.php.net/?id=33267edit=1
#32496 [Bgs]: Session string values are references
ID: 32496
User updated by: ceo at l-i-e dot com
Reported By: ceo at l-i-e dot com
Status: Bogus
Bug Type: Session related
Operating System: FreeBSD 5.3-RELEASE
PHP Version: 5.0.3
New Comment:
Fixed in CVS, I guess.
Others have confirmed the bug in 5.0.3 on non FreeBSD platforms.
Previous Comments:
[2005-03-30 07:25:38] [EMAIL PROTECTED]
Using latest CVS + register_globals = Off - Works just fine.
[2005-03-30 05:23:22] ceo at l-i-e dot com
Description:
?php
session_start();
if (!isset($_SESSION['name'])){
$_SESSION['name'] = 'Richard Lynch';
}
else{
$name = $_SESSION['name'];
}
/* Assume a ton of code goes here */
$name = 'Fooey';
echo Session name is: , $_SESSION['name'], br /\n;
?
Now, hit this page, re-load it, and what do *YOU* expect
$_SESSION['name'] to output?
A) 'Richard Lynch', because you never re-assigned $_SESSION['name']
B) 'Fooey' because $name is a reference, and you changed it, so that
changed your session data.
*I* expected A)
Alas, the reality is B)
--
Edit this bug report at http://bugs.php.net/?id=32496edit=1
#32496 [NEW]: Session string values are references
From: ceo at l-i-e dot com
Operating system: FreeBSD 5.3-RELEASE
PHP version: 5.0.3
PHP Bug Type: Session related
Bug description: Session string values are references
Description:
?php
session_start();
if (!isset($_SESSION['name'])){
$_SESSION['name'] = 'Richard Lynch';
}
else{
$name = $_SESSION['name'];
}
/* Assume a ton of code goes here */
$name = 'Fooey';
echo Session name is: , $_SESSION['name'], br /\n;
?
Now, hit this page, re-load it, and what do *YOU* expect $_SESSION['name']
to output?
A) 'Richard Lynch', because you never re-assigned $_SESSION['name']
B) 'Fooey' because $name is a reference, and you changed it, so that
changed your session data.
*I* expected A)
Alas, the reality is B)
--
Edit bug report at http://bugs.php.net/?id=32496edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32496r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32496r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32496r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32496r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32496r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32496r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32496r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32496r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32496r=support
Expected behavior: http://bugs.php.net/fix.php?id=32496r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32496r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32496r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32496r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32496r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32496r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32496r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32496r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32496r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32496r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32496r=mysqlcfg
#31905 [NEW]: Memory Limit bypasses set_error_handler
From: ceo at l-i-e dot com
Operating system: FreeBSD 4.10-STABLE
PHP version: 4.3.10
PHP Bug Type: *Programming Data Structures
Bug description: Memory Limit bypasses set_error_handler
Description:
set_error_handle seems totally ineffective for Memory Limit settings.
Reproduce code:
---
ini_set('memory_limit', '32K');
ini_set('error_reporting', 0);
echo Memory Limit: , ini_get('memory_limit'), \n;
echo Memory Used: , memory_get_usage(), \n;
function error_handler($error, $message, $file, $line){
echo Error ($error) in $file:$line - $message\n;
return true;
}
set_error_handler('error_handler');
trigger_error(Test, E_USER_NOTICE);
$str = str_repeat('a', 1024);
while (true){
echo '.';
flush();
$str .= $str;
}
echo \nMade it!\n;
Expected result:
I expected to see the same error message PHP usually reports, more or
less, and then Made it!.
Actual result:
--
-bash-2.05b$ php test.php
Content-type: text/html
X-Powered-By: PHP/4.3.10
Memory Limit: 32K
Memory Used: 13432
Error (1024) in /www/l-i-e.com/web/test.php:12 - Test
-bash-2.05b$
Note that my test error message comes out, and PHP continues, but upon
reaching memory limit, it just dies, with no call to my error handler.
:-(
I'm not sure that a soft limit imposed should necessarily be considered
non-recoverable...
Though I can see how even trying to call the function at that point is
problematic, in terms of not triggering the error again in an infinite
loop...
Still, it would be nice to be able to trap this and do something useful
rather than just die, if possible.
--
Edit bug report at http://bugs.php.net/?id=31905edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31905r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31905r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31905r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31905r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31905r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31905r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31905r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31905r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31905r=support
Expected behavior: http://bugs.php.net/fix.php?id=31905r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31905r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31905r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31905r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31905r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31905r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31905r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31905r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31905r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31905r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31905r=mysqlcfg
#31391 [Opn]: phpinfo - Apache up-time
ID: 31391
User updated by: ceo at l-i-e dot com
Reported By: ceo at l-i-e dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: *
PHP Version: Irrelevant
New Comment:
Certainly support for more SAPIs would be a Good Thing.
There is probably other information output by phpinfo() that only works
on one/some SAPIs... But perhaps that's confined to the Module
sub-sections that only support some SAPIs.
My primary goal is to stop people from asking why their change to
php.ini didn't work
Many/Most of them check using phpinfo(), and if they had it right in
front of them that their SAPI has been running for 2 years, they'd
*know* they didn't re-start it...
Actually, how about just this, the exact same on all SAPIs:
Date/time stamp the load-time of php.ini information when php.ini is
read.
This achieves the desired goal on all SAPIs/OSes and should be, what?,
a line of code to record the date/time in a variable somewhere, and
another line of code to print it out later?
Perhaps even make it a sort of 'fake' entry in the ini_get (read only)
functions so it can be checked programmatically.
So ini_get('php.ini load_time') would return the date/time php.ini got
loaded.
Just thinking aloud here...
Sorry if this should have run by php-dev first.
Seemed so simple when I first posted. :-)
Previous Comments:
[2005-01-05 06:35:48] [EMAIL PROTECTED]
I do not see any harm in this, save that it would be limiting a feature
to a specific server by design. Perhaps if it was implemented on *all*
SAPIs that it is in context on, not just Apache?
The bigger question, I suppose, is is this the place of phpinfo()?
As I understand it, phpinfo() is used to check configuration, but the
manual states:
Outputs a large amount of information about the current state of
PHP.
Perhaps server uptime *is* 'the current state of PHP'? Is this
information readily obtainable through other means? Would this be
better implemented as 'apache_get_uptime()'?
Just points for discussion, I am not going to take any action on it.
[2005-01-03 18:26:51] ceo at l-i-e dot com
Description:
It would be Really Nifty (tm) if phpinfo would output how long Apache
has been running.
So when you think you re-started Apache, but it silently failed because
of a dumb /etc script, you know why that change to httpd.conf or php.ini
didn't work.
Or if you're a newbie and you are staring at that phpinfo() output,
you'll realize more quickly that the world is not what you think it is,
because Apache was supposed to have been re-started.
Or...
I just think it would help reduce the number of confused users,
particularly the less experienced ones.
Hey, server up-time would also be Good Thing (tm), while you're at it.
--
Edit this bug report at http://bugs.php.net/?id=31391edit=1
#31391 [Opn]: phpinfo - Apache up-time
ID: 31391
User updated by: ceo at l-i-e dot com
Reported By: ceo at l-i-e dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: *
PHP Version: Irrelevant
New Comment:
Perhaps it should be called PHP up-time
Since that is what it truly is measuring/recording.
Previous Comments:
[2005-01-06 00:37:18] ceo at l-i-e dot com
Certainly support for more SAPIs would be a Good Thing.
There is probably other information output by phpinfo() that only works
on one/some SAPIs... But perhaps that's confined to the Module
sub-sections that only support some SAPIs.
My primary goal is to stop people from asking why their change to
php.ini didn't work
Many/Most of them check using phpinfo(), and if they had it right in
front of them that their SAPI has been running for 2 years, they'd
*know* they didn't re-start it...
Actually, how about just this, the exact same on all SAPIs:
Date/time stamp the load-time of php.ini information when php.ini is
read.
This achieves the desired goal on all SAPIs/OSes and should be, what?,
a line of code to record the date/time in a variable somewhere, and
another line of code to print it out later?
Perhaps even make it a sort of 'fake' entry in the ini_get (read only)
functions so it can be checked programmatically.
So ini_get('php.ini load_time') would return the date/time php.ini got
loaded.
Just thinking aloud here...
Sorry if this should have run by php-dev first.
Seemed so simple when I first posted. :-)
[2005-01-05 06:35:48] [EMAIL PROTECTED]
I do not see any harm in this, save that it would be limiting a feature
to a specific server by design. Perhaps if it was implemented on *all*
SAPIs that it is in context on, not just Apache?
The bigger question, I suppose, is is this the place of phpinfo()?
As I understand it, phpinfo() is used to check configuration, but the
manual states:
Outputs a large amount of information about the current state of
PHP.
Perhaps server uptime *is* 'the current state of PHP'? Is this
information readily obtainable through other means? Would this be
better implemented as 'apache_get_uptime()'?
Just points for discussion, I am not going to take any action on it.
[2005-01-03 18:26:51] ceo at l-i-e dot com
Description:
It would be Really Nifty (tm) if phpinfo would output how long Apache
has been running.
So when you think you re-started Apache, but it silently failed because
of a dumb /etc script, you know why that change to httpd.conf or php.ini
didn't work.
Or if you're a newbie and you are staring at that phpinfo() output,
you'll realize more quickly that the world is not what you think it is,
because Apache was supposed to have been re-started.
Or...
I just think it would help reduce the number of confused users,
particularly the less experienced ones.
Hey, server up-time would also be Good Thing (tm), while you're at it.
--
Edit this bug report at http://bugs.php.net/?id=31391edit=1
#31391 [NEW]: phpinfo - Apache up-time
From: ceo at l-i-e dot com Operating system: All PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: phpinfo - Apache up-time Description: It would be Really Nifty (tm) if phpinfo would output how long Apache has been running. So when you think you re-started Apache, but it silently failed because of a dumb /etc script, you know why that change to httpd.conf or php.ini didn't work. Or if you're a newbie and you are staring at that phpinfo() output, you'll realize more quickly that the world is not what you think it is, because Apache was supposed to have been re-started. Or... I just think it would help reduce the number of confused users, particularly the less experienced ones. Hey, server up-time would also be Good Thing (tm), while you're at it. -- Edit bug report at http://bugs.php.net/?id=31391edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31391r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31391r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31391r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31391r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31391r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31391r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31391r=needscript Try newer version: http://bugs.php.net/fix.php?id=31391r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31391r=support Expected behavior: http://bugs.php.net/fix.php?id=31391r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31391r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31391r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31391r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31391r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31391r=dst IIS Stability: http://bugs.php.net/fix.php?id=31391r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31391r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31391r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31391r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31391r=mysqlcfg
#31375 [NEW]: array_set_current
From: ceo at l-i-e dot com Operating system: All PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: array_set_current Description: While messing around with next/current/end/prev on large arrays, it became apparent that there is a gaping hole in functionality: I can't set the current internal pointer of the array to an arbitrary value. :-( I have to walk through the whole array to the element I want as my 'current' An array_set_current function which takes an array and integer to set the current internal pointer to the N'th element is pretty important for quickly starting off at the right place in my array. -- Edit bug report at http://bugs.php.net/?id=31375edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31375r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31375r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31375r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31375r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31375r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31375r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31375r=needscript Try newer version: http://bugs.php.net/fix.php?id=31375r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31375r=support Expected behavior: http://bugs.php.net/fix.php?id=31375r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31375r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31375r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31375r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31375r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31375r=dst IIS Stability: http://bugs.php.net/fix.php?id=31375r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31375r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31375r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31375r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31375r=mysqlcfg
#31362 [NEW]: GtkFileSelection-complete more complete
From: ceo at l-i-e dot com Operating system: PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: GtkFileSelection-complete more complete Description: It would be Really Nifty (tm) if GtkFileSelection-complete took an optional second argument which would make the pattern matching 'pervasive' IE, the dialog would continue to only present filenames that matched the given expression. Providing the same functionality through some other mechanism would be fine, of course. I suppose one could, in theory, dig down into the guts of the Widget, and find all the widgets inside that can affect the selection, and then connect() a function to each one that would call complete() repeatedly... But it would be Really Hard for your mere mortal programmer to find *ALL* the possible circumstances that could change the selection -- Edit bug report at http://bugs.php.net/?id=31362edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31362r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31362r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31362r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31362r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31362r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31362r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31362r=needscript Try newer version: http://bugs.php.net/fix.php?id=31362r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31362r=support Expected behavior: http://bugs.php.net/fix.php?id=31362r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31362r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31362r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31362r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31362r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31362r=dst IIS Stability: http://bugs.php.net/fix.php?id=31362r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31362r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31362r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31362r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31362r=mysqlcfg
#24936 [NEW]: FDFInitialize not defined
From: ceo at l-i-e dot com Operating system: Mandrake 8 PHP version: 4.3.2 PHP Bug Type: FDF related Bug description: FDFInitialize not defined Description: Compiling from source Apache 1.3.28 + PHP 4.3.2 --with-fdftk=shared + libfdftk.so installed and displayed by ldconfig -v, yields: /usr/local/apache/bin/httpd: relocation error: /usr/lib/php/extensions/fdf.so: undefined symbol: FDFInitialize Attempting a static compilation yielded: phpinfo() then showed me that FDF was there: fdf FDF Support enabled FdfTk Version 5.0 Alas, attempting to use fdf_create() yielded: FDF Error: An internal FDF Library error occurred Previously, using RPMs of PHP 4.2.3 and Apache 1.3.26 and then compiling the PHP fdf.so from source and tossing it in the extensions directory, I was able to use FDF. So I'm reasonably certain that the FDFTK is working correctly. But I need fdf_open_string and fdf_enum_values from PHP 4.3+ A much more long-winded version of this problem is at: http://marc.theaimsgroup.com/?l=php-generalm=105976533301489w=2 -- Edit bug report at http://bugs.php.net/?id=24936edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24936r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24936r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24936r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24936r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24936r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24936r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24936r=support Expected behavior: http://bugs.php.net/fix.php?id=24936r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24936r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24936r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24936r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24936r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24936r=dst IIS Stability: http://bugs.php.net/fix.php?id=24936r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24936r=gnused
