#33012 [NEW]: fread/fopen error
From: justin at aofrozencity dot com
Operating system: Windows 2003 Server
PHP version: 4.3.11
PHP Bug Type: Filesystem function related
Bug description: fread/fopen error
Description:
I figured out why the problem is. I found out that fread/fopen doesn't
read image file exactly and properly because I checked orginal image file
code that isn't match the image file code which was from fread/fopen.
Reproduce code:
---
// Output PNG Image
$file = fopen('images/tmp/'.$tmpname, 'rb');
$source = fread($file , filesize('images/tmp/'.$tmpname));
fclose($file);
header("Content-Type: image/png");
print($source);
Expected result:
"The image cannot be displayed, because it contains errors"
--
Edit bug report at http://bugs.php.net/?id=33012&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33012&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33012&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33012&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33012&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33012&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33012&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33012&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33012&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33012&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33012&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33012&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33012&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33012&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33012&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33012&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33012&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33012&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33012&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33012&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33012&r=mysqlcfg
#33011 [NEW]: shmop: can still open segment for reading after shmop_delete
From: joe at bs0 dot com Operating system: windows xp PHP version: 4.3.11 PHP Bug Type: Unknown/Other Function Bug description: shmop: can still open segment for reading after shmop_delete Description: Tested with iis/php5.0.4, iis/php4.3.11, apache2/php4.3.11 - same problem. after a succesful call to shmop_delete, the shared memory can still be opened, and the previous values read in. Delete call seems to have no effect. Each step is done in new request: 1)Create shared memory block, populate with string. 2)open block, read in string 3)open block, call shmop_delete (returns true) 4)open block, read in string <- should not be able to open block for reading at this point. looks to be the same as Bug #28965, this bug has status of No Feedback, so opening a new one. Reproduce code: --- Code to reproduce: http://bs0.com/shmop/shmop_test.php.txt Expected result: leave only one step uncommented at a time, at step 4, the open should fail and no data should be read in. Actual result: -- After step 4, memory is still opened/data is read in. -- Edit bug report at http://bugs.php.net/?id=33011&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33011&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33011&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33011&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33011&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33011&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33011&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33011&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33011&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33011&r=support Expected behavior: http://bugs.php.net/fix.php?id=33011&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33011&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33011&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33011&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33011&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33011&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33011&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33011&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33011&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33011&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33011&r=mysqlcfg
#31376 [Com]: Function cpdf_fill_stroke() only fills
ID: 31376
Comment by: yuanchen73 at hotmail dot com
Reported By: sybrendijkstra at gmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows 98 se
PHP Version: 5.0.1
New Comment:
OS: Windows 2000 Server
Version: 5.0.0
Same problem. The stroke doesn't work even I call cpdf_fill() and
cpdf_stroke() seperately. I have to redefine the area. For example:
cpdf_rect($cpdf, 55, 546, 60, 24);
cpdf_fill($cpdf);
cpdf_rect($cpdf, 55, 546, 60, 24); // won't work without this line
cpdf_stroke($cpdf);
Previous Comments:
[2005-03-11 11:29:14] sybrendijkstra at gmail dot com
Hello,
I had some time left and found out that in the PHP source,(
http://chora.php.net/co.php/pecl/cpdf/cpdf.c?php=4291a9959790339708d78fe44745940c&r=1.58.2.1),
around line 1700 i found this:
/* {{{ proto bool cpdf_fill_stroke(int pdfdoc)
Fills and stroke current path */
PHP_FUNCTION(cpdf_fill_stroke)
{
zval **arg1;
int id, type;
CPDFdoc *pdf;
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &arg1) ==
FAILURE) {
WRONG_PARAM_COUNT;
}
CPDF_FETCH_CPDFDOC(arg1);
cpdf_fill(pdf);
cpdf_stroke(pdf);
RETURN_TRUE;
}
It calls, cpdf_fill() and after that cpdf_stroke(). But in the ClibPDF
manual, cpdfman200.pdf page 19, there is a function "void
cpdf_fillAndStroke(CPDFdoc *pdf);".
[2005-03-06 18:09:09] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-01-01 21:35:41] sybrendijkstra at gmail dot com
Description:
I experienced some unexpected results with the CLibPDF function:
cpdf_fill_stroke() ->
http://www.php.net/manual/en/function.cpdf-fill-stroke.php
According to the manual the function is able to fill the current path
and then strokes the same path. As far is i am able to produce that
function only fills and there is no stroking at all to see.
The code below is a convert from a C example from FastI/O
(http://www.fastio.com/example/Arcs.c.txt)
Reproduce code:
---
$rbump = 0.1*100;
$xorig = 2.5*100;
$greenblue = 1.0;
$yorig = 7.5*10;
$radius= 2.2*100;
cpdf_setrgbcolor_stroke($cpdf, 0.7, 0.7, 0.0);
for($i=11; $i>=0; $i--) {
$radius -= $rbump;
$greenblue = $i/12.0;
cpdf_setrgbcolor_fill($cpdf, 1.0, $greenblue, $greenblue);
$eangle = ($i+1)*30.0; /* end angle */
$sangle = 0.0;
cpdf_moveto($cpdf, $xorig, $yorig);
cpdf_arc($cpdf, $xorig, $yorig, $radius, $sangle, $eangle, 0);
cpdf_closepath($cpdf);
cpdf_fill_stroke($cpdf);/* fill and stroke */
}
Expected result:
I expect to see: http://www.fastio.com/example/arctest.pdf
And then the "Color filled pie shapes" image. A red/white background
with a green/yellow lines as pie pieces.
Actual result:
--
I actually see only the red/white background. No stroke lines are
visable. I see the same result as when I only use cpdf_fill()
function.
When I saw the source of the .pdf file generated by PHP there where
some minor differences between a file which had cpdf_fill_stroke() and
a file that used only cpdf_fill(). cpdf_fill_stroke() does add
something to the .pdf file, but it's not visable in my PDF viewer
(Adobe Acrobat 5.0).
To be short:
cpdf_fill_stroke() -> only fills (and does not stroke)
cpdf_fill() -> only fills
cpdf_stroke() -> only strokes
--
Edit this bug report at http://bugs.php.net/?id=31376&edit=1
#32976 [Fbk->Opn]: (Un)serialize destroys references in a tree like class structure
ID: 32976 User updated by: a_wizzard at hotmail dot com Reported By: a_wizzard at hotmail dot com -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Gentoo Linux 2.6 PHP Version: 5.0.4 New Comment: I've tried to insert the CVS version last night and I think after a lot of tinkering I managed to get it running - same bug. Whatever I try, the references are gone and do not come back after unserializing thus rendering the recovered tree next to useless... Mind you, I only have a production machine over here so I'm not to eager to rip out a working module from Apache - it can break at any time. I'm hoping someone else will run into this and might provide additional info. For the moment I reverted the server back to PHP 4. When I find the time I'll try to set up a spare server and test CVS releases. Btw would it really be that hard to fix? I mean the same works in PHP 4 fine and looking at the string serialize generates I can't imagine that fixing this would be a huge problem (although an annoying one while its not fixed)... Previous Comments: [2005-05-08 04:37:26] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2005-05-08 04:01:45] a_wizzard at hotmail dot com Description: When designing a file browser I discovered the PHP 5 does not handle the unserialization of references correctly. I'm using a tree like structure in which every node has a reference to its parents and its children. When deserializing, the reference becomes corrupted (or rather it disappears). Look at the url below: http://sportlaan.adsl.utwente.nl/webstorage/index.php The first time a session is created with the default tree, notice that the nodes link to eachother. When you click on the upload link at the left directory tree (below the debug output) you'll see the script stops with an error complaining about its parent not being an object. This should be the exact same structure as when starting the script. Btw, kill the session using: http://sportlaan.adsl.utwente.nl/webstorage/index.php?clear=1 I've tested the code on the PHP 4.3.*something* engine as well and that one handles it perfectly - the references are restored using the serialize and unserialize calls. Btw, I saw the bug report on: http://bugs.php.net/bug.php?id=27120 This seems (by description) pretty much the same bug as reported before - what puzzles me though is that the old bug is from the old PHP5 CVS version whereas I am already using the stable 5.0.4. So its either not the same bug or the bug reappeared again... Reproduce code: --- See description Expected result: See description Actual result: -- See description -- Edit this bug report at http://bugs.php.net/?id=32976&edit=1
#28965 [Com]: Problem with shmop (cannot delete a segment)
ID: 28965
Comment by: joe at bs0 dot com
Reported By: mauroi at digbang dot com
Status: No Feedback
Bug Type: Unknown/Other Function
Operating System: Windows XP
PHP Version: 5.0.0RC3
New Comment:
Am experiencing the same problem on windows xp with iis and apache2.
Tested in php 4.3.11 and the snapshot in the comment above, no
difference. After calling shmop_delete, memory can still be
opened/read on either the same request, or subsequent ones.(am calling
shmop_close after delete)
Previous Comments:
[2005-03-05 01:00:06] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-02-25 11:19:29] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2004-06-30 00:14:40] mauroi at digbang dot com
Description:
First of all, when I call shmop_open with the "n" access mode I always
get an error ("cannot create...").
But also, when I create it with the "c" access mode it works ok. Then
(in another execution) I can read that shared memory segment and it
returns the correct data. If I try to delete the segment the function
always return true, but it does not delete it (on the next request I
can read it anyway).
Looking at the process explorer I can see that the apache process
always get a new "Section" called \BaseNamedObjects\TSRM_SHM_DESCRIPTOR
(even if my PHP script is only reading the segment or deleting the
segment, not creating one).
Thanks in advance.
PS. I get the same error on PHP 4 / Windows XP.
Reproduce code:
---
I execute the following script 3 times. First with the READ and DELETE
parts commented. Then with WRITE and DELETE parts commented. And
finally with the WRITE and READ parts commented.
After that if the segments exists anyway.
a = '43534553';
$this->b = 'jeqgfhewfg';
}
}
$foo = new Foo();
$key = CreateKey('var');
/* WRITE */
$content = serialize($foo);
$shmId = shmop_open($key, "c", 0777, strlen($content));
$written = shmop_write($shmId, $content, 0);
shmop_close($shmId);
/* READ */
$shmId = shmop_open($key, 'a', 0, 0);
$content = shmop_read($shmId, 0, shmop_size($shmId));
shmop_close($shmId);
var_dump($content);
/* DELETE */
$shmId = shmop_open($key, 'w', 0, 0);
$success = shmop_delete($shmId);
shmop_close($shmId);
function CreateKey($key)
{
$fileName = './' . $key;
if (!file_exists($fileName))
{
touch($fileName);
}
return FTOK($fileName, 'a');
}
function FTOK($pathName, $projId)
{
$stat = stat($pathName);
$key = sprintf("%u",
(($stat['ino'] & 0x) | (($stat['dev'] & 0xff) << 16) |
(($projId
& 0xff) << 24)));
return $key;
}
?>
Expected result:
On a fourth request I would expect an error if I execute the READ part
Actual result:
--
I get the foo object.
--
Edit this bug report at http://bugs.php.net/?id=28965&edit=1
#32933 [Opn->Asn]: Cannot extend class "SQLiteDatabase"
ID: 32933 Updated by: [EMAIL PROTECTED] Reported By: rbro at hotmail dot com -Status: Open +Status: Assigned Bug Type: SQLite related Operating System: Linux PHP Version: 5.0.4 -Assigned To: +Assigned To: helly New Comment: Marcus, you did it: http://cvs.php.net/diff.php/php-src/ext/sqlite/sqlite.c?r1=1.97&r2=1.98&ty=u Previous Comments: [2005-05-03 23:16:53] rbro at hotmail dot com Description: The SQLiteDatabase class is not extendable while other databases classes such as mysqli are extendable. Reproduce code: --- Expected result: no output Actual result: -- PHP Fatal error: Class s1 may not inherit from final class (SQLiteDatabase) in 1.php on line 6 Fatal error: Class s1 may not inherit from final class (SQLiteDatabase) in 1.php on line 6 -- Edit this bug report at http://bugs.php.net/?id=32933&edit=1
#33010 [Fbk->Csd]: protected member array treated as static
ID: 33010 User updated by: bart dot vanbrabant at zoeloelip dot be Reported By: bart dot vanbrabant at zoeloelip dot be -Status: Feedback +Status: Closed Bug Type: Zend Engine 2 problem Operating System: Linux 2.6.11 PHP Version: 5.0.4 New Comment: Seems like this is fixed in 5.0.5-dev Previous Comments: [2005-05-11 23:06:05] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Can't reproduce it. [2005-05-11 22:58:06] bart dot vanbrabant at zoeloelip dot be Description: When using the __get and __set function and extending from a class the variable of the super class is treated static. The description isn't very clear but the source code explains it better. It seems like the super class of the sub class uses a static member or that the same object is used. Reproduce code: --- The code snippit is a bit to long (~50lines): http://zoeloelip.be:81/ea/tests/get_set.php.txt (the code) http://zoeloelip.be:81/ea/tests/get_set.php (the output) The server runs php 5.0.3 but on my machine with php 5.0.4 it also gives this error. Expected result: super::__construct super: __get $test at super construction: 10 super: __get super: __set super: __get The value of 'test' is 11 - super::__construct sub: __get $test at super construction: 10 sub::__construct sub: __get $test at sub construction: 10 sub: __get sub: __set sub: __get The value of 'test' in sub::super is 11 Actual result: -- super::__construct super: __get $test at super construction: 10 super: __get super: __set super: __get The value of 'test' is 11 -- sub::__construct sub: __get $test at sub construction: 11 sub: __get sub: __set sub: __get The value of 'test' in sub::super is 12 -- Edit this bug report at http://bugs.php.net/?id=33010&edit=1
#33010 [Opn->Fbk]: protected member array treated as static
ID: 33010 Updated by: [EMAIL PROTECTED] Reported By: bart dot vanbrabant at zoeloelip dot be -Status: Open +Status: Feedback Bug Type: Zend Engine 2 problem Operating System: Linux 2.6.11 PHP Version: 5.0.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Can't reproduce it. Previous Comments: [2005-05-11 22:58:06] bart dot vanbrabant at zoeloelip dot be Description: When using the __get and __set function and extending from a class the variable of the super class is treated static. The description isn't very clear but the source code explains it better. It seems like the super class of the sub class uses a static member or that the same object is used. Reproduce code: --- The code snippit is a bit to long (~50lines): http://zoeloelip.be:81/ea/tests/get_set.php.txt (the code) http://zoeloelip.be:81/ea/tests/get_set.php (the output) The server runs php 5.0.3 but on my machine with php 5.0.4 it also gives this error. Expected result: super::__construct super: __get $test at super construction: 10 super: __get super: __set super: __get The value of 'test' is 11 - super::__construct sub: __get $test at super construction: 10 sub::__construct sub: __get $test at sub construction: 10 sub: __get sub: __set sub: __get The value of 'test' in sub::super is 11 Actual result: -- super::__construct super: __get $test at super construction: 10 super: __get super: __set super: __get The value of 'test' is 11 -- sub::__construct sub: __get $test at sub construction: 11 sub: __get sub: __set sub: __get The value of 'test' in sub::super is 12 -- Edit this bug report at http://bugs.php.net/?id=33010&edit=1
#32945 [Asn]: copy size 0 file with ftp wrapper
ID: 32945
Updated by: [EMAIL PROTECTED]
Reported By: jxmaster at msn dot com
Status: Assigned
Bug Type: Filesystem function related
Operating System: freebsd4.3,windowsxp,linux9.0
PHP Version: 4.3.11
Assigned To: pollita
New Comment:
The very same situation exists with http wrapper.
The problem is that php_stream_copy_to_stream() returns 0 on error and
we can't distinguish zero-length file from error if there is no stat()
for current wrapper.
Previous Comments:
[2005-05-10 15:17:35] [EMAIL PROTECTED]
Sara, you're most familiar with this.. (this propably happens in PHP 5
too)
[2005-05-04 17:28:47] jxmaster at msn dot com
Description:
copy('ftp://username:[EMAIL PROTECTED]/path/filename', 'tmp.dat');
If the file in the ftp server has size 0, the copy statment returned
false. However, the file tmp.dat was created with size 0.
copy ('localfile', 'tmp.dat') worked well.
Reproduce code:
---
copy('ftp://username:[EMAIL PROTECTED]/path/filename', 'tmp.dat');
Expected result:
The file tmp.dat is created in the current directory with file zero and
gets a TRUE return.
Actual result:
--
The file tmp.dat is created in the current directory with file zero,
but gets a FALSE return.
--
Edit this bug report at http://bugs.php.net/?id=32945&edit=1
#28828 [NoF->Csd]: Problem with appending session.use_trans_sid to urls
ID: 28828 User updated by: demjanich at yandex dot ru -Reported By: demjan at elkor dot lv +Reported By: demjanich at yandex dot ru -Status: No Feedback +Status: Closed Bug Type: Session related Operating System: Linux PHP Version: 5.0.0RC3 New Comment: Now all works fine. Thanks! Previous Comments: [2005-02-23 01:00:10] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-02-15 01:40:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2004-06-18 14:07:06] demjanich at yandex dot ru Description: Hello! There is some problem in adding SESSID when "session.use_trans_sid" is enabled. See code bellow. Reproduce code: --- "; ?> test Expected result: 00 [... a lot of nulls] test Actual result: -- 00[... a lot of nulls] test -- Edit this bug report at http://bugs.php.net/?id=28828&edit=1
#33010 [NEW]: protected member array treated as static
From: bart dot vanbrabant at zoeloelip dot be Operating system: Linux 2.6.11 PHP version: 5.0.4 PHP Bug Type: Zend Engine 2 problem Bug description: protected member array treated as static Description: When using the __get and __set function and extending from a class the variable of the super class is treated static. The description isn't very clear but the source code explains it better. It seems like the super class of the sub class uses a static member or that the same object is used. Reproduce code: --- The code snippit is a bit to long (~50lines): http://zoeloelip.be:81/ea/tests/get_set.php.txt (the code) http://zoeloelip.be:81/ea/tests/get_set.php (the output) The server runs php 5.0.3 but on my machine with php 5.0.4 it also gives this error. Expected result: super::__construct super: __get $test at super construction: 10 super: __get super: __set super: __get The value of 'test' is 11 - super::__construct sub: __get $test at super construction: 10 sub::__construct sub: __get $test at sub construction: 10 sub: __get sub: __set sub: __get The value of 'test' in sub::super is 11 Actual result: -- super::__construct super: __get $test at super construction: 10 super: __get super: __set super: __get The value of 'test' is 11 -- sub::__construct sub: __get $test at sub construction: 11 sub: __get sub: __set sub: __get The value of 'test' in sub::super is 12 -- Edit bug report at http://bugs.php.net/?id=33010&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33010&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33010&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33010&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33010&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33010&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33010&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33010&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33010&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33010&r=support Expected behavior: http://bugs.php.net/fix.php?id=33010&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33010&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33010&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33010&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33010&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33010&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33010&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33010&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33010&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33010&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33010&r=mysqlcfg
#32999 [Com]: Segmentation fault
ID: 32999
Comment by: andrew at sourcelabs dot com
Reported By: andrea dot busia at axis-sv dot it
Status: Feedback
Bug Type: Mailparse related
Operating System: linux redhat enterprise
PHP Version: 5.0.4
New Comment:
The problem here is in mailparse. In mailparse.c:151,
zend_register_internal_class is called but the return value
is ignored. This function in PHP5 will always return a new
object which should be used by the caller. In PHP4, it
wasn't replaced so the address was ok. I will notify the
maintainer of mailparse.
Here is a patch to fix mailparse:
1 73c73
2 < static zend_class_entry mimemsg_class_entry;
3 ---
4 > static zend_class_entry *mimemsg_class_entry;
5 140a141,142
6 > zend_class_entry mmce;
7 >
8 148,149c150,151
9 < INIT_CLASS_ENTRY(mimemsg_class_entry,
"mimemessage", mimemessage_methods);
10 < zend_register_internal_class
(&mimemsg_class_entry TSRMLS_CC);
11 ---
12 > INIT_CLASS_ENTRY(mmce, "mimemessage",
mimemessage_methods);
13 > mimemsg_class_entry =
zend_register_internal_class(&mmce TSRMLS_CC);
14 214c216
15 < object_init_ex(object,
&mimemsg_class_entry);
16 ---
17 > object_init_ex(object, mimemsg_class_entry);
Previous Comments:
[2005-05-11 21:00:47] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Can't reproduce with latest CVS,
[2005-05-10 15:27:29] andrea dot busia at axis-sv dot it
Description:
All my scripts using mailparse exit with a segmentation fault since I
installed php5, in php4 it worked.
this is email_prova.txt content:
Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 18935 invoked from network); 10 May 2005 13:12:48
-
Received: from ppp-217-133-20-168.cust-adsl.tiscali.it (HELO axis20)
(217.133.20.168)
by 212.100.249.98 with SMTP; 10 May 2005 13:12:48 -
Message-ID: <[EMAIL PROTECTED]>
From: "Andrea Busia - Axis" <[EMAIL PROTECTED]>
To: "Andrea Busia - Axis" <[EMAIL PROTECTED]>
Subject: sdohhoisdfhi
Date: Tue, 10 May 2005 15:11:27 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_NextPart_000_0096_01C55572.897E0FA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
This is a multi-part message in MIME format.
--=_NextPart_000_0096_01C55572.897E0FA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
obidsfb=E8odfsb=E8odgbp=E8dgd
gs+dfghp=E8dfhp=E8gpdh=E8gfds
hgsfdhgiohpdsgoipsd
fdhoigsoidhgpfdfpo
--=_NextPart_000_0096_01C55572.897E0FA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
obidsfb=E8odfsb=E8odgbp=E8dgd
gs+dfghp=E8dfhp=E8gpdh=E8gfds
hgsfdhgiohpdsgoipsd
fdhoigsoidhgpfdfpo
--=_NextPart_000_0096_01C55572.897E0FA0--
Reproduce code:
---
get_child_count();
if ($n != 0) {
for ($i = 0; $i < $n; $i++) {
echo "a $i $n\n";
$part =& $msg->get_child($i);
echo "b $i $n\n";
}
}
else echo "99\n";
?>
Expected result:
a 0 3
b 0 3
a 1 3
b 1 3
a 2 3
b 2 3
Actual result:
--
a 0 3
Segmentation fault
backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 27129)]
zend_hash_apply_with_argument (ht=0x0,
apply_func=0x819e5a8 , argument=0x1)
at /home/archivi/php-5.0.4/Zend/zend_hash.c:680
680 HASH_PROTECT_RECURSION(ht);
(gdb) bt
#0 zend_hash_apply_with_argument (ht=0x0,
apply_func=0x819e5a8 , argument=0x1)
at /home/archivi/php-5.0.4/Zend/zend_hash.c:680
#1 0x081a9a58 in zend_update_class_constants (class_type=0x40522b40)
at /home/archivi/php-5.0.4/Zend/zend_API.c:694
#2 0x081a9aaa in _object_and_properties_init (arg=0x843509c,
class_type=0x40522b40, properties=0x0)
at /home/archivi/php-5.0.4/Zend/zend_API.c:714
#3 0x081a9b67 in _object_init_ex (arg=0x843509c,
class_type=0x40522b40)
at /home/archivi/php-5.0.4/Zend/zend_API.c:734
#4 0x4051b1d4 in mailparse_mimemessage_export (part=0x84326e4,
object=0x843509c) at
/tmp/tmpzRZItJ/mailparse-2.1.1/mailparse.c:214
#5 0x4051b99e in zif_mailparse_mimemessage_get_child (ht=1,
return_value=0x843509c, this_ptr=0x8436f54, return_value_used=1)
at /tmp/tmpzRZItJ/mailparse-2.1.1/mailparse.c:374
#6 0x081dd9db in zend_do_fcall_common_helper
(execute_data=0xbffe9a50,
opline=0x8437e18, op_array=0x8431654)
at /home/archivi/php-5.0.4/Zend/zend_execute.c:2727
#7 0x081c4cfa i
#33002 [Bgs]: IMAP PHP connection crash Apache 2
ID: 33002
User updated by: netadmin at vcsn dot com
Reported By: netadmin at vcsn dot com
Status: Bogus
Bug Type: IMAP related
Operating System: Linux 2.4.29
PHP Version: 4.3.11
New Comment:
Ahhh, I see. Ok I will rebuild my box on a newer version and see what
my mileage is. 8.0 is an old build so I'll see how 10.1 faires tonight
and I will update this bug for completeness. Thanks!
Previous Comments:
[2005-05-11 11:23:25] [EMAIL PROTECTED]
We've seen this before, it's a bug in how Slackware build nss_db:
#1 0x409f4e1e in db_open () from /lib/libnss_db.so.2
#2 0x409f4ed0 in internal_setent () from /lib/libnss_db.so.2
#3 0x409f390e in _nss_db_endprotoent () from /lib/libnss_db.so.2
#4 0x409f3b78 in _nss_db_getprotobyname_r () from /lib/libnss_db.so.2
that means that nss_db.so is built using a non-unique-name-ified
version of BDB, which is doomed to failure. You should report this bug
to the Slackware maintainers.
[2005-05-11 08:11:08] netadmin at vcsn dot com
It is not **obvious** to me- isn't it possible for PHP to return data
that could 'cause a crash subsequently?? It would really be more
helpful if you could point me to what you see **is** 'causing the crash
so I can test and report back.
[2005-05-11 01:27:34] [EMAIL PROTECTED]
The crash obviously happens outside PHP code -> not PHP bug.
[2005-05-10 23:00:26] netadmin at vcsn dot com
Description:
I've seen some postings about this problem but it appears the issue is
never followed up and thus gets closed- so I'm posting it again since
this is a high priority issue for me:
My environment is Apache 2.0.54 (I have also tried .47 and .49), PHP
4.3.11 (I have also tried, .1, .5, .8, and .10), Horde's IMP product
(version 3.2.1 and version 4 with the appropriate Horde version
respectively), Postgres 8.0.2 (migrated from 7.1.2- all data is intact
and I do see database connections) and the UW c-client (built from 4.58
and 4.63). The OS is Linux 2.4.29 (upgrade slackware 8 disto).
PHP appear's (I think) to be SIGSEGV'ing Apache when IMAP is being
used. Here is the gdb output that I get with different combinations of
the version's I specified about [inserted below]
(note that the last version I tried was .5 but I will repeat
with the lastest snapshot if requested since it also faulted)
Reproduce code:
---
As posted in a previous bug report, the following script will fault and
generate a SIGSEGV in an Apache process and log it:
Expected result:
I actually am not sure since I borrowed the code and I'm not a PHP
programmer. The way I was diagnosed the problem was by using my
sniffer to watch port 143 connections. I would expect to see a
connection to the IMAP server is things were working properly.
Actual result:
--
This GDB was configured as "i686-pc-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".
(gdb) run -DONE_PROCESS -DSSL
Starting program: /www2/bin/httpd -DONE_PROCESS -DSSL
[Thread debugging using libthread_db enabled]
[New Thread 1024 (LWP 12274)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 12274)]
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x409f4e1e in db_open () from /lib/libnss_db.so.2
#2 0x409f4ed0 in internal_setent () from /lib/libnss_db.so.2
#3 0x409f390e in _nss_db_endprotoent () from /lib/libnss_db.so.2
#4 0x409f3b78 in _nss_db_getprotobyname_r () from /lib/libnss_db.so.2
#5 0x403a647f in __getprotobyname_r (name=0x40767d84 "tcp",
resbuf=0x403d9b48, buffer=0x83fd720 "[EMAIL PROTECTED]", buflen=1024,
result=0xbfff6528)
at ../nss/getXXbyYY_r.c:200
#6 0x403a632d in getprotobyname (name=0x40767d84 "tcp") at
../nss/getXXbyYY.c:145
#7 0x406e838a in tcp_socket_open (family=2, adr=0x8442d50, adrlen=4,
port=143, tmp=0xbfff671c
"\221+D\b|[EMAIL PROTECTED]@|[EMAIL PROTECTED]@\n",
ctr=0xbfff6718, hst=0x8442d45 "vcsn.com") at tcp_unix.c:225
#8 0x406e81ee in tcp_open (host=0xbfff6fec "vcsn.com", service=0x0,
port=143) at tcp_unix.c:184
#9 0x406f9913 in net_open_work (dv=0x407c53c0, host=0xbfff6fec
"vcsn.com", service=0xbfff736e "imap", port=143, portoverride=143,
flags=0)
at mail.c:5967
#10 0x406f8113 in net_open (mb=0xbfff6fec, dv=0x0, port=143, ssld=0x0,
ssls=0x407ab92c "*imaps", sslp=993) at mail.c:5938
#11 0x4070a652 in imap_open (stream=0x8442a98) at imap4r1.c:823
#12 0x406ed6f9 in mail_open (stream=0x8442a98, name=0x83f9364
"{vcsn.com:143/imap/notls}", options=0) at mail.c:1217
#13 0x405e25fb in php_imap_do_open (ht=4, return_value=0x8397c4c,
this_ptr=0x0, return_value_used=1, persistent=0)
at /root/src/INSTALLED/php-4.3.5/e
#32953 [Opn->Fbk]: ob calls into ob handler
ID: 32953 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Output Control Operating System: RHEL 3 PHP Version: 4.3.11, 5.0.4 New Comment: What do you expect to get instead? ob_end_flush() calls output handler, which in turn calls ob_end_flush() and so on. You'll get the same result with this code: Previous Comments: [2005-05-05 12:20:54] [EMAIL PROTECTED] Description: the bellow generating Segmentation fault on both 4.3.11, 5.0.4 the gdb trace looks like infinit recursive. Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=32953&edit=1
#32981 [Opn->Fbk]: ReflectionMethod::getStaticVariables() causes apache2.0.54 seg fault
ID: 32981
Updated by: [EMAIL PROTECTED]
Reported By: phpbug at swift-web dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Gentoo 2.6.11
PHP Version: 5.0CVS (2005-05-09)
New Comment:
Nobody is able to reproduce it (me neither), so try to rebuild PHP
(grab new snapshot for that) and if you're still able to replicate it,
provide more info about your build: configure options, software used
etc.
Previous Comments:
[2005-05-10 17:16:44] phpbug at swift-web dot com
I couldn't make sense of the backtrace either. phpinfo() confirms I
have --enable-debug flag set.
I have no Zend extensions loaded.
I don't have apache compiled with --enable-debug. Is that part of the
problem?
[2005-05-10 14:40:14] [EMAIL PROTECTED]
That backtrace is useless to us. You really didn't configure with
--enable-debug.
Are you using any Zend extensions (any extension loaded with
zend_extension in php.ini) ?
[2005-05-10 04:55:33] phpbug at swift-web dot com
The script I run that crashes is a class I called ss_debug and it has a
dump method that will use the Reflection methods to output into a easy
to read table information about a class.
I remembered the ss_debug class has methods with static values so I set
it to report/parse itself and it ran, but only if I did it at the end of
a script that ran normally (If I tried dumping the output at the
beginning of a script or just an empty script like entered as an
example earlier, it crashed).
This confused me why it ran at the end and not at the beginning. I
tried adding a new method to this class that simple was:
function jason() {
static $me = true;
}
now it crashed all the time (whether I ran it on it's own or after a
page that normally worked).
Pulled a few hairs out and then it dawned on me to override the default
setting in that class before I dumped it and now it works.
So what I have narrowed it down to consistently is if I have static
variables that are still in their default setting of boolean true or
false then it causes a seg fault. If I override the default setting
before dumping (running the reflection class/methods) then it works.
Did I explain this clear enough?
[2005-05-10 04:01:09] phpbug at swift-web dot com
Couldn't get a core file (even though compiled with --enable-debug) so
I ran httpd -X under gdb
cut 'n paste bt results here:
#0 0xb7cca595 in memcpy () from /lib/libc.so.6
#1 0xb7a90f71 in zif_vprintf () from
/usr/lib/apache2/modules/libphp5.so
#2 0x0822ee7b in ?? ()
#3 0x in ?? ()
#4 0x0005 in ?? ()
#5 0xb7b2411e in zend_make_printable_zval () from
/usr/lib/apache2/modules/libphp5.so
#6 0xbffed060 in ?? ()
#7 0xb7b99b20 in php_tiff_bytes_per_format () from
/usr/lib/apache2/modules/libphp5.so
#8 0x0103 in ?? ()
#9 0xb7b0ea04 in _emalloc () from /usr/lib/apache2/modules/libphp5.so
#10 0xbffec64c in ?? ()
#11 0xbffec648 in ?? ()
#12 0x0052 in ?? ()
#13 0xb7a903c0 in zif_vprintf () from
/usr/lib/apache2/modules/libphp5.so
#14 0xbffec644 in ?? ()
#15 0xbffec648 in ?? ()
#16 0xbffec64c in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0x in ?? ()
#20 0x0020 in ?? ()
#21 0x0001 in ?? ()
#22 0x0004 in ?? ()
#23 0x in ?? ()
#24 0x in ?? ()
#25 0x in ?? ()
#26 0x in ?? ()
#27 0x in ?? ()
#28 0x in ?? ()
#29 0x in ?? ()
#30 0x in ?? ()
#31 0x in ?? ()
#32 0x2000 in ?? ()
#33 0x081e9cbc in ?? ()
#34 0x in ?? ()
#35 0x0007 in ?? ()
#36 0x in ?? ()
#37 0x in ?? ()
#38 0x0001 in ?? ()
#39 0x0007 in ?? ()
#40 0x in ?? ()
#41 0x08220dc4 in ?? ()
#42 0x08220324 in ?? ()
#43 0x0822ed04 in ?? ()
#44 0x0177 in ?? ()
#45 0x01e0 in ?? ()
#46 0x0001 in ?? ()
#47 0x in ?? ()
(line 47 repeats the same until 450)
#451 0xbffecca8 in ?? ()
#452 0x081f2d64 in ?? ()
#453 0x in ?? ()
(line 453 repeats the same until 596)
#597 0x7300 in ?? ()
#598 0xb7d572a0 in ?? () from /lib/libc.so.6
#599 0x in ?? ()
#600 0x in ?? ()
#601 0x in ?? ()
#602 0x in ?? ()
#603 0x in ?? ()
#604 0x081ff8cc in ?? ()
#605 0x in ?? ()
#606 0x0005 in ?? ()
#607 0x1999 in ?? ()
#608 0x in ?? ()
#609 0xb7d6eff4 in ?? () from /lib/libc.so.6
#610 0x081ff8cc in ?? ()
#611 0x0006 in ?? ()
#612 0xbffecf48 in ?? ()
#613 0xb7c8fefa in __strtol_internal () from /lib/libc.so.6
#614 0x0004 in ?? ()
[2005-05-10 00:52:01] [EMAIL PROTECTED]
Thank you for this bug report.
#32999 [Opn->Fbk]: Segmentation fault
ID: 32999
Updated by: [EMAIL PROTECTED]
Reported By: andrea dot busia at axis-sv dot it
-Status: Open
+Status: Feedback
Bug Type: Mailparse related
Operating System: linux redhat enterprise
PHP Version: 5.0.4
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Can't reproduce with latest CVS,
Previous Comments:
[2005-05-10 15:27:29] andrea dot busia at axis-sv dot it
Description:
All my scripts using mailparse exit with a segmentation fault since I
installed php5, in php4 it worked.
this is email_prova.txt content:
Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 18935 invoked from network); 10 May 2005 13:12:48
-
Received: from ppp-217-133-20-168.cust-adsl.tiscali.it (HELO axis20)
(217.133.20.168)
by 212.100.249.98 with SMTP; 10 May 2005 13:12:48 -
Message-ID: <[EMAIL PROTECTED]>
From: "Andrea Busia - Axis" <[EMAIL PROTECTED]>
To: "Andrea Busia - Axis" <[EMAIL PROTECTED]>
Subject: sdohhoisdfhi
Date: Tue, 10 May 2005 15:11:27 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_NextPart_000_0096_01C55572.897E0FA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
This is a multi-part message in MIME format.
--=_NextPart_000_0096_01C55572.897E0FA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
obidsfb=E8odfsb=E8odgbp=E8dgd
gs+dfghp=E8dfhp=E8gpdh=E8gfds
hgsfdhgiohpdsgoipsd
fdhoigsoidhgpfdfpo
--=_NextPart_000_0096_01C55572.897E0FA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
obidsfb=E8odfsb=E8odgbp=E8dgd
gs+dfghp=E8dfhp=E8gpdh=E8gfds
hgsfdhgiohpdsgoipsd
fdhoigsoidhgpfdfpo
--=_NextPart_000_0096_01C55572.897E0FA0--
Reproduce code:
---
get_child_count();
if ($n != 0) {
for ($i = 0; $i < $n; $i++) {
echo "a $i $n\n";
$part =& $msg->get_child($i);
echo "b $i $n\n";
}
}
else echo "99\n";
?>
Expected result:
a 0 3
b 0 3
a 1 3
b 1 3
a 2 3
b 2 3
Actual result:
--
a 0 3
Segmentation fault
backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 27129)]
zend_hash_apply_with_argument (ht=0x0,
apply_func=0x819e5a8 , argument=0x1)
at /home/archivi/php-5.0.4/Zend/zend_hash.c:680
680 HASH_PROTECT_RECURSION(ht);
(gdb) bt
#0 zend_hash_apply_with_argument (ht=0x0,
apply_func=0x819e5a8 , argument=0x1)
at /home/archivi/php-5.0.4/Zend/zend_hash.c:680
#1 0x081a9a58 in zend_update_class_constants (class_type=0x40522b40)
at /home/archivi/php-5.0.4/Zend/zend_API.c:694
#2 0x081a9aaa in _object_and_properties_init (arg=0x843509c,
class_type=0x40522b40, properties=0x0)
at /home/archivi/php-5.0.4/Zend/zend_API.c:714
#3 0x081a9b67 in _object_init_ex (arg=0x843509c,
class_type=0x40522b40)
at /home/archivi/php-5.0.4/Zend/zend_API.c:734
#4 0x4051b1d4 in mailparse_mimemessage_export (part=0x84326e4,
object=0x843509c) at
/tmp/tmpzRZItJ/mailparse-2.1.1/mailparse.c:214
#5 0x4051b99e in zif_mailparse_mimemessage_get_child (ht=1,
return_value=0x843509c, this_ptr=0x8436f54, return_value_used=1)
at /tmp/tmpzRZItJ/mailparse-2.1.1/mailparse.c:374
#6 0x081dd9db in zend_do_fcall_common_helper
(execute_data=0xbffe9a50,
opline=0x8437e18, op_array=0x8431654)
at /home/archivi/php-5.0.4/Zend/zend_execute.c:2727
#7 0x081c4cfa in execute (op_array=0x8431654)
at /home/archivi/php-5.0.4/Zend/zend_execute.c:1406
#8 0x081a87a5 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/archivi/php-5.0.4/Zend/zend.c:1069
#9 0x0817a386 in php_execute_script (primary_file=0xbffebdd0)
at /home/archivi/php-5.0.4/main/main.c:1632
#10 0x081e6948 in main (argc=2, argv=0xbffebe74)
at /home/archivi/php-5.0.4/sapi/cgi/cgi_main.c:1577
--
Edit this bug report at http://bugs.php.net/?id=32999&edit=1
#33009 [Opn]: floor does not work with some integers as argument
ID: 33009 User updated by: edelmar at ditech dot com dot br Reported By: edelmar at ditech dot com dot br Status: Open Bug Type: *Math Functions Operating System: Win XP PHP Version: 4.3.11 New Comment: $d = 75.6 * 100; $d = (string)$d; echo floor($d).''; // prints 7560, wich is expected... how embarassing. Previous Comments: [2005-05-11 20:12:01] edelmar at ditech dot com dot br Description: Using PHP Version 4.3.11 on Windows xp (my development machine). I believe this behavior of floor function is a bug. The number 7560 passed to it is an integer and would not be changed by floor. I am using 100 times number because PHP has no function like 'truncate'. I want 2 decimals and there is no way to do it with regular functions. Its like 7560 has some special properties because this error does not happens with a lot of other numbers. Thank you. Reproduce code: --- echo (75.6 * 100).''; // prints 7560 - OK echo intval(75.6 * 100).''; // prints 7559 - ? echo (int)(75.6 * 100).''; // prints 7559 - ? echo floor(75.6 * 100).''; // prints 7559 - ? echo ceil(75.6 * 100).''; // prints 7560 - OK echo round(75.6 * 100).''; // prints 7560 - OK Expected result: 7560 7560 7560 7560 7560 7560 Actual result: -- 7560 7559 7559 7559 7560 7560 -- Edit this bug report at http://bugs.php.net/?id=33009&edit=1
#33009 [Opn->Bgs]: floor does not work with some integers as argument
ID: 33009 Updated by: [EMAIL PROTECTED] Reported By: edelmar at ditech dot com dot br -Status: Open +Status: Bogus Bug Type: *Math Functions Operating System: Win XP PHP Version: 4.3.11 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. Previous Comments: [2005-05-11 20:41:00] edelmar at ditech dot com dot br $d = 75.6 * 100; $d = (string)$d; echo floor($d).''; // prints 7560, wich is expected... how embarassing. [2005-05-11 20:12:01] edelmar at ditech dot com dot br Description: Using PHP Version 4.3.11 on Windows xp (my development machine). I believe this behavior of floor function is a bug. The number 7560 passed to it is an integer and would not be changed by floor. I am using 100 times number because PHP has no function like 'truncate'. I want 2 decimals and there is no way to do it with regular functions. Its like 7560 has some special properties because this error does not happens with a lot of other numbers. Thank you. Reproduce code: --- echo (75.6 * 100).''; // prints 7560 - OK echo intval(75.6 * 100).''; // prints 7559 - ? echo (int)(75.6 * 100).''; // prints 7559 - ? echo floor(75.6 * 100).''; // prints 7559 - ? echo ceil(75.6 * 100).''; // prints 7560 - OK echo round(75.6 * 100).''; // prints 7560 - OK Expected result: 7560 7560 7560 7560 7560 7560 Actual result: -- 7560 7559 7559 7559 7560 7560 -- Edit this bug report at http://bugs.php.net/?id=33009&edit=1
#33009 [NEW]: floor does not work with some integers as argument
From: edelmar at ditech dot com dot br Operating system: Win XP PHP version: 4.3.11 PHP Bug Type: *Math Functions Bug description: floor does not work with some integers as argument Description: Using PHP Version 4.3.11 on Windows xp (my development machine). I believe this behavior of floor function is a bug. The number 7560 passed to it is an integer and would not be changed by floor. I am using 100 times number because PHP has no function like 'truncate'. I want 2 decimals and there is no way to do it with regular functions. Its like 7560 has some special properties because this error does not happens with a lot of other numbers. Thank you. Reproduce code: --- echo (75.6 * 100).''; // prints 7560 - OK echo intval(75.6 * 100).''; // prints 7559 - ? echo (int)(75.6 * 100).''; // prints 7559 - ? echo floor(75.6 * 100).''; // prints 7559 - ? echo ceil(75.6 * 100).''; // prints 7560 - OK echo round(75.6 * 100).''; // prints 7560 - OK Expected result: 7560 7560 7560 7560 7560 7560 Actual result: -- 7560 7559 7559 7559 7560 7560 -- Edit bug report at http://bugs.php.net/?id=33009&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33009&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33009&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33009&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33009&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33009&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33009&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33009&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33009&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33009&r=support Expected behavior: http://bugs.php.net/fix.php?id=33009&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33009&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33009&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33009&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33009&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33009&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33009&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33009&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33009&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33009&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33009&r=mysqlcfg
#32171 [Asn]: Userspace stream wrapper crashes PHP
ID: 32171 Updated by: [EMAIL PROTECTED] Reported By: jr at terragate dot net Status: Assigned -Bug Type: SPL related +Bug Type: Reproducible crash Operating System: * PHP Version: 5.* -Assigned To: helly +Assigned To: tony2001 New Comment: It has nothing to do with SPL, it's stream-related problem. Reassigned to myself, patch pending.. Previous Comments: [2005-03-09 17:52:16] jr at terragate dot net Finally I was able to create a smaller test case for the segfault (with error_reporting = E_ALL): Trace: (gdb) r crash.php Starting program: /usr/local/bin/php crash.php warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 15212)] Done Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 15212)] 0x0019 in ?? () Current language: auto; currently asm (gdb) bt #0 0x0019 in ?? () #1 0x081abc73 in _php_stream_free (stream=0x82fdce4, close_options=3) at /root/compile/php5-STABLE-200503091530/main/streams/streams.c:351 #2 0x080b3fb8 in spl_ce_dir_object_free_storage (object=0x82f76c4) at /root/compile/php5-STABLE-200503091530/ext/spl/spl_directory.c:66 #3 0x081fa906 in zend_objects_store_del_ref (zobject=0x82fd4e4) at /root/compile/php5-STABLE-200503091530/Zend/zend_objects_API.c:159 #4 0x081deb76 in _zval_dtor (zvalue=0x82fd4e4, __zend_filename=0x82549e0 "/root/compile/php5-STABLE-200503091530/Zend/zend_execute_API.c", __zend_lineno=392) at /root/compile/php5-STABLE-200503091530/Zend/zend_variables.c:61 #5 0x081d36f8 in _zval_ptr_dtor (zval_ptr=0x82fdda0, __zend_filename=0x8255940 "/root/compile/php5-STABLE-200503091530/Zend/zend_variables.c", __zend_lineno=193) at /root/compile/php5-STABLE-200503091530/Zend/zend_execute_API.c:392 #6 0x081dee88 in _zval_ptr_dtor_wrapper (zval_ptr=0x82fdda0) at /root/compile/php5-STABLE-200503091530/Zend/zend_variables.c:193 #7 0x081e8f13 in zend_hash_apply_deleter (ht=0x82761d0, p=0x82fdd94) at /root/compile/php5-STABLE-200503091530/Zend/zend_hash.c:574 #8 0x081e9164 in zend_hash_graceful_reverse_destroy (ht=0x82761d0) at /root/compile/php5-STABLE-200503091530/Zend/zend_hash.c:640 #9 0x081d302f in shutdown_executor () at /root/compile/php5-STABLE-200503091530/Zend/zend_execute_API.c:208 #10 0x081e0264 in zend_deactivate () at /root/compile/php5-STABLE-200503091530/Zend/zend.c:817 #11 0x081996e1 in php_request_shutdown (dummy=0x0) at /root/compile/php5-STABLE-200503091530/main/main.c:1214 #12 0x082155d0 in main (argc=2, argv=0xb844) at /root/compile/php5-STABLE-200503091530/sapi/cli/php_cli.c:1046 The script will be fully executed but php segfaults on shutdown. The behavior in the complex test case (with the WebDAV stream wrapper) was the same: Using instaneof instead of is_a caused the script to be fully executed but with a segfault on shutdown. To answer your second question I modified the test case above: Running this script with error_reporting set to E_ALL (or even E_ALL & ~E_NOTICE & ~E_STRICT) will lead to the behaviour already mentioned (deprecation warning thrown as exception). Running the script with error_reporting = 0 will terminate the script with exit code 0377 and without outputting 'Done'. Using gdb I figured out that php_error_cb is still called with the deprecation warning and zend_throw_exception will abort the script. We have two issues here: 1. A wrong free causing a segfault on shutdown 2. PHP notices and warnings thrown as exception I dont't know what to do with the segfault (my knowledge about PHP's internals is too limited to debug this yet). IMHO the second problem could be solved in 2 ways: 1. Modifying php_error_cb's behavior (as my patch does) 2. Do not set error_mode to EH_THROW in spl_directory.c if a user space stream wrapper is used. [2005-03-09 14:40:34] [EMAIL PROTECTED] Did i get that correct that all works frin when you use instanceof ? If so all is fine. Also what happens if you stick with is_a but set error mode to 0? [2005-03-07 11:25:40] jr at terragate dot net I tested the instanceof segfault against the 5.1 branch and it segfaults too. But I had to change a is_a in HTTP/Request.php to instanceof because the 'notice exception' was thrown there this time. I wasn't able to reproduce the segfault with a smaller test case by using HTTP/Request.php myself (PEAR's WebDAV Wrapper) nor using instanceof inside a small stream wrapper. Initially I tested the bug with 5.0.3 but tried a snap a few hours later. Sorry for not updating the version field. -
#32742 [Asn]: segmentation fault when the stream with a wrapper is not closed (Linux RH only)
ID: 32742
Updated by: [EMAIL PROTECTED]
Reported By: public at grik dot net
Status: Assigned
Bug Type: Reproducible crash
Operating System: Linux (RH7,RH9,Gentoo)
PHP Version: 5.0.4
-Assigned To: pollita
+Assigned To: tony2001
New Comment:
Reassigned to myself, patch pending..
Previous Comments:
[2005-04-18 16:39:36] [EMAIL PROTECTED]
Sara, you seem to be patching streams hard these days, please take a
look at it.
Looks like there is some memory corruption (but valgrind complains only
about invalid reads and tells nothing about invalid writes).
[2005-04-18 16:35:53] [EMAIL PROTECTED]
Here is the backtrace (pay attention to the last line):
(gdb) bt
#0 0x0018 in ?? ()
#1 0x0817f8a6 in _php_stream_free (stream=0x82b8cb4, close_options=11)
at /usr/src/dev/clean/php-src_5_0/main/streams/streams.c:351
#2 0x081814d8 in stream_resource_regular_dtor (rsrc=0x82b8d40) at
/usr/src/dev/clean/php-src_5_0/main/streams/streams.c:1361
#3 0x081b6e2f in list_entry_destructor (ptr=0x82b8d40) at
/usr/src/dev/clean/php-src_5_0/Zend/zend_list.c:178
#4 0x081b517a in zend_hash_del_key_or_index (ht=0x82372fc, arKey=0x0,
nKeyLength=0, h=6, flag=1) at
/usr/src/dev/clean/php-src_5_0/Zend/zend_hash.c:490
#5 0x081b6b8d in _zend_list_delete (id=6) at
/usr/src/dev/clean/php-src_5_0/Zend/zend_list.c:58
#6 0x081acff6 in _zval_dtor (zvalue=0x82b8998,
__zend_filename=0x8216844
"/usr/src/dev/clean/php-src_5_0/Zend/zend_execute_API.c",
__zend_lineno=392)
at /usr/src/dev/clean/php-src_5_0/Zend/zend_variables.c:69
#7 0x081a2d23 in _zval_ptr_dtor (zval_ptr=0x82b8bfc,
__zend_filename=0x8217570
"/usr/src/dev/clean/php-src_5_0/Zend/zend_variables.c",
__zend_lineno=193)
at /usr/src/dev/clean/php-src_5_0/Zend/zend_execute_API.c:392
#8 0x081ad275 in _zval_ptr_dtor_wrapper (zval_ptr=0x82b8bfc) at
/usr/src/dev/clean/php-src_5_0/Zend/zend_variables.c:193
#9 0x081b53b5 in zend_hash_apply_deleter (ht=0x82371d0, p=0x82b8bf0)
at /usr/src/dev/clean/php-src_5_0/Zend/zend_hash.c:574
#10 0x081b555f in zend_hash_graceful_reverse_destroy (ht=0x82371d0) at
/usr/src/dev/clean/php-src_5_0/Zend/zend_hash.c:640
#11 0x081a26ab in shutdown_executor () at
/usr/src/dev/clean/php-src_5_0/Zend/zend_execute_API.c:208
#12 0x081ae443 in zend_deactivate () at
/usr/src/dev/clean/php-src_5_0/Zend/zend.c:817
#13 0x081700a7 in php_request_shutdown (dummy=0x0) at
/usr/src/dev/clean/php-src_5_0/main/main.c:1214
#14 0x081dc2f6 in main (argc=2, argv=0xb154) at
/usr/src/dev/clean/php-src_5_0/sapi/cli/php_cli.c:1049
(gdb) f 1
#1 0x0817f8a6 in _php_stream_free (stream=0x82b8cb4, close_options=11)
at /usr/src/dev/clean/php-src_5_0/main/streams/streams.c:351
351
stream->wrapper->wops->stream_closer(stream->wrapper, stream
TSRMLS_CC);
(gdb) p *stream.wrapper.wops
$1 = {stream_opener = 0x4480, stream_closer = 0x18, stream_stat =
0x82a67b0, url_stat = 0, dir_opener = 0x1, label = 0x0, unlink = 0,
rename = 0x31,
stream_mkdir = 0x82a67c8, stream_rmdir = 0x2}
[2005-04-18 14:44:29] public at grik dot net
Description:
There is a problem with stream_wrapper_register() that appears on Linux
and not on the FreeBSD.
I open a stream with the registered wrapper and assing a handler to the
resource variable.
If a variable stays alive when the execution of the script reaches the
end, PHP gives the segmentation fault.
Attempt to close the resource from an object destructor does not help.
Platforms tested: 5 servers with Red Hat 7, 9 and gentoo 5.03 (kernels
2.4, 2.6, 2.6 hardened), PHP 5.03, 5.04, 4.3.7
In FreeBSD 5.3 there is no problem executing the script.
Reproduce code:
---
Expected result:
time with microseconds
Actual result:
--
When run from the command line - time with microseconds and words
"Segmentation fault",
when called from browser - no output.
--
Edit this bug report at http://bugs.php.net/?id=32742&edit=1
#32486 [NoF->Opn]: odbc_fetch_into returns wrong data
ID: 32486 User updated by: tho at e-dict dot net Reported By: tho at e-dict dot net -Status: No Feedback +Status: Open Bug Type: Adabas-D related Operating System: Linux PHP Version: 4.3.9 New Comment: Tried php4-STABLE-200501211130 and still get wrong results. The \0 issue described before could not be reproduced since the field in the second line was longer then in the first line. But I found out, that in all cases the \0 issue occoured, there was a date field right before the string field and this date field contained the data from the previous line. e.g. 1992-09-09, [EMAIL PROTECTED] 1960-01-09, [EMAIL PROTECTED] results in 1992-09-09, [EMAIL PROTECTED] 1992-09-09, [EMAIL PROTECTED] Previous Comments: [2005-04-06 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-03-29 17:38:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-03-29 16:58:34] tho at e-dict dot net Description: Sometimes after odbc_fetch_into($query, $row) $row contains parts of data from the previous fetched row. For now I'm not able to reproduce this behavior reliably, it just happens once in a while. What happens is that if the data of the previous row is longer than in the current, the result contains '$currentdata\0$somepreviousdata', e.g. previous row: "[EMAIL PROTECTED]" current row: "[EMAIL PROTECTED]" results in "[EMAIL PROTECTED]" IOW the field is as long as the data in the previous row, contains a \0 terminator after the field content and then the rest of the previous field. This also happens if a unset($row) is done before calling odbc_fetch_into() Reproduce code: --- N/A -- Edit this bug report at http://bugs.php.net/?id=32486&edit=1
#33008 [NEW]: phpinfo(INFO_MODULES) crashes Apache 2
From: elie_cohen at yahoo dot com Operating system: XP Home SP2 PHP version: 5CVS-2005-05-11 (dev) PHP Bug Type: Apache2 related Bug description: phpinfo(INFO_MODULES) crashes Apache 2 Description: Trying to call the function phpinfo(INFO_MODULES) (code below) from either IE 6 or Firefox crashes Apache 2.0.54. This problem can be reproduce with PHP 5.0.4, and PHP 5.1. The other phpinfo options (INFO_GENERAL, INFO_...) seem to work OK. phpMyAdmin seems to work fine also. Also the script works from the command line using php.exe. Let me know if you need more infos Reproduce code: --- Expected result: Modules list on Web page Actual result: -- Crashes Apache 2.0.54 with following Error signature: szAppName: apache.exe szAppVer: 2.0.54.0 szModName: MxAVIsp.dll szModVer: 5.0.0.6 offset: 19a9 -- Edit bug report at http://bugs.php.net/?id=33008&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33008&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33008&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33008&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33008&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33008&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33008&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33008&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33008&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33008&r=support Expected behavior: http://bugs.php.net/fix.php?id=33008&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33008&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33008&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33008&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33008&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33008&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33008&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33008&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33008&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33008&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33008&r=mysqlcfg
#32685 [Fbk->Opn]: Segfault when using assignment by reference within function
ID: 32685
User updated by: david at davidheath dot org
Reported By: david at davidheath dot org
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: mandrake linux 10.1
PHP Version: 4CVS-2005-04-14
New Comment:
Hi
thanks for following this up. I tried with the snapshot you gave and
still got the crash.
I tried running it in gdb as well ('fraid I don't really know whether
this helps or not).
See below.
Dave
[EMAIL PROTECTED] dh]$ gdb
GNU gdb 6.2-2mdk (Mandrakelinux)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i586-mandrake-linux-gnu".
(gdb) file /usr/local/src/php4-STABLE-200505110647/sapi/cli/php
Reading symbols from
/usr/local/src/php4-STABLE-200505110647/sapi/cli/php...done.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) run crash2.php
Starting program: /usr/local/src/php4-STABLE-200505110647/sapi/cli/php
crash2.php
Program received signal SIGSEGV, Segmentation fault.
0x08111a41 in shutdown_memory_manager (silent=0, clean_cache=0) at
/usr/local/src/php4-STABLE-200505110647/Zend/zend_alloc.c:530
530 REMOVE_POINTER_FROM_LIST(t);
(gdb) quit
Previous Comments:
[2005-05-11 10:05:56] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-04-19 13:53:19] ericvanblokland at gmail dot com
This maybe related to an issue I encountered. My guess is this code
will work fine with php5
http://bugs.php.net/bug.php?id=31624
[2005-04-13 10:51:34] david at davidheath dot org
> 1) Does it also crash when you replace file reading by
> assignment from string?
yes it does, see http://www.davidheath.org/php_bug/crash2.php.txt
I've also noticed that I had a mistake in the original repro script
(crash.php.txt), which I've now corrected (the filename on line 4 was
wrong). This may explain why you couldn't repro. However, having
changed that I now get:
[EMAIL PROTECTED] repro]$ /usr/local/php-4.3-CVS-13apr05/bin/php
crash.php
Content-type: text/html
X-Powered-By: PHP/4.3.12-dev
free(): invalid pointer 0x81b14a8!
ALSO, another important observation. The crash sometimes seems to not
happen if I execute the script in a different directory. For example:
[EMAIL PROTECTED] repro]$ pwd
/tmp/repro
[EMAIL PROTECTED] repro]$ ls
crash2.php
[EMAIL PROTECTED] repro]$ /usr/local/php-4.3-CVS-13apr05/bin/php
crash2.php
Content-type: text/html
X-Powered-By: PHP/4.3.12-dev
[EMAIL PROTECTED] repro]$ mkdir -p foo/bar
[EMAIL PROTECTED] repro]$ cd foo/bar
[EMAIL PROTECTED] bar]$ cp ../../crash2.php .
[EMAIL PROTECTED] bar]$ /usr/local/php-4.3-CVS-13apr05/bin/php
crash2.php
Content-type: text/html
X-Powered-By: PHP/4.3.12-dev
Segmentation fault (core dumped)
[2005-04-13 10:32:48] david at davidheath dot org
Hi,
I tried again with CVS HEAD (from PHP_4_3 branch). Still crashes.
[EMAIL PROTECTED] dh]$ /usr/local/php-4.3-CVS-13apr05/bin/php
crash.php
Content-type: text/html
X-Powered-By: PHP/4.3.12-dev
Segmentation fault (core dumped)
[EMAIL PROTECTED] dh]$
[2005-04-12 20:37:20] [EMAIL PROTECTED]
Two questions:
1) Does it also crash when you replace file reading by assignment from
string?
2) Did you try 5.0 or HEAD?
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/32685
--
Edit this bug report at http://bugs.php.net/?id=32685&edit=1
#30215 [Com]: strtotime returning huge timestamps instead of -1
ID: 30215
Comment by: olivier at oxeva dot fr
Reported By: pmurray at nevada dot net dot nz
Status: Assigned
Bug Type: Date/time related
Operating System: Linux 64bit - Opteron
PHP Version: 4.3.10-dev
Assigned To: derick
New Comment:
I could reproduce this bug on Bi-Xeon; fedora rc3
Previous Comments:
[2005-02-13 19:48:04] borishim at hotmail dot com
I could reproduce this on 6.0-CURRENT of FreeBSD/amd64 box
(which is 64bit OS also.)
[2005-02-11 18:18:36] sstillwell at aerostich dot com
PHP Version: 4.3.2-19 (RHEL)
OS: RHEL x86_64
CPU: Dual Intel Xeon 2.8 EM64T
I am getting this same bug as well.
This code
print strtotime(time());
Produces this
3434798239200
Looks like PHP is not quite ready for 64 bit plateforms at this time.
[2004-09-24 05:21:54] pmurray at nevada dot net dot nz
Description:
When using strtotime(), it returns a bogus timestamp instead of -1.
Gentoo 64bit (Opteron) 2004.2, Glibc 2.3.4, PHP 4.3.8;
strtotime(time()) returns 3396548642400
Gentoo 32bit (Pentium 4) 2004.2, Glibc 2.3.3, PHP 4.3.8 returns -1
FreeBSD 32bit, PHP 4.3.8 and 5.0.1 returns -1
This causes the examples in the date_format modifier page in the Smarty
documentation to fail. IE
{$smarty.now|date_format:"%Y"}
Could this be related to being on a 64bit platform?
Reproduce code:
---
strtotime(time());
Expected result:
Return -1
Actual result:
--
Return 3396548642400
--
Edit this bug report at http://bugs.php.net/?id=30215&edit=1
#32660 [Ver]: Assignment by reference causes crash when field access is overloaded (__get)
ID: 32660
Updated by: [EMAIL PROTECTED]
Reported By: ladislav dot prosek at matfyz dot cz
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-04-11
New Comment:
Initializing $a->whatever before assigning reference can be used as a
temporary workaround.
Previous Comments:
[2005-04-11 02:04:49] [EMAIL PROTECTED]
object(A)#1 (1) {
["q"]=>
&UNKNOWN:0
}
/usr/src/php/php5/Zend/zend_execute.c(891) : Freeing 0x0A117D6C (16
bytes), script=/home/jani/t.php
/usr/src/php/php5/Zend/zend_variables.h(45) : Freeing 0x0A117D2C (12
bytes), script=/home/jani/t.php
/usr/src/php/php5/Zend/zend_variables.c(120) : Actual location
(location was relayed)
=== Total 2 memory leaks detected ===
[2005-04-10 22:22:04] ladislav dot prosek at matfyz dot cz
Description:
There is probably a bug in memory allocation related to property
getters. Note that the behavior depends on lengths of the two strings
and also on the way the $q property is initialized.
Reproduce code:
---
class A
{
var $q;
function __construct()
{
$this->q = array();
}
function __get($name)
{
return $this->q;
}
};
$a = new A;
$b = "short";
$a->whatever =& $b;
$b = "much longer";
var_dump($a);
Expected result:
// as __get does not return a reference
// the output should IMHO look like this:
object(A)#1 (1) {
["q"]=>
array(0) {
}
}
// if you guys think the output should be
// different, please do explain it!
Actual result:
--
object(A)#1 (1) {
["q"]=>
CRASH!
--
Edit this bug report at http://bugs.php.net/?id=32660&edit=1
#32252 [Asn]: Segfault when offsetSet throws an Exception (only without debug)
ID: 32252
User updated by: shulmanb at il dot ibm dot com
Reported By: shulmanb at il dot ibm dot com
Status: Assigned
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.*
Assigned To: helly
New Comment:
Tested with the latest snapshot (200505110630) on Windows XP, and it is
still crashing.
Previous Comments:
[2005-05-03 14:55:02] [EMAIL PROTECTED]
Runs in php 5.1 now.
[2005-03-13 19:22:42] [EMAIL PROTECTED]
Related to http://bugs.php.net/30346
[2005-03-09 15:13:34] [EMAIL PROTECTED]
The first problem here is that the negative key results in incomplete
initialized zvals internally *before* even calling offsetSet().
[2005-03-09 14:38:38] shulmanb at il dot ibm dot com
Description:
In some cases, when offsetSet throws an exception a segfault occurs.
This does not happen when compiled with --enable-debug.
Note that if the index passed to $list is positive or a string, not
segfault occurs.
Reproduce code:
---
class a implements ArrayAccess
{
function offsetExists ($offset) { return false; }
function offsetGet ($offset) { return null; }
function offsetSet ($offset, $value) { throw new Exception ("Ooops");
}
function offsetUnset ($offset) {}
}
function test()
{
$list = new a();
try {
$list[-1] = 123;
} catch (Exception $e) { }
return true;
}
print test();
Expected result:
The output should be "1".
Actual result:
--
Segmentation fault.
The stack trace reported in Visual Studio, using the latest snapshot
and debug pack is:
php5ts.dll!shutdown_memory_manager(int silent=0, int full_shutdown=0,
void * * * tsrm_ls=0x00364b38) Line 490 + 0xb C
php5ts.dll!php_request_shutdown(void * dummy=0x) Line 1225 +
0x2fC
msvcrt.dll!77c37bbe()
user32.dll!77d5f160()
--
Edit this bug report at http://bugs.php.net/?id=32252&edit=1
#32988 [Fbk->Opn]: ext/oci8: OCI doesn't support DB external authentication
ID: 32988
User updated by: stephane dot dekeyzer at kmi dot be
Reported By: stephane dot dekeyzer at kmi dot be
-Status: Feedback
+Status: Open
Bug Type: Feature/Change Request
Operating System: Any
PHP Version: 5.0.4
New Comment:
simplified version:
if(external authentication){
do ext authentication
}
else{
do login/password authentication
}
after line 2819, here a re my new lines:
if(strcmp(username, "/") == 0 && strlen(password) == 0 ||
strlen(username) == 0 && strlen(password) == 0){
/* doing external authentication (OCI_CRED_EXT) */
CALL_OCI_RETURN(OCI(error),
OCISessionBegin(
svchp,
OCI(pError),
session->pSession,
(ub4) OCI_CRED_EXT,
(ub4) OCI_DEFAULT
)
);
}
else {
/* set the username in user handle */
CALL_OCI_RETURN(OCI(error),
OCIAttrSet(
(dvoid *) session->pSession,
(ub4) OCI_HTYPE_SESSION,
(dvoid *) username,
(ub4) strlen(username),
(ub4) OCI_ATTR_USERNAME,
OCI(pError)
)
);
if (OCI(error) != OCI_SUCCESS) {
oci_error(OCI(pError), "OCIAttrSet OCI_ATTR_USERNAME",
OCI(error));
goto CLEANUP;
}
/* set the password in user handle */
CALL_OCI_RETURN(OCI(error),
OCIAttrSet(
(dvoid *) session->pSession,
(ub4) OCI_HTYPE_SESSION,
(dvoid *) password,
(ub4) strlen(password),
(ub4) OCI_ATTR_PASSWORD,
OCI(pError)
)
);
if (OCI(error) != OCI_SUCCESS) {
oci_error(OCI(pError), "OCIAttrSet OCI_ATTR_PASSWORD",
OCI(error));
goto CLEANUP;
}
CALL_OCI_RETURN(OCI(error),
OCISessionBegin(
svchp,
OCI(pError),
session->pSession,
(ub4) OCI_CRED_RDBMS,
(ub4) OCI_DEFAULT
)
);
}
Previous Comments:
[2005-05-10 17:51:57] [EMAIL PROTECTED]
Please post your patch online somewhere as a unified diff against CVS
HEAD, and paste the link to that diff into this bug report; thanks :)
[2005-05-09 17:00:26] stephane dot dekeyzer at kmi dot be
Description:
OCILogon, OCIPLogon, doesn't support external authentication to the
database ...
I know this a ecurity hole if you use php with apache, but when you use
it in scripting mode, it is very usefull, and itsn't a security breach.
I met Christopher Jones last week at the PHP conference in Amsterdam
who agreed and asked me to post this bug so OCI developpers can discuss
about it.
It would a be a good idea when php runs without apache, external
authentication would be allowed.
I have a modification of the oci8.c wich support external
authentication, just mail me if you want to have it !
Reproduce code:
---
$conn = OCILogon("", "", mydb); // should work
$conn = OCILogon("/", "", mydb); // should also work
$conn = OCILogon(null, null, mydb); // should also work
Expected result:
$conn = OCILogon(null, null, mydb); // should work and log me in as the
os user curently running the script
Actual result:
--
$conn = OCILogon(null, null, mydb); // gives an error.
--
Edit this bug report at http://bugs.php.net/?id=32988&edit=1
#33002 [Bgs]: IMAP PHP connection crash Apache 2
ID: 33002
Updated by: [EMAIL PROTECTED]
Reported By: netadmin at vcsn dot com
Status: Bogus
Bug Type: IMAP related
Operating System: Linux 2.4.29
PHP Version: 4.3.11
New Comment:
We've seen this before, it's a bug in how Slackware build nss_db:
#1 0x409f4e1e in db_open () from /lib/libnss_db.so.2
#2 0x409f4ed0 in internal_setent () from /lib/libnss_db.so.2
#3 0x409f390e in _nss_db_endprotoent () from /lib/libnss_db.so.2
#4 0x409f3b78 in _nss_db_getprotobyname_r () from /lib/libnss_db.so.2
that means that nss_db.so is built using a non-unique-name-ified
version of BDB, which is doomed to failure. You should report this bug
to the Slackware maintainers.
Previous Comments:
[2005-05-11 08:11:08] netadmin at vcsn dot com
It is not **obvious** to me- isn't it possible for PHP to return data
that could 'cause a crash subsequently?? It would really be more
helpful if you could point me to what you see **is** 'causing the crash
so I can test and report back.
[2005-05-11 01:27:34] [EMAIL PROTECTED]
The crash obviously happens outside PHP code -> not PHP bug.
[2005-05-10 23:00:26] netadmin at vcsn dot com
Description:
I've seen some postings about this problem but it appears the issue is
never followed up and thus gets closed- so I'm posting it again since
this is a high priority issue for me:
My environment is Apache 2.0.54 (I have also tried .47 and .49), PHP
4.3.11 (I have also tried, .1, .5, .8, and .10), Horde's IMP product
(version 3.2.1 and version 4 with the appropriate Horde version
respectively), Postgres 8.0.2 (migrated from 7.1.2- all data is intact
and I do see database connections) and the UW c-client (built from 4.58
and 4.63). The OS is Linux 2.4.29 (upgrade slackware 8 disto).
PHP appear's (I think) to be SIGSEGV'ing Apache when IMAP is being
used. Here is the gdb output that I get with different combinations of
the version's I specified about [inserted below]
(note that the last version I tried was .5 but I will repeat
with the lastest snapshot if requested since it also faulted)
Reproduce code:
---
As posted in a previous bug report, the following script will fault and
generate a SIGSEGV in an Apache process and log it:
Expected result:
I actually am not sure since I borrowed the code and I'm not a PHP
programmer. The way I was diagnosed the problem was by using my
sniffer to watch port 143 connections. I would expect to see a
connection to the IMAP server is things were working properly.
Actual result:
--
This GDB was configured as "i686-pc-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".
(gdb) run -DONE_PROCESS -DSSL
Starting program: /www2/bin/httpd -DONE_PROCESS -DSSL
[Thread debugging using libthread_db enabled]
[New Thread 1024 (LWP 12274)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 12274)]
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x409f4e1e in db_open () from /lib/libnss_db.so.2
#2 0x409f4ed0 in internal_setent () from /lib/libnss_db.so.2
#3 0x409f390e in _nss_db_endprotoent () from /lib/libnss_db.so.2
#4 0x409f3b78 in _nss_db_getprotobyname_r () from /lib/libnss_db.so.2
#5 0x403a647f in __getprotobyname_r (name=0x40767d84 "tcp",
resbuf=0x403d9b48, buffer=0x83fd720 "[EMAIL PROTECTED]", buflen=1024,
result=0xbfff6528)
at ../nss/getXXbyYY_r.c:200
#6 0x403a632d in getprotobyname (name=0x40767d84 "tcp") at
../nss/getXXbyYY.c:145
#7 0x406e838a in tcp_socket_open (family=2, adr=0x8442d50, adrlen=4,
port=143, tmp=0xbfff671c
"\221+D\b|[EMAIL PROTECTED]@|[EMAIL PROTECTED]@\n",
ctr=0xbfff6718, hst=0x8442d45 "vcsn.com") at tcp_unix.c:225
#8 0x406e81ee in tcp_open (host=0xbfff6fec "vcsn.com", service=0x0,
port=143) at tcp_unix.c:184
#9 0x406f9913 in net_open_work (dv=0x407c53c0, host=0xbfff6fec
"vcsn.com", service=0xbfff736e "imap", port=143, portoverride=143,
flags=0)
at mail.c:5967
#10 0x406f8113 in net_open (mb=0xbfff6fec, dv=0x0, port=143, ssld=0x0,
ssls=0x407ab92c "*imaps", sslp=993) at mail.c:5938
#11 0x4070a652 in imap_open (stream=0x8442a98) at imap4r1.c:823
#12 0x406ed6f9 in mail_open (stream=0x8442a98, name=0x83f9364
"{vcsn.com:143/imap/notls}", options=0) at mail.c:1217
#13 0x405e25fb in php_imap_do_open (ht=4, return_value=0x8397c4c,
this_ptr=0x0, return_value_used=1, persistent=0)
at /root/src/INSTALLED/php-4.3.5/ext/imap/php_imap.c:734
#14 0x405e26a9 in zif_imap_open (ht=4, return_value=0x8397c4c,
this_ptr=0x0, return_value_used=1)
at /root/src/INSTALLED/php-4.3.5/ext/imap/php_imap.c:755
#15 0x406d88d3 in execute (op_array=0x846474c) at
/root/src/INSTALLED/php-4.3.5/Zend/zend_execute.c:1623
#16 0x406d8a4a in execute (op_arr
#32838 [Opn->Csd]: child processes opened with proc_open freeze the script
ID: 32838 Updated by: [EMAIL PROTECTED] Reported By: mjpph at stardust dot fi -Status: Open +Status: Closed Bug Type: Program Execution Operating System: Linux PHP Version: 5.0.4 New Comment: Ok, marking as closed. Previous Comments: [2005-05-11 10:08:18] mjpph at stardust dot fi It seems the snapshot sniper posted has solved the bug. I usually was able to freeze atleast one script in say 48 hours with almost 100% propability. Usually more than one script. This time around, with the sniper's snapshot, the scripts have been running for over 120 hours without a single failure. I think it's safe to say this bug has been solved. Thanks a lot, I wrestled with this bug for a long time. [2005-05-11 10:02:21] [EMAIL PROTECTED] Are you still able to reproduce it? [2005-05-08 16:34:06] mjpph at stardust dot fi It looks like the newest snapshot has fixed the issue. I've been now running the scripts for 55 hours without one single failure. Before this atleast one, most likely half of the scripts would have freezed already. I'll send some more feedback after few more days of testing. [2005-05-06 09:07:54] mjpph at stardust dot fi Ok I'll try that snapshot. One thing I notice too, all version seem to have PTY support of the proc_open disabled. It can be easily seen by checking ext/standard/proc_open.c which has two pty-related defines which start by "0 &&". I changed these and got fully working proc_open PTY support on my system. This didn't have any effect on the freezing problem though. Maybe the PTY support is still buggy or someone has tested something and forgot to enable it? Just as a sidenote. [2005-05-06 03:21:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip 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/32838 -- Edit this bug report at http://bugs.php.net/?id=32838&edit=1
#32942 [Bgs]: "CLI a rencontré un problème et doit fermer. Nous vous prions..."
ID: 32942 User updated by: yelva03 at yahoo dot fr Reported By: yelva03 at yahoo dot fr Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP Professionnal PHP Version: 5.0.4 New Comment: This message appears when executing go_pear.bat, pear.bat and php_win.exe : "CLI a rencontré un problème et doit fermer. Nous vous prions de nous excuser pour le désagrément encouru." ( Translation : CLI has generate a system problem and must be closed. Sorry.) This while configuring manually PHP as an Apache2 module. Previous Comments: [2005-05-05 11:22:19] [EMAIL PROTECTED] In English please. [2005-05-04 09:43:50] yelva03 at yahoo dot fr Description: Ce message de Windows XP apparaît à l'exécution de go_pear.bat, pear.bat et php_win.exe : "CLI a rencontré un problème et doit fermer. Nous vous prions de nous excuser pour le désagrément encouru." Ceci pendant la configuration de PHP manuellement comme module de Apache2. -- Edit this bug report at http://bugs.php.net/?id=32942&edit=1
#33005 [Fbk->Opn]: mysqli do not support float type
ID: 33005
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: winxp
PHP Version: 5CVS-2005-05-11 (dev)
New Comment:
PHP Version 5.0.5-dev
MySQLi Client API version 4.1.7
MySQL Server version: 5.0.4-beta
Previous Comments:
[2005-05-11 09:36:37] [EMAIL PROTECTED]
Can't reproduce
Connecting to MySQL 4.1 returns
int(1)
float(1.23)
Connectiong to MySQL 5.0 returns
int(1)
string(4) "1.23"
Which MySQL client library and server do you use?
[2005-05-11 07:58:39] dan at yes dot lt
Description:
mysqli do not supports float type neither in results nor in params. for
result it returns NULL instead of float, for params there is no type
letter for float type...
Reproduce code:
---
$db = new mysqli(...);
$st = $db->prepare("SELECT 1.23 AS test");
$st->execute();
$st->store_result();
var_dump($st->num_rows);
$st->bind_result($x);
$st->fetch();
$st->free_result();
$st->close();
var_dump($x);
Expected result:
int(1)
float(1.23)
Actual result:
--
int(1)
NULL
--
Edit this bug report at http://bugs.php.net/?id=33005&edit=1
#32838 [Fbk->Opn]: child processes opened with proc_open freeze the script
ID: 32838 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi -Status: Feedback +Status: Open Bug Type: Program Execution Operating System: Linux PHP Version: 5.0.4 New Comment: It seems the snapshot sniper posted has solved the bug. I usually was able to freeze atleast one script in say 48 hours with almost 100% propability. Usually more than one script. This time around, with the sniper's snapshot, the scripts have been running for over 120 hours without a single failure. I think it's safe to say this bug has been solved. Thanks a lot, I wrestled with this bug for a long time. Previous Comments: [2005-05-11 10:02:21] [EMAIL PROTECTED] Are you still able to reproduce it? [2005-05-08 16:34:06] mjpph at stardust dot fi It looks like the newest snapshot has fixed the issue. I've been now running the scripts for 55 hours without one single failure. Before this atleast one, most likely half of the scripts would have freezed already. I'll send some more feedback after few more days of testing. [2005-05-06 09:07:54] mjpph at stardust dot fi Ok I'll try that snapshot. One thing I notice too, all version seem to have PTY support of the proc_open disabled. It can be easily seen by checking ext/standard/proc_open.c which has two pty-related defines which start by "0 &&". I changed these and got fully working proc_open PTY support on my system. This didn't have any effect on the freezing problem though. Maybe the PTY support is still buggy or someone has tested something and forgot to enable it? Just as a sidenote. [2005-05-06 03:21:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-05-05 15:16:41] mjpph at stardust dot fi More info. I have a identical script running on a machine with PHP 5.0.0RC3, it has no problems mentioned here. All scripts run perfectly well. When I run the identical script on 5.0.4 it freezes after some time of runtime almost without exceptions. Both are CLI versions compiled from the source. The hltv-runner started to freeze after I upgraded PHP from 5.0.0RC3 to 5.0.4, it never did before the upgrade. 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/32838 -- Edit this bug report at http://bugs.php.net/?id=32838&edit=1
#32838 [Opn->Fbk]: child processes opened with proc_open freeze the script
ID: 32838 Updated by: [EMAIL PROTECTED] Reported By: mjpph at stardust dot fi -Status: Open +Status: Feedback Bug Type: Program Execution Operating System: Linux PHP Version: 5.0.4 New Comment: Are you still able to reproduce it? Previous Comments: [2005-05-08 16:34:06] mjpph at stardust dot fi It looks like the newest snapshot has fixed the issue. I've been now running the scripts for 55 hours without one single failure. Before this atleast one, most likely half of the scripts would have freezed already. I'll send some more feedback after few more days of testing. [2005-05-06 09:07:54] mjpph at stardust dot fi Ok I'll try that snapshot. One thing I notice too, all version seem to have PTY support of the proc_open disabled. It can be easily seen by checking ext/standard/proc_open.c which has two pty-related defines which start by "0 &&". I changed these and got fully working proc_open PTY support on my system. This didn't have any effect on the freezing problem though. Maybe the PTY support is still buggy or someone has tested something and forgot to enable it? Just as a sidenote. [2005-05-06 03:21:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-05-05 15:16:41] mjpph at stardust dot fi More info. I have a identical script running on a machine with PHP 5.0.0RC3, it has no problems mentioned here. All scripts run perfectly well. When I run the identical script on 5.0.4 it freezes after some time of runtime almost without exceptions. Both are CLI versions compiled from the source. The hltv-runner started to freeze after I upgraded PHP from 5.0.0RC3 to 5.0.4, it never did before the upgrade. [2005-05-02 18:10:33] mjpph at stardust dot fi I'm using PHP's CLI version. Also I noticed that when I upgraded an earlier 5.x PHP to 5.0.4 it started to freeze one process runner which has always worked perfectly. The script was unchanged. Test code can be anything that just simply opens a child process which has atleast relatively high output and keeps listening to it for a long time (several hours, days). I'll add two simple test scripts asap. 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/32838 -- Edit this bug report at http://bugs.php.net/?id=32838&edit=1
#32685 [Opn->Fbk]: Segfault when using assignment by reference within function
ID: 32685 Updated by: [EMAIL PROTECTED] Reported By: david at davidheath dot org -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: mandrake linux 10.1 PHP Version: 4CVS-2005-04-14 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2005-04-19 13:53:19] ericvanblokland at gmail dot com This maybe related to an issue I encountered. My guess is this code will work fine with php5 http://bugs.php.net/bug.php?id=31624 [2005-04-13 10:51:34] david at davidheath dot org > 1) Does it also crash when you replace file reading by > assignment from string? yes it does, see http://www.davidheath.org/php_bug/crash2.php.txt I've also noticed that I had a mistake in the original repro script (crash.php.txt), which I've now corrected (the filename on line 4 was wrong). This may explain why you couldn't repro. However, having changed that I now get: [EMAIL PROTECTED] repro]$ /usr/local/php-4.3-CVS-13apr05/bin/php crash.php Content-type: text/html X-Powered-By: PHP/4.3.12-dev free(): invalid pointer 0x81b14a8! ALSO, another important observation. The crash sometimes seems to not happen if I execute the script in a different directory. For example: [EMAIL PROTECTED] repro]$ pwd /tmp/repro [EMAIL PROTECTED] repro]$ ls crash2.php [EMAIL PROTECTED] repro]$ /usr/local/php-4.3-CVS-13apr05/bin/php crash2.php Content-type: text/html X-Powered-By: PHP/4.3.12-dev [EMAIL PROTECTED] repro]$ mkdir -p foo/bar [EMAIL PROTECTED] repro]$ cd foo/bar [EMAIL PROTECTED] bar]$ cp ../../crash2.php . [EMAIL PROTECTED] bar]$ /usr/local/php-4.3-CVS-13apr05/bin/php crash2.php Content-type: text/html X-Powered-By: PHP/4.3.12-dev Segmentation fault (core dumped) [2005-04-13 10:32:48] david at davidheath dot org Hi, I tried again with CVS HEAD (from PHP_4_3 branch). Still crashes. [EMAIL PROTECTED] dh]$ /usr/local/php-4.3-CVS-13apr05/bin/php crash.php Content-type: text/html X-Powered-By: PHP/4.3.12-dev Segmentation fault (core dumped) [EMAIL PROTECTED] dh]$ [2005-04-12 20:37:20] [EMAIL PROTECTED] Two questions: 1) Does it also crash when you replace file reading by assignment from string? 2) Did you try 5.0 or HEAD? [2005-04-12 18:16:17] david at davidheath dot org Description: The attached program always segfaults. I have stripped out as much code as possible whilst ensuring that it still segfaults, I'm afraid I haven't been able to make the repro code any simpler. The problem is either something to do with the assignment by reference on line 11 in the test2::exists() method, or otherwise something to do with the use of unserialize(). I'm using the standard build of php4.3.11 with no special modules. Reproduce code: --- $ wget http://www.davidheath.org/php_bug/crash.php.txt $ wget http://www.davidheath.org/php_bug/testfile $ mv crash.php.txt crash.php $ php crash.php Expected result: no segfault, no output at all Actual result: -- [EMAIL PROTECTED] dh]$ /usr/local/php4.3.11/bin/php.4.3.11 crash.php Content-type: text/html X-Powered-By: PHP/4.3.11 Segmentation fault (core dumped) When I run with debug build, it doesn't segfault: [EMAIL PROTECTED] dh]$ /usr/local/php4.3.11_debug/bin/php.4.3.11 crash.php Content-type: text/html X-Powered-By: PHP/4.3.11 /home/heathd/downloads/php-4.3.11/Zend/zend_execute.c(279) : Freeing 0x081EA8A4 (12 bytes), script=crash.php /home/heathd/downloads/php-4.3.11/Zend/zend_execute.c(282) : Freeing 0x081EA704 (28 bytes), script=crash.php /home/heathd/downloads/php-4.3.11/Zend/zend_variables.c(111) : Actual location (location was relayed) -- Edit this bug report at http://bugs.php.net/?id=32685&edit=1
#33005 [Opn->Fbk]: mysqli do not support float type
ID: 33005
Updated by: [EMAIL PROTECTED]
Reported By: dan at yes dot lt
-Status: Open
+Status: Feedback
Bug Type: MySQLi related
Operating System: winxp
PHP Version: 5CVS-2005-05-11 (dev)
New Comment:
Can't reproduce
Connecting to MySQL 4.1 returns
int(1)
float(1.23)
Connectiong to MySQL 5.0 returns
int(1)
string(4) "1.23"
Which MySQL client library and server do you use?
Previous Comments:
[2005-05-11 07:58:39] dan at yes dot lt
Description:
mysqli do not supports float type neither in results nor in params. for
result it returns NULL instead of float, for params there is no type
letter for float type...
Reproduce code:
---
$db = new mysqli(...);
$st = $db->prepare("SELECT 1.23 AS test");
$st->execute();
$st->store_result();
var_dump($st->num_rows);
$st->bind_result($x);
$st->fetch();
$st->free_result();
$st->close();
var_dump($x);
Expected result:
int(1)
float(1.23)
Actual result:
--
int(1)
NULL
--
Edit this bug report at http://bugs.php.net/?id=33005&edit=1
#33006 [Opn->Bgs]: binary data in $_POST[] is corrupt
ID: 33006
User updated by: billy dot becker at gmail dot com
Reported By: billy dot becker at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Variables related
Operating System: gentoo linux 2.4.28-gentoo-r2
PHP Version: 5.0.3
New Comment:
I am retarded. I didn't fully understand magic quotes until i reread
the manual. GPC magic quotes was set to on, and so all my NULLS (0x00)
were getting escaped. I turned GPC magic quotes off in my php.ini and
tested it and $_POST['message'] was not corrupt.
I'm setting this bug to bogus now.
Obligatory "RTFM" accepted.
Previous Comments:
[2005-05-11 08:19:03] billy dot becker at gmail dot com
Description:
I have a form that submits a wavfile as a variable. The form uses
enctype application/form-data-urlencoded. Normal variables (integer and
string) get tranmitted fine and I can access them normally from $_POST.
However, my wavfile is coming through corrupt. The bug is that although
the documentation says that PHP does only a urldecode before populating
the $_POST array, something else must be happening in addition.
However, If I manually parse the $HTTP_RAW_POST_DATA string, I can pull
my data out, urldecode() it, and the data is fine. When I compare the
urldecoded RAW_POST_DATA to the $_POST data, I find that the $_POST
data has man low-bit characters replaced with high-bit characters, and
the $_POST data has about 200bytes of extra information strewn
throughout the string.
So, the data is getting transmitted to the server fine, and PHP see's
it fine, but it does something when it puts it into the $_POST array to
corrupt the data.
I started a thread on comp.lang.php named "how does PHP5 process POST
data in creating $_POST array?"
this link may or may not work:
http://groups-beta.google.com/group/comp.lang.php/browse_frm/thread/01636851f3909135/22e6b7fa4724b4e6#22e6b7fa4724b4e6
I'm not sure how you will be able to reproduce the error without having
access to a source that will send wav data as a form variable.
Let me know if there is anything else I can do or give you to help fix
this bug.
Reproduce code:
---
Assuming you have a source that has posted a wav file with the variable
name: message
this code will show you the difference:
function &parse_http_raw_post_data(&$data, $split1str = '&', $split2str
= '=')
{
$split1dat = explode($split1str, $data);
$num = count($split1dat);
if (! $num) { return false; }
for ($i = 0; $i < $num; $i++) {
$split2dat=explode($split2str, $split1dat[$i]);
$ret[$split2dat[$i]] = $split2dat[$i + 1];
}
return $ret;
}
$rawdata=$HTTP_RAW_POST_DATA;
$parsedata=parse_http_raw_post_data($rawdata);
$wavdata=$parsedata['message'];
$postdata=$_POST['message'];
file_put_contents("$writepath/$filename-raw.wav", $wavdata);
file_put_contents("$writepath/$filename-post.wav", $postdata);
file_put_contents("$writepath/$filename-u.wav",
urldecode($wavdata));
Expected result:
wavdata and postdata should be exactly the same.
Actual result:
--
wavdata contains: RIFFFóWAVEfmt @data óÿþÿþÿþ
postdata contains: RIFFFó\0\0WAVEfmt [EMAIL PROTECTED]@\0\0\\0\0\0data
ó\
there's a lot more to the output, but that's the gist of it. PHP is
inserting lots of \0 where it doesn't need to be.
I can send you the two files to compare if you wish.
--
Edit this bug report at http://bugs.php.net/?id=33006&edit=1
#33007 [NEW]: PHP fails to build .so
From: nickt at nicktemple dot com Operating system: Liinux 2.4.21 RHEL PHP version: 4.3.11 PHP Bug Type: Compile Failure Bug description: PHP fails to build .so Description: When building php4.11, it refuses to build the .so needed for apache. Tried every configuration I could think of. Using the exact same configuration on 4.3.10, however, PHP builds without a problem. Reproduce code: --- ./configure --prefix=/home/imts \ --with-apxs=/home/imts/bin/apxs \ --enable-so \ --enable-shared \ --with-xml \ --enable-bcmath\ --enable-calendar \ --with-curl \ --enable-ftp \ --with-gd \ --with-jpeg-dir=/usr/local \ --with-mysql=/usr \ --enable-discard-path \ --with-pear \ --enable-sockets \ --enable-track-vars \ --enable-versioning \ --with-xmlrpc \ --enable-sockets \ --with-zlib Expected result: Installing PHP SAPI module: apache [activating module `php4' in /home/imts/conf/httpd.conf] cp libs/libphp4.so /home/imts/libexec/libphp4.so chmod 755 /home/imts/libexec/libphp4.so cp /home/imts/conf/httpd.conf /home/imts/conf/httpd.conf.bak cp /home/imts/conf/httpd.conf.new /home/imts/conf/httpd.conf rm /home/imts/conf/httpd.conf.new [etc] Actual result: -- Installing PHP SAPI module: apache [activating module `php4' in /home/imts/conf/httpd.conf] cp libs/libphp4.so /home/imts/libexec/libphp4.so cp: cannot stat `libs/libphp4.so': No such file or directory apxs:Break: Command failed with rc=1 make: *** [install-sapi] Error 1 -- Edit bug report at http://bugs.php.net/?id=33007&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33007&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33007&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33007&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33007&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33007&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33007&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33007&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33007&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33007&r=support Expected behavior: http://bugs.php.net/fix.php?id=33007&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33007&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33007&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33007&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33007&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33007&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33007&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33007&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33007&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33007&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33007&r=mysqlcfg
#33006 [NEW]: binary data in $_POST[] is corrupt
From: billy dot becker at gmail dot com
Operating system: gentoo linux 2.4.28-gentoo-r2
PHP version: 5.0.3
PHP Bug Type: Variables related
Bug description: binary data in $_POST[] is corrupt
Description:
I have a form that submits a wavfile as a variable. The form uses enctype
application/form-data-urlencoded. Normal variables (integer and string)
get tranmitted fine and I can access them normally from $_POST.
However, my wavfile is coming through corrupt. The bug is that although
the documentation says that PHP does only a urldecode before populating
the $_POST array, something else must be happening in addition.
However, If I manually parse the $HTTP_RAW_POST_DATA string, I can pull my
data out, urldecode() it, and the data is fine. When I compare the
urldecoded RAW_POST_DATA to the $_POST data, I find that the $_POST data
has man low-bit characters replaced with high-bit characters, and the
$_POST data has about 200bytes of extra information strewn throughout the
string.
So, the data is getting transmitted to the server fine, and PHP see's it
fine, but it does something when it puts it into the $_POST array to
corrupt the data.
I started a thread on comp.lang.php named "how does PHP5 process POST data
in creating $_POST array?"
this link may or may not work:
http://groups-beta.google.com/group/comp.lang.php/browse_frm/thread/01636851f3909135/22e6b7fa4724b4e6#22e6b7fa4724b4e6
I'm not sure how you will be able to reproduce the error without having
access to a source that will send wav data as a form variable.
Let me know if there is anything else I can do or give you to help fix
this bug.
Reproduce code:
---
Assuming you have a source that has posted a wav file with the variable
name: message
this code will show you the difference:
function &parse_http_raw_post_data(&$data, $split1str = '&', $split2str =
'=')
{
$split1dat = explode($split1str, $data);
$num = count($split1dat);
if (! $num) { return false; }
for ($i = 0; $i < $num; $i++) {
$split2dat=explode($split2str, $split1dat[$i]);
$ret[$split2dat[$i]] = $split2dat[$i + 1];
}
return $ret;
}
$rawdata=$HTTP_RAW_POST_DATA;
$parsedata=parse_http_raw_post_data($rawdata);
$wavdata=$parsedata['message'];
$postdata=$_POST['message'];
file_put_contents("$writepath/$filename-raw.wav", $wavdata);
file_put_contents("$writepath/$filename-post.wav", $postdata);
file_put_contents("$writepath/$filename-u.wav", urldecode($wavdata));
Expected result:
wavdata and postdata should be exactly the same.
Actual result:
--
wavdata contains: RIFFFóWAVEfmt @data óÿþÿþÿþ
postdata contains: RIFFFó\0\0WAVEfmt [EMAIL PROTECTED]@\0\0\\0\0\0data
ó\
there's a lot more to the output, but that's the gist of it. PHP is
inserting lots of \0 where it doesn't need to be.
I can send you the two files to compare if you wish.
--
Edit bug report at http://bugs.php.net/?id=33006&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33006&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33006&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33006&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33006&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33006&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33006&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33006&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33006&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33006&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33006&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33006&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33006&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33006&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33006&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33006&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33006&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33006&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33006&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33006&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33006&r=mysqlcfg
#33002 [Bgs]: IMAP PHP connection crash Apache 2
ID: 33002
User updated by: netadmin at vcsn dot com
Reported By: netadmin at vcsn dot com
Status: Bogus
Bug Type: IMAP related
Operating System: Linux 2.4.29
PHP Version: 4.3.11
New Comment:
It is not **obvious** to me- isn't it possible for PHP to return data
that could 'cause a crash subsequently?? It would really be more
helpful if you could point me to what you see **is** 'causing the crash
so I can test and report back.
Previous Comments:
[2005-05-11 01:27:34] [EMAIL PROTECTED]
The crash obviously happens outside PHP code -> not PHP bug.
[2005-05-10 23:00:26] netadmin at vcsn dot com
Description:
I've seen some postings about this problem but it appears the issue is
never followed up and thus gets closed- so I'm posting it again since
this is a high priority issue for me:
My environment is Apache 2.0.54 (I have also tried .47 and .49), PHP
4.3.11 (I have also tried, .1, .5, .8, and .10), Horde's IMP product
(version 3.2.1 and version 4 with the appropriate Horde version
respectively), Postgres 8.0.2 (migrated from 7.1.2- all data is intact
and I do see database connections) and the UW c-client (built from 4.58
and 4.63). The OS is Linux 2.4.29 (upgrade slackware 8 disto).
PHP appear's (I think) to be SIGSEGV'ing Apache when IMAP is being
used. Here is the gdb output that I get with different combinations of
the version's I specified about [inserted below]
(note that the last version I tried was .5 but I will repeat
with the lastest snapshot if requested since it also faulted)
Reproduce code:
---
As posted in a previous bug report, the following script will fault and
generate a SIGSEGV in an Apache process and log it:
Expected result:
I actually am not sure since I borrowed the code and I'm not a PHP
programmer. The way I was diagnosed the problem was by using my
sniffer to watch port 143 connections. I would expect to see a
connection to the IMAP server is things were working properly.
Actual result:
--
This GDB was configured as "i686-pc-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".
(gdb) run -DONE_PROCESS -DSSL
Starting program: /www2/bin/httpd -DONE_PROCESS -DSSL
[Thread debugging using libthread_db enabled]
[New Thread 1024 (LWP 12274)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 12274)]
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x409f4e1e in db_open () from /lib/libnss_db.so.2
#2 0x409f4ed0 in internal_setent () from /lib/libnss_db.so.2
#3 0x409f390e in _nss_db_endprotoent () from /lib/libnss_db.so.2
#4 0x409f3b78 in _nss_db_getprotobyname_r () from /lib/libnss_db.so.2
#5 0x403a647f in __getprotobyname_r (name=0x40767d84 "tcp",
resbuf=0x403d9b48, buffer=0x83fd720 "[EMAIL PROTECTED]", buflen=1024,
result=0xbfff6528)
at ../nss/getXXbyYY_r.c:200
#6 0x403a632d in getprotobyname (name=0x40767d84 "tcp") at
../nss/getXXbyYY.c:145
#7 0x406e838a in tcp_socket_open (family=2, adr=0x8442d50, adrlen=4,
port=143, tmp=0xbfff671c
"\221+D\b|[EMAIL PROTECTED]@|[EMAIL PROTECTED]@\n",
ctr=0xbfff6718, hst=0x8442d45 "vcsn.com") at tcp_unix.c:225
#8 0x406e81ee in tcp_open (host=0xbfff6fec "vcsn.com", service=0x0,
port=143) at tcp_unix.c:184
#9 0x406f9913 in net_open_work (dv=0x407c53c0, host=0xbfff6fec
"vcsn.com", service=0xbfff736e "imap", port=143, portoverride=143,
flags=0)
at mail.c:5967
#10 0x406f8113 in net_open (mb=0xbfff6fec, dv=0x0, port=143, ssld=0x0,
ssls=0x407ab92c "*imaps", sslp=993) at mail.c:5938
#11 0x4070a652 in imap_open (stream=0x8442a98) at imap4r1.c:823
#12 0x406ed6f9 in mail_open (stream=0x8442a98, name=0x83f9364
"{vcsn.com:143/imap/notls}", options=0) at mail.c:1217
#13 0x405e25fb in php_imap_do_open (ht=4, return_value=0x8397c4c,
this_ptr=0x0, return_value_used=1, persistent=0)
at /root/src/INSTALLED/php-4.3.5/ext/imap/php_imap.c:734
#14 0x405e26a9 in zif_imap_open (ht=4, return_value=0x8397c4c,
this_ptr=0x0, return_value_used=1)
at /root/src/INSTALLED/php-4.3.5/ext/imap/php_imap.c:755
#15 0x406d88d3 in execute (op_array=0x846474c) at
/root/src/INSTALLED/php-4.3.5/Zend/zend_execute.c:1623
#16 0x406d8a4a in execute (op_array=0x843bc34) at
/root/src/INSTALLED/php-4.3.5/Zend/zend_execute.c:1665
#17 0x406d8a4a in execute (op_array=0x844e13c) at
/root/src/INSTALLED/php-4.3.5/Zend/zend_execute.c:1665
#18 0x406c6cfe in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/src/INSTALLED/php-4.3.5/Zend/zend.c:889
#19 0x4069e635 in php_execute_script (primary_file=0xb668) at
/root/src/INSTALLED/php-4.3.5/main/main.c:1731
#20 0x406e002f in php_handler (r=0x8374ee8) at
/root/src/INSTALLED/php-4.3.5/sapi/apache2handler/sapi_apache2.c:561
#21 0x0809f669 in ap_run_handler (r=0x8374ee8) at config.c:152
#22 0x0809fbb
#33005 [NEW]: mysqli do not support float type
From: dan at yes dot lt
Operating system: winxp
PHP version: 5CVS-2005-05-11 (dev)
PHP Bug Type: MySQLi related
Bug description: mysqli do not support float type
Description:
mysqli do not supports float type neither in results nor in params. for
result it returns NULL instead of float, for params there is no type
letter for float type...
Reproduce code:
---
$db = new mysqli(...);
$st = $db->prepare("SELECT 1.23 AS test");
$st->execute();
$st->store_result();
var_dump($st->num_rows);
$st->bind_result($x);
$st->fetch();
$st->free_result();
$st->close();
var_dump($x);
Expected result:
int(1)
float(1.23)
Actual result:
--
int(1)
NULL
--
Edit bug report at http://bugs.php.net/?id=33005&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33005&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33005&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33005&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33005&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33005&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33005&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33005&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33005&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33005&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33005&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33005&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33005&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33005&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33005&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33005&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33005&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33005&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33005&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33005&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33005&r=mysqlcfg
