#35513 [NEW]: A method of grouping variables so that the order of operators can be made clear
From: david at tulloh dot id dot au Operating system: PHP version: 6CVS-2005-12-02 (CVS) PHP Bug Type: Feature/Change Request Bug description: A method of grouping variables so that the order of operators can be made clear Description: When using objects it can become very ambiguous what is occuring once you start using variable variable names. The reproduce code shows a non-useful example of where this might occur. A concise example of the problem: $ob->field[0] ==> array[0] ==> item $ob->$field[0] ==> $ob->'b' ==> array Being able to use brackets or something similar to force the -> operator to act before the [] would allow for a choice of functionality in the second example and provide the ability to make the code clearer. $ob->($field[0]) ($ob->$field)[0] Both of these examples are currently not possible, a syntax error, unexpected ( or [ occurs. Reproduce code: --- $field[0]); // b var_dump($ob->field[0]); // bar ?> -- Edit bug report at http://bugs.php.net/?id=35513&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35513&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35513&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35513&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35513&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35513&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35513&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35513&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35513&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35513&r=support Expected behavior:http://bugs.php.net/fix.php?id=35513&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35513&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35513&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35513&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35513&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35513&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35513&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35513&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35513&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35513&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35513&r=mysqlcfg
#35103 [Opn]: mysqli bind_result incorrectly handles unsigned int
ID: 35103
User updated by: php at pjberkel dot com
Reported By: php at pjberkel dot com
Status: Open
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.1CVS-2005-12-02 (cvs)
Assigned To: andrey
New Comment:
Additionally, it appears that mysqli_stmt_bind_param() suffers from the
same unsigned integer problem as mysqli_stmt_bind_result() when there
bind type is set to "i" and the actual bind data is > MAX_UNSIGNED_INT
on a 32 bit platform.
Below is an example of the bug using php5.1-200512020130 and
mysql-5.0.16 on RHEL 4 (intel):
Reproduce code:
---
query("CREATE TABLE temp (id INT UNSIGNED NOT NULL)");
$mysqli->query("INSERT INTO temp (id) VALUES
(300897),(381532),(392281),(3100059612)");
$id_val = 392281;
/* BEGIN EXAMPLE OF BUG */
$stmt = $mysqli->prepare("SELECT id FROM temp WHERE id = ?");
$stmt->bind_param("i", $id_val);
$stmt->execute();
$stmt->bind_result($id);
$stmt->fetch();
var_dump($id);
$stmt->close();
/* END EXAMPLE OF BUG */
$mysqli->query("DROP TABLE temp");
$mysqli->close();
?>
Expected result:
string(10) "300897"
Actual result:
--
int(0)
Interestingly, if the bind type in $stmt->bind_param() is changed to
"d" the above reproduce code works as expected.
Previous Comments:
[2005-12-02 06:50:50] php at pjberkel dot com
I tested my original reproduce code using the lastest stable snapshot
available (php5.1-200512020130), but there appears to be another bug
(or feature) introduced because no output is being generated at all.
It appears as though $stmt->fetch() is returning NULL despite the fact
that it correcly bound the result set. I notice in the manual page
that mysqli_stmt_fetch() returns NULL when "No more rows/data exists or
data truncation occurred". Can anybody confirm this is a bug or
feature?
FYI I'm testing this with MySQL 5.0.16 on RHEL 4.
[2005-11-30 17:26:36] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2005-11-21 21:52:34] [EMAIL PROTECTED]
I have a fix for this problem as well as speedup of the current code
that handles unsigned ints on 32bit but I will push it after 5.1.0 is
released because it's a bit too late in the release cycle.
[2005-11-15 18:37:22] [EMAIL PROTECTED]
I am taking care of this problem.
Thanks!
[2005-11-10 08:54:25] [EMAIL PROTECTED]
Andrey, really REALLY big ints don't work yet! :)
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/35103
--
Edit this bug report at http://bugs.php.net/?id=35103&edit=1
#35103 [Csd->Opn]: mysqli bind_result incorrectly handles unsigned int
ID: 35103
User updated by: php at pjberkel dot com
Reported By: php at pjberkel dot com
-Status: Closed
+Status: Open
Bug Type: MySQLi related
Operating System: *
-PHP Version: 5CVS-2005-11-04 (cvs)
+PHP Version: 5.1CVS-2005-12-02 (cvs)
Assigned To: andrey
New Comment:
I tested my original reproduce code using the lastest stable snapshot
available (php5.1-200512020130), but there appears to be another bug
(or feature) introduced because no output is being generated at all.
It appears as though $stmt->fetch() is returning NULL despite the fact
that it correcly bound the result set. I notice in the manual page
that mysqli_stmt_fetch() returns NULL when "No more rows/data exists or
data truncation occurred". Can anybody confirm this is a bug or
feature?
FYI I'm testing this with MySQL 5.0.16 on RHEL 4.
Previous Comments:
[2005-11-30 17:26:36] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2005-11-21 21:52:34] [EMAIL PROTECTED]
I have a fix for this problem as well as speedup of the current code
that handles unsigned ints on 32bit but I will push it after 5.1.0 is
released because it's a bit too late in the release cycle.
[2005-11-15 18:37:22] [EMAIL PROTECTED]
I am taking care of this problem.
Thanks!
[2005-11-10 08:54:25] [EMAIL PROTECTED]
Andrey, really REALLY big ints don't work yet! :)
[2005-11-10 04:36:13] php at pjberkel dot com
I compiled the latest CVS snapshot from the 5.1 branch
(php5-200511100130) and can confirm that the problem has been fixed for
32bit unsigned INT values.
However, I also did some further testing using the unsigned BIGINT data
type (which contain 64bit integer values) and discovered the same
problem exists for unsigned values larger than the maximum signed 64bit
value:
(9223372036854775807 < int <= 18446744073709551615)
(BTW I'm using
http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html as a
reference page for MySQL numerical types.)
Changing the following two lines in the original reproduce code
fragment:
$mysqli->query("CREATE TABLE temp (id BIGINT UNSIGNED NOT NULL)");
$mysqli->query("INSERT INTO temp (id) VALUES
(9223372036854775807),(9223372036854775808),(18446744073709551614),(18446744073709551615)");
Expected result:
string(19) "9223372036854775807"
string(19) "9223372036854775808"
string(20) "18446744073709551614"
string(20) "18446744073709551615"
Actual result:
--
string(19) "9223372036854775807"
string(20) "-9223372036854775808"
int(-2)
int(-1)
I don't want to push the envelope too much on this as I guess it would
be extremely rare for anyone to encounter this bug, but if there is a
quick, easy solution then it's probably a good idea to fix the unsigned
BIGINT problem too.
Any plans to backport this to the 5.0.x branch?
Thanks
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/35103
--
Edit this bug report at http://bugs.php.net/?id=35103&edit=1
#35482 [Bgs->Opn]: Bad performance of filesystem functions on Windows XP Professional
ID: 35482
User updated by: tobias-bender at web dot de
Reported By: tobias-bender at web dot de
-Status: Bogus
+Status: Open
Bug Type: Filesystem function related
Operating System: Windows XP Professional
PHP Version: 5.1.1
New Comment:
I know but a difference of 1:9 is not normal. This might be not a real
bug but has to be kept in mind when working on the code. I think there
could be done a lot of optimization.
Where to put an issue like that when the bug db is not the right place?
Previous Comments:
[2005-12-01 13:11:28] [EMAIL PROTECTED]
Comparing PHP 5 with PHP 4 is like comparing apples and oranges. This
is inherent problem in Windows, not a bug.
[2005-12-01 00:03:12] tobias-bender at web dot de
I think this has to be analysed on a Windows platform
[2005-11-30 10:30:11] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Can't reproduce on Linux.
[2005-11-30 01:25:57] tobias-bender at web dot de
Description:
All filesystem functions got much slower with PHP 5.x.
With short relative paths PHP 4 is about twice as fast as PHP 5. PHP 5
is nearly 10 times slower when using absolute paths compared to PHP 4.
Reproduce code:
---
function getMicrotime(){
list($usec, $sec) = explode(' ', microtime());
return ((float)$usec + (float)$sec);
}
$iTime = getMicrotime();
$rHandle = opendir('C:/Apache2/htdocs/phpXplorer/test/vollvoll');
while (false !== ($sName = readdir($rHandle))) {
if (is_dir('C:/Apache2/htdocs/phpXplorer/test/vollvoll/' . $sName)){
echo 'C:/Apache2/htdocs/phpXplorer/test/vollvoll/' . $sName .
'';
}
}
echo getMicrotime() - $iTime;
--
Edit this bug report at http://bugs.php.net/?id=35482&edit=1
#35506 [Opn->Fbk]: FATAL: erealloc(): Unable to allocate 24576 bytes
ID: 35506 Updated by: [EMAIL PROTECTED] Reported By: broadmind at magicn dot com -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: windows 2000 server PHP Version: 5CVS-2005-12-01 (snap) New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2005-12-02 01:16:03] broadmind at magicn dot com Sorry for my inadequate report. My PHP pages consist of a lot of mysql queries. Then, after requesting the one page, the memory usage of Apache is only incremented. After all, when it is over about 240MB for lots of PHP page requests, the apache server is shut down and restarted. At this time, "FATAL: erealloc(): Unable to allocate 24576 bytes" log is written to error.log file. Why it is a serious problem is that this phenomenon is reiterated continuously. [2005-12-01 18:06:49] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2005-12-01 17:35:56] broadmind at magicn dot com Description: My server environment is, CPU : AMD Opteron 240 x2 (2 cpu) RAM : 2 GB Apache 1.3.34 Mysql 5.0.16 PHP : 5.1.2-dev Snap stable version. In error logs, I could find the following error message frequently. FATAL: erealloc(): Unable to allocate 24576 bytes So, opening windows task manager, I have monitored the memory usage of Apache server. I found this log is happen when it is over 240MB duing to heavily access to mysql through a PHP page. Because the memory size of my server is 2GB, it is nonsense to say that this problem is duing to the lack of memory. In my guess, there may be a memory leak in the memory manager. Actual result: -- FATAL: erealloc(): Unable to allocate 24576 bytes the above log is leaved in error.log file and Apache server is restarted, causing the lose of POST data or "page not found". -- Edit this bug report at http://bugs.php.net/?id=35506&edit=1
#35506 [Fbk->Opn]: FATAL: erealloc(): Unable to allocate 24576 bytes
ID: 35506 User updated by: broadmind at magicn dot com Reported By: broadmind at magicn dot com -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: windows 2000 server PHP Version: 5CVS-2005-12-01 (snap) New Comment: Sorry for my inadequate report. My PHP pages consist of a lot of mysql queries. Then, after requesting the one page, the memory usage of Apache is only incremented. After all, when it is over about 240MB for lots of PHP page requests, the apache server is shut down and restarted. At this time, "FATAL: erealloc(): Unable to allocate 24576 bytes" log is written to error.log file. Why it is a serious problem is that this phenomenon is reiterated continuously. Previous Comments: [2005-12-01 18:06:49] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2005-12-01 17:35:56] broadmind at magicn dot com Description: My server environment is, CPU : AMD Opteron 240 x2 (2 cpu) RAM : 2 GB Apache 1.3.34 Mysql 5.0.16 PHP : 5.1.2-dev Snap stable version. In error logs, I could find the following error message frequently. FATAL: erealloc(): Unable to allocate 24576 bytes So, opening windows task manager, I have monitored the memory usage of Apache server. I found this log is happen when it is over 240MB duing to heavily access to mysql through a PHP page. Because the memory size of my server is 2GB, it is nonsense to say that this problem is duing to the lack of memory. In my guess, there may be a memory leak in the memory manager. Actual result: -- FATAL: erealloc(): Unable to allocate 24576 bytes the above log is leaved in error.log file and Apache server is restarted, causing the lose of POST data or "page not found". -- Edit this bug report at http://bugs.php.net/?id=35506&edit=1
#35380 [Opn]: Provide information about the current temporary directory
ID: 35380 User updated by: daniel dot gorski at develnet dot org Reported By: daniel dot gorski at develnet dot org Status: Open Bug Type: Feature/Change Request Operating System: Any PHP Version: 5CVS-2005-11-25 (snap) New Comment: Any opinions? regards dtg Previous Comments: [2005-11-25 04:28:32] daniel dot gorski at develnet dot org Description: It is not possible to programatically get the information about the directory used by PHP where to store temporary files - if the session save path is not set in the php.ini (default). There is no chance to get an unusal path (unlike /tmp/) for temporary directory on OSes like Windows. Creating a _single_ temporary file by e.g. tmpfile() doesn't solve the problem if an additional temporary structure, e.g. for caching purposes, needs to be created beneath the temp directory and an userland method requires the path on which it can work on. If running on Windows the location of the temporary directory might differ. The code - or the - recognition of it is already solved in PHP: http://lxr.php.net/source/php-src/main/php_open_temporary_file.c#161 But there is no way to get this information whilst a script is running. Reproduce code: --- -none- Expected result: A constant or function that reflects/returns the status of PHPs internal php_tmpdir()/php_get_temporary_directory() for the current running script. Actual result: -- not available, but thank you for fixing in advance. -- Edit this bug report at http://bugs.php.net/?id=35380&edit=1
#35512 [NEW]: Lack of read permission on main script results in E_WARNING
From: rdingman at next-online dot net Operating system: Mac OS X 10.4.3 PHP version: 5.1.1 PHP Bug Type: Scripting Engine problem Bug description: Lack of read permission on main script results in E_WARNING Description: If I access http://localhost/foo.php and PHP does not have permission to read foo.php (say the permissions are 222), I get an E_WARNING rather than an E_COMPILE_ERROR (include vs. require). This is in PHP 5.1.1. I've fixed this in a local build by patching zend_execute_scripts in Zend/zend.c on line 1079. zend_execute_scripts was calling zend_compile_file and passing ZEND_INCLUDE in as the type argument rather than passing along its type argument. The old code reads: EG(active_op_array) = zend_compile_file(file_handle, ZEND_INCLUDE TSRMLS_CC); My patched version reads: EG(active_op_array) = zend_compile_file(file_handle, type TSRMLS_CC); Because I'm not intimately familiar with the inner workings of the interpreter, I'm not sure that this is the best way to fix this problem, but it seems like the most appropriate place that I could find. Expected result: If PHP does not have permission to read the main script, I would expect to get an E_COMPILE_ERROR. The difference is treating reading the main script as if it where required rather than included. The main script should be treated as if it were required rather than included. In case you are wondering why I care -- we have a PHP module that monitors PHP errors and redirects our customers to a customer service page any time that PHP encounters anything that the interpreter really shouldn't recover from (E_CORE_ERROR, E_ERROR, E_PARSE, E_COMPILE_ERROR and E_USER_ERROR). The main script not being readable is certainly a case where we would like to redirect them to a customer service page. However, having an E_WARNING as the error makes it difficult to identify this situation because we would now have to distinguish between this E_WARNING and any others that might arise in the site. Having an E_COMPILE_ERROR would be much more definitive and more correct IMHO. Yes, we are taking other steps to ensure that the permission on the PHP scripts for our site are correct, but mistakes do happen and we want to guarantee that our customers have as good an experience as possible in the case of unexpected errors (as any enterprise site should). Actual result: -- If PHP does not have permission to read the main script, I get the following E_WARNING: Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0 Warning: Unknown: Failed opening '/Library/WebServer/ Documents/foo.php' for inclusion (include_path='/usr/local/ lib/php:.') in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=35512&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35512&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35512&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35512&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35512&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35512&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35512&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35512&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35512&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35512&r=support Expected behavior:http://bugs.php.net/fix.php?id=35512&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35512&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35512&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35512&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35512&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35512&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35512&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35512&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35512&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35512&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35512&r=mysqlcfg
#35507 [Bgs]: feof does not report no-char on STDIN
ID: 35507
User updated by: dsp at tdcspace dot dk
Reported By: dsp at tdcspace dot dk
Status: Bogus
Bug Type: Feature/Change Request
Operating System: win/nix
PHP Version: 5.1.1
New Comment:
hotddam - error
can't destroy the zero flag with "xor ax,ax" must use "mov ax,0" - sry
keyb_newchar_check proc far
mov ax,1
int 16h ; func=1
mov ax,0
jz nochar
inc ax
nochar:
ret
keyb_newchar_check endp
Previous Comments:
[2005-12-01 22:08:58] dsp at tdcspace dot dk
This is what has been valid BIOS INT on the x86 family IBM compatible
since it came in early 80' !
---
TEST FOR KEY (SINGLE CHAR)
---
return: ax=0=no char waiting or ax=1=yes
keyb_newchar_check proc far
mov ax,1
int 16h ; func=1
xor ax,ax
jz nochar
inc ax
nochar:
ret
keyb_newchar_check endp
-
GET WAITING KEY (SINGLE CHAR)
-
return: ax (AL) = char (if func key like F1 then its scan code)
note: if no waiting key - then the bios will wait for one
keyb_newchar_get proc far
xor ax,ax
int 16h; func=0
or al,al
jnz noscan
mov al,ah ; scan code in ah
noscan:
xor ah,ah
ret
keyb_newchar_get endp
SOURCE
Public Domain/Freeware/Shareware by Ralf Brown: INTER60.ZIP X86 family
DOS/BIOS int's
B-1600---
INT 16 - KEYBOARD - GET KEYSTROKE
AH = 00h
Return: AH = BIOS scan code
AL = ASCII character
Notes: on extended keyboards, this function discards any extended
keystrokes,
returning only when a non-extended keystroke is available
the BIOS scan code is usually, but not always, the same as the
hardware
scan code processed by INT 09. It is the same for ASCII keystrokes
and most unshifted special keys (F-keys, arrow keys, etc.), but
differs for shifted special keys
some (older) clone BIOSes do not discard extended keystrokes and
manage
function AH=00h and AH=10h the same
the K3PLUS v6.00+ INT 16 BIOS replacement doesn't discard extended
keystrokes (same as with functions 10h and 20h), but will always
translate prefix E0h to 00h. This allows old programs to use
extended
keystrokes and should not cause compatibility problems
SeeAlso: AH=01h,AH=05h,AH=10h,AH=20h,AX=AF4Dh"K3PLUS",INT 18/AH=00h
SeeAlso: INT 09,INT 15/AH=4Fh
B-1601---
INT 16 - KEYBOARD - CHECK FOR KEYSTROKE
AH = 01h
Return: ZF set if no keystroke available
ZF clear if keystroke available
AH = BIOS scan code
AL = ASCII character
Note: if a keystroke is present, it is not removed from the keyboard
buffer;
however, any extended keystrokes which are not compatible with
83/84-
key keyboards are removed by IBM and most fully-compatible BIOSes
in
the process of checking whether a non-extended keystroke is
available
some (older) clone BIOSes do not discard extended keystrokes and
manage
function AH=00h and AH=10h the same
the K3PLUS v6.00+ INT 16 BIOS replacement doesn't discard extended
keystrokes (same as with functions 10h and 20h), but will always
translate prefix E0h to 00h. This allows old programs to use
extended
keystrokes and should not cause compatibility problems
SeeAlso: AH=00h,AH=11h,AH=21h,INT 18/AH=01h,INT 09,INT 15/AH=4Fh
[2005-12-01 20:30:13] [EMAIL PROTECTED]
I'm not talking about a file, no.
I'm talking about stdin stream.
Feel free to cook a patch and post it for use to review.
[2005-12-01 20:08:57] dsp at tdcspace dot dk
Tx for asking me !
In case of the keyboard input, the state is well defined from the bios
aka. the "waiting char status" of which all comp's have a (basic) BIOS
to report tat.
In case of a file (stream) it is possible to detect an EOF - (WITHOUT
having to read first) by using ftell()/fseek(). Ayway it may impose
some overhead. Nevertheless the code below will allways report EOF
without reading (ex. is with a zero len file). Try it urself !
$handle = fopen('test', 'w'); // create a zero length file
fclose($handle);
$handle = fopen('test', 'r'); // re-open
do {
// start - EOF routine
$curpos = ftell($handle);
fseek($handle, 0, SEEK_END);
$endpos = ftell($handle);
// test wether the current pos is the last pos (=eof)
if ($endpos == $curpos) { echo " ..EOF"; break; }
fseek($handle, $curpos); // not EOF - return to last file pos
// end - EOF routine
echo "\r\nRead at " . $curpos;
$buffer = fgets($handle, 9);
}
whil
#35507 [Bgs]: feof does not report no-char on STDIN
ID: 35507
User updated by: dsp at tdcspace dot dk
Reported By: dsp at tdcspace dot dk
Status: Bogus
Bug Type: Feature/Change Request
Operating System: win/nix
PHP Version: 5.1.1
New Comment:
This is what has been valid BIOS INT on the x86 family IBM compatible
since it came in early 80' !
---
TEST FOR KEY (SINGLE CHAR)
---
return: ax=0=no char waiting or ax=1=yes
keyb_newchar_check proc far
mov ax,1
int 16h ; func=1
xor ax,ax
jz nochar
inc ax
nochar:
ret
keyb_newchar_check endp
-
GET WAITING KEY (SINGLE CHAR)
-
return: ax (AL) = char (if func key like F1 then its scan code)
note: if no waiting key - then the bios will wait for one
keyb_newchar_get proc far
xor ax,ax
int 16h; func=0
or al,al
jnz noscan
mov al,ah ; scan code in ah
noscan:
xor ah,ah
ret
keyb_newchar_get endp
SOURCE
Public Domain/Freeware/Shareware by Ralf Brown: INTER60.ZIP X86 family
DOS/BIOS int's
B-1600---
INT 16 - KEYBOARD - GET KEYSTROKE
AH = 00h
Return: AH = BIOS scan code
AL = ASCII character
Notes: on extended keyboards, this function discards any extended
keystrokes,
returning only when a non-extended keystroke is available
the BIOS scan code is usually, but not always, the same as the
hardware
scan code processed by INT 09. It is the same for ASCII keystrokes
and most unshifted special keys (F-keys, arrow keys, etc.), but
differs for shifted special keys
some (older) clone BIOSes do not discard extended keystrokes and
manage
function AH=00h and AH=10h the same
the K3PLUS v6.00+ INT 16 BIOS replacement doesn't discard extended
keystrokes (same as with functions 10h and 20h), but will always
translate prefix E0h to 00h. This allows old programs to use
extended
keystrokes and should not cause compatibility problems
SeeAlso: AH=01h,AH=05h,AH=10h,AH=20h,AX=AF4Dh"K3PLUS",INT 18/AH=00h
SeeAlso: INT 09,INT 15/AH=4Fh
B-1601---
INT 16 - KEYBOARD - CHECK FOR KEYSTROKE
AH = 01h
Return: ZF set if no keystroke available
ZF clear if keystroke available
AH = BIOS scan code
AL = ASCII character
Note: if a keystroke is present, it is not removed from the keyboard
buffer;
however, any extended keystrokes which are not compatible with
83/84-
key keyboards are removed by IBM and most fully-compatible BIOSes
in
the process of checking whether a non-extended keystroke is
available
some (older) clone BIOSes do not discard extended keystrokes and
manage
function AH=00h and AH=10h the same
the K3PLUS v6.00+ INT 16 BIOS replacement doesn't discard extended
keystrokes (same as with functions 10h and 20h), but will always
translate prefix E0h to 00h. This allows old programs to use
extended
keystrokes and should not cause compatibility problems
SeeAlso: AH=00h,AH=11h,AH=21h,INT 18/AH=01h,INT 09,INT 15/AH=4Fh
Previous Comments:
[2005-12-01 20:30:13] [EMAIL PROTECTED]
I'm not talking about a file, no.
I'm talking about stdin stream.
Feel free to cook a patch and post it for use to review.
[2005-12-01 20:08:57] dsp at tdcspace dot dk
Tx for asking me !
In case of the keyboard input, the state is well defined from the bios
aka. the "waiting char status" of which all comp's have a (basic) BIOS
to report tat.
In case of a file (stream) it is possible to detect an EOF - (WITHOUT
having to read first) by using ftell()/fseek(). Ayway it may impose
some overhead. Nevertheless the code below will allways report EOF
without reading (ex. is with a zero len file). Try it urself !
$handle = fopen('test', 'w'); // create a zero length file
fclose($handle);
$handle = fopen('test', 'r'); // re-open
do {
// start - EOF routine
$curpos = ftell($handle);
fseek($handle, 0, SEEK_END);
$endpos = ftell($handle);
// test wether the current pos is the last pos (=eof)
if ($endpos == $curpos) { echo " ..EOF"; break; }
fseek($handle, $curpos); // not EOF - return to last file pos
// end - EOF routine
echo "\r\nRead at " . $curpos;
$buffer = fgets($handle, 9);
}
while(true);
echo " ..END";
fclose($handle);
[2005-12-01 19:04:13] [EMAIL PROTECTED]
And how do you propose to distinguish "slow input" from "no input"?
Where exactly there should be EOF in a *stream*?
[2005-12-
#35510 [Bgs->Opn]: add gmp_nextprime function to ext/gmp
ID: 35510
Updated by: [EMAIL PROTECTED]
Reported By: ants dot aasma at gmail dot com
-Status: Bogus
+Status: Open
-Bug Type: *Math Functions
+Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.1.1
New Comment:
reclassified where this belongs.
Previous Comments:
[2005-12-01 20:28:56] [EMAIL PROTECTED]
Do not use the bug system for posting patches that do not fix a bug.
Use the maillist (internals@lists.php.net).
[2005-12-01 20:13:44] ants dot aasma at gmail dot com
Description:
Add the gmp_nextprime function to ext/gmp. I need it for
my cryptographically secure random number generator and
it's probably pretty useful to others too (espescially
because I can then release my code properly :).
http://www.hot.ee/stepz/Math_Random/gmp.patch is the
(really simple) patch.
Reproduce code:
---
if (function_exists("gmp_nextprime")) {
echo gmp_strval(gmp_nextprime(1000));
} else {
echo "No function";
}
Expected result:
1009
Actual result:
--
No function
--
Edit this bug report at http://bugs.php.net/?id=35510&edit=1
#35511 [Bgs]: Unserialized global arrays do not globalize in functions properly.
ID: 35511
User updated by: ngaugler at ngworld dot net
Reported By: ngaugler at ngworld dot net
Status: Bogus
Bug Type: Arrays related
Operating System: Linux 2.6
PHP Version: 4.4.1
New Comment:
I found it, had to change the wording to look more for next specific
functions.
http://bugs.php.net/bug.php?id=35444
Previous Comments:
[2005-12-01 21:15:20] ngaugler at ngworld dot net
What is the link to the same bug? I searched many times and was unable
to locate one.
[2005-12-01 20:55:29] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Fixed in CVS months ago.
[2005-12-01 20:51:49] ngaugler at ngworld dot net
Description:
In 4.4.1, when you unserialize an array, then attempt to globalize it
within a function, and then pass it to an internal array function such
as next or key, it does not work as it was in 4.3.10 or how it
functions in PHP 5.0.5. This functions as expected in 4.3.10 and
5.0.5. The documentation clearly states you are not to use
next(&array) or key(&array) when using references, which is why this is
not used.
Reproduce code:
---
'BOB'), array('ID' => 'GEORGE'), array('ID'
=> 'JOHN'));
$ser = serialize($ar);
$arn = unserialize($ser);
print_r($arn) . "\n\n";
function breakPHP() {
global $arn;
for ($i = 0, reset($arn); ($key = key($arn)), (isset($key));
next($arn), $i++) {
print "$key ... " . $arn[$key]['ID'] . "\n";
if ($i > 5) {
print "we looped";
exit;
}
}
}
breakPHP();
?>
Expected result:
Array
(
[0] => Array
(
[ID] => BOB
)
[1] => Array
(
[ID] => GEORGE
)
[2] => Array
(
[ID] => JOHN
)
)
0 ... BOB
1 ... GEORGE
2 ... JOHN
Actual result:
--
Array
(
[0] => Array
(
[ID] => BOB
)
[1] => Array
(
[ID] => GEORGE
)
[2] => Array
(
[ID] => JOHN
)
)
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
--
Edit this bug report at http://bugs.php.net/?id=35511&edit=1
#35511 [Bgs]: Unserialized global arrays do not globalize in functions properly.
ID: 35511
User updated by: ngaugler at ngworld dot net
Reported By: ngaugler at ngworld dot net
Status: Bogus
Bug Type: Arrays related
Operating System: Linux 2.6
PHP Version: 4.4.1
New Comment:
What is the link to the same bug? I searched many times and was unable
to locate one.
Previous Comments:
[2005-12-01 20:55:29] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Fixed in CVS months ago.
[2005-12-01 20:51:49] ngaugler at ngworld dot net
Description:
In 4.4.1, when you unserialize an array, then attempt to globalize it
within a function, and then pass it to an internal array function such
as next or key, it does not work as it was in 4.3.10 or how it
functions in PHP 5.0.5. This functions as expected in 4.3.10 and
5.0.5. The documentation clearly states you are not to use
next(&array) or key(&array) when using references, which is why this is
not used.
Reproduce code:
---
'BOB'), array('ID' => 'GEORGE'), array('ID'
=> 'JOHN'));
$ser = serialize($ar);
$arn = unserialize($ser);
print_r($arn) . "\n\n";
function breakPHP() {
global $arn;
for ($i = 0, reset($arn); ($key = key($arn)), (isset($key));
next($arn), $i++) {
print "$key ... " . $arn[$key]['ID'] . "\n";
if ($i > 5) {
print "we looped";
exit;
}
}
}
breakPHP();
?>
Expected result:
Array
(
[0] => Array
(
[ID] => BOB
)
[1] => Array
(
[ID] => GEORGE
)
[2] => Array
(
[ID] => JOHN
)
)
0 ... BOB
1 ... GEORGE
2 ... JOHN
Actual result:
--
Array
(
[0] => Array
(
[ID] => BOB
)
[1] => Array
(
[ID] => GEORGE
)
[2] => Array
(
[ID] => JOHN
)
)
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
--
Edit this bug report at http://bugs.php.net/?id=35511&edit=1
#35509 [Opn->Asn]: string constant as array key has different behavior inside object
ID: 35509
Updated by: [EMAIL PROTECTED]
Reported By: bill dot finn at sellingsource dot com
-Status: Open
+Status: Assigned
Bug Type: Arrays related
Operating System: Gentoo 2.6.9
PHP Version: 6CVS-2005-12-01 (CVS)
-Assigned To:
+Assigned To: dmitry
New Comment:
Dmitry, please take a look at it.
Previous Comments:
[2005-12-01 20:02:51] bill dot finn at sellingsource dot com
Description:
When using a constant of '01' as an array key inside of a class, it
converts the key to the integer 1. Outside of a class, it leaves it as
'01'.
Reproduce code:
---
class mytest
{
const classConstant = '01';
private $classArray = array( mytest::classConstant => 'value' );
public function __construct()
{
print_r($this->classArray);
}
}
$classtest = new mytest();
define( "normalConstant", '01' );
$normalArray = array( normalConstant => 'value' );
print_r($normalArray);
Expected result:
Array
(
[01] => value
)
Array
(
[01] => value
)
Actual result:
--
Array
(
[1] => value
)
Array
(
[01] => value
)
--
Edit this bug report at http://bugs.php.net/?id=35509&edit=1
#35508 [Opn->Csd]: PDO returns SQLSTATE error on valid queries.
ID: 35508
Updated by: [EMAIL PROTECTED]
Reported By: capiCrimm at gmail dot com
-Status: Open
+Status: Closed
Bug Type: PDO related
Operating System: Debian
PHP Version: 5.1.1
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
JFYI: all PDO constants were changed to class constants before 5.1
release.
Previous Comments:
[2005-12-01 19:35:18] capiCrimm at gmail dot com
Description:
When creating a temporary table with PDO it returns an
error when you try to use the table. The database I'm
running is mysql 14.7. The queries run fine in mysql CLI.
I've tried switching around the query values and changing
tables and databases. Error occurs both in php CLI and
mod_php. I'm pretty sure Temp tables were working in RC1,
though I may be remembering wrong.
Reproduce code:
---
query('CREATE TEMPORARY TABLE TestC(str1 INT(1),str2
INT(1));');
$pdoConnection->query("INSERT INTO TestC VALUES(1,1);",
PDO_RESULT_ASSOC); // line 6
?>
Expected result:
A Blank Page
Actual result:
--
Warning: PDO::query() [function.query]: SQLSTATE[22003]:
Numeric value out of range: unhandled mode; this is a PDO
bug, please report it in /file.php on line 6
--
Edit this bug report at http://bugs.php.net/?id=35508&edit=1
#35511 [Opn->Bgs]: Unserialized global arrays do not globalize in functions properly.
ID: 35511
Updated by: [EMAIL PROTECTED]
Reported By: ngaugler at ngworld dot net
-Status: Open
+Status: Bogus
-Bug Type: Scripting Engine problem
+Bug Type: Arrays related
Operating System: Linux 2.6
PHP Version: 4.4.1
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Fixed in CVS months ago.
Previous Comments:
[2005-12-01 20:51:49] ngaugler at ngworld dot net
Description:
In 4.4.1, when you unserialize an array, then attempt to globalize it
within a function, and then pass it to an internal array function such
as next or key, it does not work as it was in 4.3.10 or how it
functions in PHP 5.0.5. This functions as expected in 4.3.10 and
5.0.5. The documentation clearly states you are not to use
next(&array) or key(&array) when using references, which is why this is
not used.
Reproduce code:
---
'BOB'), array('ID' => 'GEORGE'), array('ID'
=> 'JOHN'));
$ser = serialize($ar);
$arn = unserialize($ser);
print_r($arn) . "\n\n";
function breakPHP() {
global $arn;
for ($i = 0, reset($arn); ($key = key($arn)), (isset($key));
next($arn), $i++) {
print "$key ... " . $arn[$key]['ID'] . "\n";
if ($i > 5) {
print "we looped";
exit;
}
}
}
breakPHP();
?>
Expected result:
Array
(
[0] => Array
(
[ID] => BOB
)
[1] => Array
(
[ID] => GEORGE
)
[2] => Array
(
[ID] => JOHN
)
)
0 ... BOB
1 ... GEORGE
2 ... JOHN
Actual result:
--
Array
(
[0] => Array
(
[ID] => BOB
)
[1] => Array
(
[ID] => GEORGE
)
[2] => Array
(
[ID] => JOHN
)
)
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
--
Edit this bug report at http://bugs.php.net/?id=35511&edit=1
#35511 [NEW]: Unserialized global arrays do not globalize in functions properly.
From: ngaugler at ngworld dot net
Operating system: Linux 2.6
PHP version: 4.4.1
PHP Bug Type: Scripting Engine problem
Bug description: Unserialized global arrays do not globalize in functions
properly.
Description:
In 4.4.1, when you unserialize an array, then attempt to globalize it
within a function, and then pass it to an internal array function such as
next or key, it does not work as it was in 4.3.10 or how it functions in
PHP 5.0.5. This functions as expected in 4.3.10 and 5.0.5. The
documentation clearly states you are not to use next(&array) or
key(&array) when using references, which is why this is not used.
Reproduce code:
---
'BOB'), array('ID' => 'GEORGE'), array('ID' =>
'JOHN'));
$ser = serialize($ar);
$arn = unserialize($ser);
print_r($arn) . "\n\n";
function breakPHP() {
global $arn;
for ($i = 0, reset($arn); ($key = key($arn)), (isset($key));
next($arn), $i++) {
print "$key ... " . $arn[$key]['ID'] . "\n";
if ($i > 5) {
print "we looped";
exit;
}
}
}
breakPHP();
?>
Expected result:
Array
(
[0] => Array
(
[ID] => BOB
)
[1] => Array
(
[ID] => GEORGE
)
[2] => Array
(
[ID] => JOHN
)
)
0 ... BOB
1 ... GEORGE
2 ... JOHN
Actual result:
--
Array
(
[0] => Array
(
[ID] => BOB
)
[1] => Array
(
[ID] => GEORGE
)
[2] => Array
(
[ID] => JOHN
)
)
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
0 ... BOB
--
Edit bug report at http://bugs.php.net/?id=35511&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35511&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35511&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35511&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35511&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35511&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35511&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35511&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35511&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35511&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35511&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35511&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35511&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35511&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35511&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35511&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35511&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35511&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35511&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35511&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35511&r=mysqlcfg
#35507 [Opn->Bgs]: feof does not report no-char on STDIN
ID: 35507
Updated by: [EMAIL PROTECTED]
Reported By: dsp at tdcspace dot dk
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: win/nix
PHP Version: 5.1.1
New Comment:
I'm not talking about a file, no.
I'm talking about stdin stream.
Feel free to cook a patch and post it for use to review.
Previous Comments:
[2005-12-01 20:08:57] dsp at tdcspace dot dk
Tx for asking me !
In case of the keyboard input, the state is well defined from the bios
aka. the "waiting char status" of which all comp's have a (basic) BIOS
to report tat.
In case of a file (stream) it is possible to detect an EOF - (WITHOUT
having to read first) by using ftell()/fseek(). Ayway it may impose
some overhead. Nevertheless the code below will allways report EOF
without reading (ex. is with a zero len file). Try it urself !
$handle = fopen('test', 'w'); // create a zero length file
fclose($handle);
$handle = fopen('test', 'r'); // re-open
do {
// start - EOF routine
$curpos = ftell($handle);
fseek($handle, 0, SEEK_END);
$endpos = ftell($handle);
// test wether the current pos is the last pos (=eof)
if ($endpos == $curpos) { echo " ..EOF"; break; }
fseek($handle, $curpos); // not EOF - return to last file pos
// end - EOF routine
echo "\r\nRead at " . $curpos;
$buffer = fgets($handle, 9);
}
while(true);
echo " ..END";
fclose($handle);
[2005-12-01 19:04:13] [EMAIL PROTECTED]
And how do you propose to distinguish "slow input" from "no input"?
Where exactly there should be EOF in a *stream*?
[2005-12-01 18:58:29] dsp at tdcspace dot dk
Better explain that the loop waits for a keyboard input
despite there is no input.
[2005-12-01 18:47:38] dsp at tdcspace dot dk
Description:
In a continous loop for processing data with options for
entering a process char (like 'q' for quit, etc.) - the
feof() does not report no input (EOF) from STDIN (keyboard).
note: This is about the CLI version
example: the loop should output etc
do {
if ( !feof(STDIN) ) { $x = fgetc(STDIN); echo $x; }
echo '.';
}
while(true);
THE PHP MANUAL SAYS -
feof (PHP 3, PHP 4, PHP 5)
feof -- Tests for end-of-file on a file pointer
Description
bool feof ( resource handle )
Returns TRUE if the file pointer is at EOF or an error occurs
(including socket timeout); otherwise returns FALSE.
---
Apparantly "Tests for end-of-file on a file pointer" does
not TEST for anything !!
--
Edit this bug report at http://bugs.php.net/?id=35507&edit=1
#35510 [Opn->Bgs]: add gmp_nextprime function to ext/gmp
ID: 35510
Updated by: [EMAIL PROTECTED]
Reported By: ants dot aasma at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: *Math Functions
Operating System: Linux
PHP Version: 5.1.1
New Comment:
Do not use the bug system for posting patches that do not fix a bug.
Use the maillist (internals@lists.php.net).
Previous Comments:
[2005-12-01 20:13:44] ants dot aasma at gmail dot com
Description:
Add the gmp_nextprime function to ext/gmp. I need it for
my cryptographically secure random number generator and
it's probably pretty useful to others too (espescially
because I can then release my code properly :).
http://www.hot.ee/stepz/Math_Random/gmp.patch is the
(really simple) patch.
Reproduce code:
---
if (function_exists("gmp_nextprime")) {
echo gmp_strval(gmp_nextprime(1000));
} else {
echo "No function";
}
Expected result:
1009
Actual result:
--
No function
--
Edit this bug report at http://bugs.php.net/?id=35510&edit=1
#35510 [NEW]: add gmp_nextprime function to ext/gmp
From: ants dot aasma at gmail dot com
Operating system: Linux
PHP version: 5.1.1
PHP Bug Type: *Math Functions
Bug description: add gmp_nextprime function to ext/gmp
Description:
Add the gmp_nextprime function to ext/gmp. I need it for
my cryptographically secure random number generator and
it's probably pretty useful to others too (espescially
because I can then release my code properly :).
http://www.hot.ee/stepz/Math_Random/gmp.patch is the
(really simple) patch.
Reproduce code:
---
if (function_exists("gmp_nextprime")) {
echo gmp_strval(gmp_nextprime(1000));
} else {
echo "No function";
}
Expected result:
1009
Actual result:
--
No function
--
Edit bug report at http://bugs.php.net/?id=35510&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35510&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35510&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35510&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35510&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35510&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35510&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35510&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35510&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35510&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35510&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35510&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35510&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35510&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35510&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35510&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35510&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35510&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35510&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35510&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35510&r=mysqlcfg
#35507 [Fbk->Opn]: feof does not report no-char on STDIN
ID: 35507
User updated by: dsp at tdcspace dot dk
Reported By: dsp at tdcspace dot dk
-Status: Feedback
+Status: Open
Bug Type: Feature/Change Request
Operating System: win/nix
PHP Version: 5.1.1
New Comment:
Tx for asking me !
In case of the keyboard input, the state is well defined from the bios
aka. the "waiting char status" of which all comp's have a (basic) BIOS
to report tat.
In case of a file (stream) it is possible to detect an EOF - (WITHOUT
having to read first) by using ftell()/fseek(). Ayway it may impose
some overhead. Nevertheless the code below will allways report EOF
without reading (ex. is with a zero len file). Try it urself !
$handle = fopen('test', 'w'); // create a zero length file
fclose($handle);
$handle = fopen('test', 'r'); // re-open
do {
// start - EOF routine
$curpos = ftell($handle);
fseek($handle, 0, SEEK_END);
$endpos = ftell($handle);
// test wether the current pos is the last pos (=eof)
if ($endpos == $curpos) { echo " ..EOF"; break; }
fseek($handle, $curpos); // not EOF - return to last file pos
// end - EOF routine
echo "\r\nRead at " . $curpos;
$buffer = fgets($handle, 9);
}
while(true);
echo " ..END";
fclose($handle);
Previous Comments:
[2005-12-01 19:04:13] [EMAIL PROTECTED]
And how do you propose to distinguish "slow input" from "no input"?
Where exactly there should be EOF in a *stream*?
[2005-12-01 18:58:29] dsp at tdcspace dot dk
Better explain that the loop waits for a keyboard input
despite there is no input.
[2005-12-01 18:47:38] dsp at tdcspace dot dk
Description:
In a continous loop for processing data with options for
entering a process char (like 'q' for quit, etc.) - the
feof() does not report no input (EOF) from STDIN (keyboard).
note: This is about the CLI version
example: the loop should output etc
do {
if ( !feof(STDIN) ) { $x = fgetc(STDIN); echo $x; }
echo '.';
}
while(true);
THE PHP MANUAL SAYS -
feof (PHP 3, PHP 4, PHP 5)
feof -- Tests for end-of-file on a file pointer
Description
bool feof ( resource handle )
Returns TRUE if the file pointer is at EOF or an error occurs
(including socket timeout); otherwise returns FALSE.
---
Apparantly "Tests for end-of-file on a file pointer" does
not TEST for anything !!
--
Edit this bug report at http://bugs.php.net/?id=35507&edit=1
#35509 [NEW]: string constant as array key has different behavior inside object
From: bill dot finn at sellingsource dot com
Operating system: Gentoo 2.6.9
PHP version: 6CVS-2005-12-01 (CVS)
PHP Bug Type: Arrays related
Bug description: string constant as array key has different behavior inside
object
Description:
When using a constant of '01' as an array key inside of a class, it
converts the key to the integer 1. Outside of a class, it leaves it as
'01'.
Reproduce code:
---
class mytest
{
const classConstant = '01';
private $classArray = array( mytest::classConstant => 'value' );
public function __construct()
{
print_r($this->classArray);
}
}
$classtest = new mytest();
define( "normalConstant", '01' );
$normalArray = array( normalConstant => 'value' );
print_r($normalArray);
Expected result:
Array
(
[01] => value
)
Array
(
[01] => value
)
Actual result:
--
Array
(
[1] => value
)
Array
(
[01] => value
)
--
Edit bug report at http://bugs.php.net/?id=35509&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35509&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35509&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35509&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35509&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35509&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35509&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35509&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35509&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35509&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35509&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35509&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35509&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35509&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35509&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35509&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35509&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35509&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35509&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35509&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35509&r=mysqlcfg
#35508 [NEW]: PDO returns SQLSTATE error on valid queries.
From: capiCrimm at gmail dot com
Operating system: Debian
PHP version: 5.1.1
PHP Bug Type: PDO related
Bug description: PDO returns SQLSTATE error on valid queries.
Description:
When creating a temporary table with PDO it returns an
error when you try to use the table. The database I'm
running is mysql 14.7. The queries run fine in mysql CLI.
I've tried switching around the query values and changing
tables and databases. Error occurs both in php CLI and
mod_php. I'm pretty sure Temp tables were working in RC1,
though I may be remembering wrong.
Reproduce code:
---
query('CREATE TEMPORARY TABLE TestC(str1 INT(1),str2
INT(1));');
$pdoConnection->query("INSERT INTO TestC VALUES(1,1);", PDO_RESULT_ASSOC);
// line 6
?>
Expected result:
A Blank Page
Actual result:
--
Warning: PDO::query() [function.query]: SQLSTATE[22003]:
Numeric value out of range: unhandled mode; this is a PDO
bug, please report it in /file.php on line 6
--
Edit bug report at http://bugs.php.net/?id=35508&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35508&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35508&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35508&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35508&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35508&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35508&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35508&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35508&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35508&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35508&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35508&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35508&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35508&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35508&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35508&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35508&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35508&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35508&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35508&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35508&r=mysqlcfg
#35498 [Asn]: GD cannot open majority of jpeg images
ID: 35498 User updated by: paniemin at cc dot hut dot fi Reported By: paniemin at cc dot hut dot fi Status: Assigned Bug Type: GD related Operating System: Redhat Linux 7.3 PHP Version: 5.1.0 Assigned To: pajoye New Comment: Problem is in jpeg library but problems is that there isn't enought memory! But I haven't enabled memory limit. jmemmgr.c: in alloc_large function: hdr_ptr = (large_pool_ptr) jpeg_get_large(cinfo, sizeofobject + SIZEOF(large_pool_hdr)); if (hdr_ptr == NULL) out_of_memory(cinfo, 4);/* jpeg_get_large failed */ jpeg_get_large is just system specifig warepper for malloc call. The problem is in jpeg_start_decompress call from php GD library in gdImageCreateFromJpegCtx function (gd_jpeg.c). But when I try to run the php code in shell there is no problems. I quess that maybe some limits in apache that is runnig php in cgi mode. Previous Comments: [2005-12-01 12:29:42] [EMAIL PROTECTED] Assigned to the maintainer. [2005-12-01 10:45:31] paniemin at cc dot hut dot fi First I tryed to us blunded but when that failed I tested external library. I will try to find the location of bug in php source later today when I will be back home. Btw, corect version is 5.1.0 (the public release). [2005-12-01 10:24:43] [EMAIL PROTECTED] Try with the bundled GD, it's known to be less buggy and well maintained. [2005-12-01 01:18:25] paniemin at cc dot hut dot fi Description: I tryed to upgrade from 5.0.4 to 5.1. I use blunded GD version with freetype2, jpeg and png libraries. First I tried with old libraries that I used to build 5.0.4. Next I downloaded new version from freetype2. Next I downloaded GD 2.0.33 and tryed with it. I tried to find the problematic part but I failed to locate it outside php :( I found that imagecreatefromjpeg() fails to open jpeg files that older php version opened without problems. The failure to open seems to be random but about 60-70% images are 'corruped' for gd library. here is one of corrupted images: http://antin.net/imageshu/7363_1.jpg I will continue searching the real reason for this bug. I hope someone else can confirm same problem with 5.1 and GD. Reproduce code: --- $file = getFileForPerson($id, $imageNumber); $img = imagecreatefromjpeg($file); Expected result: I excepted imagecreatefromjpeg to load the image so next steps in code can manipulate it. Actual result: -- Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg: JPEG library reports unrecoverable error: in /home/customers/antin/public_html/huippu/ranki_dev.cgi on line 110 Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '../imageshu/7363_1.jpg' is not a valid JPEG file in /home/customers/antin/public_html/huippu/ranki_dev.cgi on line 110 With GD 2.0.33 the first warning is skipped which seems natural for me. -- Edit this bug report at http://bugs.php.net/?id=35498&edit=1
#35507 [Opn->Fbk]: feof does not report no-char on STDIN
ID: 35507
Updated by: [EMAIL PROTECTED]
Reported By: dsp at tdcspace dot dk
-Status: Open
+Status: Feedback
Bug Type: Feature/Change Request
Operating System: win/nix
PHP Version: 5.1.1
New Comment:
And how do you propose to distinguish "slow input" from "no input"?
Where exactly there should be EOF in a *stream*?
Previous Comments:
[2005-12-01 18:58:29] dsp at tdcspace dot dk
Better explain that the loop waits for a keyboard input
despite there is no input.
[2005-12-01 18:47:38] dsp at tdcspace dot dk
Description:
In a continous loop for processing data with options for
entering a process char (like 'q' for quit, etc.) - the
feof() does not report no input (EOF) from STDIN (keyboard).
note: This is about the CLI version
example: the loop should output etc
do {
if ( !feof(STDIN) ) { $x = fgetc(STDIN); echo $x; }
echo '.';
}
while(true);
THE PHP MANUAL SAYS -
feof (PHP 3, PHP 4, PHP 5)
feof -- Tests for end-of-file on a file pointer
Description
bool feof ( resource handle )
Returns TRUE if the file pointer is at EOF or an error occurs
(including socket timeout); otherwise returns FALSE.
---
Apparantly "Tests for end-of-file on a file pointer" does
not TEST for anything !!
--
Edit this bug report at http://bugs.php.net/?id=35507&edit=1
#35507 [Opn]: feof does not report no-char on STDIN
ID: 35507
User updated by: dsp at tdcspace dot dk
Reported By: dsp at tdcspace dot dk
Status: Open
Bug Type: Feature/Change Request
Operating System: win/nix
PHP Version: 5.1.1
New Comment:
Better explain that the loop waits for a keyboard input
despite there is no input.
Previous Comments:
[2005-12-01 18:47:38] dsp at tdcspace dot dk
Description:
In a continous loop for processing data with options for
entering a process char (like 'q' for quit, etc.) - the
feof() does not report no input (EOF) from STDIN (keyboard).
note: This is about the CLI version
example: the loop should output etc
do {
if ( !feof(STDIN) ) { $x = fgetc(STDIN); echo $x; }
echo '.';
}
while(true);
THE PHP MANUAL SAYS -
feof (PHP 3, PHP 4, PHP 5)
feof -- Tests for end-of-file on a file pointer
Description
bool feof ( resource handle )
Returns TRUE if the file pointer is at EOF or an error occurs
(including socket timeout); otherwise returns FALSE.
---
Apparantly "Tests for end-of-file on a file pointer" does
not TEST for anything !!
--
Edit this bug report at http://bugs.php.net/?id=35507&edit=1
#35507 [NEW]: feof does not report no-char on STDIN
From: dsp at tdcspace dot dk
Operating system: win/nix
PHP version: 5.1.1
PHP Bug Type: Feature/Change Request
Bug description: feof does not report no-char on STDIN
Description:
In a continous loop for processing data with options for
entering a process char (like 'q' for quit, etc.) - the
feof() does not report no input (EOF) from STDIN (keyboard).
note: This is about the CLI version
example: the loop should output etc
do {
if ( !feof(STDIN) ) { $x = fgetc(STDIN); echo $x; }
echo '.';
}
while(true);
THE PHP MANUAL SAYS -
feof (PHP 3, PHP 4, PHP 5)
feof -- Tests for end-of-file on a file pointer
Description
bool feof ( resource handle )
Returns TRUE if the file pointer is at EOF or an error occurs (including
socket timeout); otherwise returns FALSE.
---
Apparantly "Tests for end-of-file on a file pointer" does
not TEST for anything !!
--
Edit bug report at http://bugs.php.net/?id=35507&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35507&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35507&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35507&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35507&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35507&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35507&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35507&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35507&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35507&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35507&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35507&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35507&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35507&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35507&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35507&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35507&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35507&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35507&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35507&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35507&r=mysqlcfg
#35329 [Com]: php.ini location changed between 5.0 and 5.1
ID: 35329 Comment by: thejkwhosaysni at gmail dot com Reported By: cjbj at hotmail dot com Status: Feedback Bug Type: *General Issues Operating System: win32 PHP Version: 5.1.0 New Comment: I have exactly the same problem with both php5.1.0 and php5.1.1. Putting php.ini into apache2/bin does not work either. Nor the php directory itself. Previous Comments: [2005-11-28 17:10:28] [EMAIL PROTECTED] CWD (why it checked the Apache dir) is now only searched when running under CLI. Either this is really a bug or FAQ in the manual should be changed to say to use Apache/bin (path is checked in 5.0 and 5.1 at least since its the binary location). [2005-11-28 15:19:43] [EMAIL PROTECTED] Chris, can you try using filemon from sysinternals to see if it's trying to access alternate php.ini paths? [2005-11-23 02:54:38] cjbj at hotmail dot com When I upgraded from 5.5 to 5.1, I had to 0. Unzip 5.1 to c:\php5-win32-latest 1. Edit c:/Program Files/Apache Group/Apache2/conf/httpd.conf and change: LoadModule php5_module "c:/php5.0-win32-200511031730/php5apache2.dll" to LoadModule php5_module "c:/php5-win32-latest/php5apache2.dll" 2. Edit c:\Program Files\Apache Group\Apache2\php.ini and change: extension_dir = "c:\php5.0-win32-200511031730\ext" to extension_dir = "c:\php5-win32-latest\ext" 3. Copy c:\Program Files\Apache Group\Apache2\php.ini to c:\WINDOWS Step 3 was not needed when upgrading any 5.0.x to 5.0.y. [2005-11-22 13:10:42] cjbj at hotmail dot com Description: PHP 5.0 on Windows reads a php.ini located at c:/Program Files/Apache Group/Apache/conf/httpd.conf or c:/Program Files/Apache Group/Apache/conf2/httpd.conf. PHP 5.1.0RC7-dev (Nov 22 2005 08:23:50) does not read this php.ini. Phpinfo() shows php.ini as "C:\WINDOWS", i.e. it has not found a php.ini This is a backward compatibility breakage I didn't notice documented in Steph's 5.1 upgrade notes. -- Edit this bug report at http://bugs.php.net/?id=35329&edit=1
#35506 [Opn->Fbk]: FATAL: erealloc(): Unable to allocate 24576 bytes
ID: 35506 Updated by: [EMAIL PROTECTED] Reported By: broadmind at magicn dot com -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: windows 2000 server PHP Version: 5CVS-2005-12-01 (snap) New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2005-12-01 17:35:56] broadmind at magicn dot com Description: My server environment is, CPU : AMD Opteron 240 x2 (2 cpu) RAM : 2 GB Apache 1.3.34 Mysql 5.0.16 PHP : 5.1.2-dev Snap stable version. In error logs, I could find the following error message frequently. FATAL: erealloc(): Unable to allocate 24576 bytes So, opening windows task manager, I have monitored the memory usage of Apache server. I found this log is happen when it is over 240MB duing to heavily access to mysql through a PHP page. Because the memory size of my server is 2GB, it is nonsense to say that this problem is duing to the lack of memory. In my guess, there may be a memory leak in the memory manager. Actual result: -- FATAL: erealloc(): Unable to allocate 24576 bytes the above log is leaved in error.log file and Apache server is restarted, causing the lose of POST data or "page not found". -- Edit this bug report at http://bugs.php.net/?id=35506&edit=1
#35484 [Opn->Fbk]: segmentation faults with multiple include virtual
ID: 35484 Updated by: [EMAIL PROTECTED] Reported By: minnoce at polito dot it -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Linux RHEL 4 PHP Version: 5.1.1 New Comment: We can't reproduce this so please provide the backtrace. (without --enable-debug if that's the only way..) Previous Comments: [2005-12-01 16:31:23] minnoce at polito dot it Obviously, the expected output is: TESTTEST [2005-12-01 16:28:50] minnoce at polito dot it mmm... Compiling PHP with --enable-debug and reproducing the bug (getting the "test.html" with the two include virtuals) don't cause anymore segmentatio faults. But simply the last "include virtual" produce NO output at all (no errors in apache logs). The output received from browser getting "test.html" is: TEST Thanks, Mauro [2005-12-01 15:58:54] [EMAIL PROTECTED] Please provide current backtrace. And make sure you had --enable-debug in your configure line! Also, don't submit ALL the lines, just the relevant ones. (The "loading symbols.." lines are not needed) [2005-12-01 15:48:55] minnoce at polito dot it The bug persist even with the LATEST PHP 5.1 from CVS. The GDB backtrace is exactly the same already reported. Thanks, Mauro [2005-12-01 15:10:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip 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/35484 -- Edit this bug report at http://bugs.php.net/?id=35484&edit=1
#35504 [Opn->Bgs]: Can only use c:\windows for php.ini dir.
ID: 35504 Updated by: [EMAIL PROTECTED] Reported By: thejkwhosaysni at gmail dot com -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: win32 PHP Version: 5.1.1 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. See bug #35329 Previous Comments: [2005-12-01 16:57:08] thejkwhosaysni at gmail dot com Description: Since php5.1 I have been unable to use php.ini from any directory other than c:\windows. This is a pain because i have apache2 running as a seperate user which I don't really want accessing any directories than it needs to. php5.0.* worked fine with php.ini in the \apache2\ directory. I tried overwriting my original php.ini (from when i installed 5.0) with the php.ini-dist from 5.1.1 with no avail. php refuses to see that it's there. I also trid the \php directory with both my php.ini and the default php.ini-dist. Neither worked. I first noticed this with 5.1.0 and the problem is still present in 5.1.1 Reproduce code: --- I just extracted php5.1.0 into the directory that I had php5.0.* installed into. -- Edit this bug report at http://bugs.php.net/?id=35504&edit=1
#35506 [NEW]: FATAL: erealloc(): Unable to allocate 24576 bytes
From: broadmind at magicn dot com Operating system: windows 2000 server PHP version: 5CVS-2005-12-01 (snap) PHP Bug Type: MySQL related Bug description: FATAL: erealloc(): Unable to allocate 24576 bytes Description: My server environment is, CPU : AMD Opteron 240 x2 (2 cpu) RAM : 2 GB Apache 1.3.34 Mysql 5.0.16 PHP : 5.1.2-dev Snap stable version. In error logs, I could find the following error message frequently. FATAL: erealloc(): Unable to allocate 24576 bytes So, opening windows task manager, I have monitored the memory usage of Apache server. I found this log is happen when it is over 240MB duing to heavily access to mysql through a PHP page. Because the memory size of my server is 2GB, it is nonsense to say that this problem is duing to the lack of memory. In my guess, there may be a memory leak in the memory manager. Actual result: -- FATAL: erealloc(): Unable to allocate 24576 bytes the above log is leaved in error.log file and Apache server is restarted, causing the lose of POST data or "page not found". -- Edit bug report at http://bugs.php.net/?id=35506&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35506&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35506&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35506&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35506&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35506&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35506&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35506&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35506&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35506&r=support Expected behavior:http://bugs.php.net/fix.php?id=35506&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35506&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35506&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35506&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35506&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35506&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35506&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35506&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35506&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35506&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35506&r=mysqlcfg
#35505 [Opn->Csd]: strtotime broken
ID: 35505
Updated by: [EMAIL PROTECTED]
Reported By: mvl22 at cam dot ac dot uk
-Status: Open
+Status: Closed
Bug Type: Date/time related
Operating System: Linux
PHP Version: 5.1.1
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-12-01 17:25:25] mvl22 at cam dot ac dot uk
Description:
echo strtotime ('1st December 2005 GMT');
fails - no output is produced.
Actual result:
--
[No output]
--
Edit this bug report at http://bugs.php.net/?id=35505&edit=1
#35499 [Asn->Csd]: strtotime with newline fails
ID: 35499
Updated by: [EMAIL PROTECTED]
Reported By: stabthecat at hotmail dot com
-Status: Assigned
+Status: Closed
Bug Type: Date/time related
Operating System: Windows / Linux
PHP Version: 5.1.1
Assigned To: iliaa
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-12-01 14:55:24] [EMAIL PROTECTED]
http://mega.ist.utl.pt/~ncpl/php_35499_patch.txt
[2005-12-01 01:22:59] stabthecat at hotmail dot com
Description:
Since version 5.1
strtotime("11/20/2005 8:00 AM\r\n");
fails, and returns null
strtotime(trim("11/20/2005 8:00 AM\r\n"));
fixes it
Reproduce code:
---
print(strtotime("11/20/2005 8:00 AM\r\n"));
Expected result:
1132488000
--
Edit this bug report at http://bugs.php.net/?id=35499&edit=1
#35505 [NEW]: strtotime broken
From: mvl22 at cam dot ac dot uk
Operating system: Linux
PHP version: 5.1.1
PHP Bug Type: Date/time related
Bug description: strtotime broken
Description:
echo strtotime ('1st December 2005 GMT');
fails - no output is produced.
Actual result:
--
[No output]
--
Edit bug report at http://bugs.php.net/?id=35505&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35505&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35505&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35505&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35505&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35505&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35505&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35505&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35505&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35505&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35505&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35505&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35505&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35505&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35505&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35505&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35505&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35505&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35505&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35505&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35505&r=mysqlcfg
#35504 [NEW]: Can only use c:\windows for php.ini dir.
From: thejkwhosaysni at gmail dot com Operating system: win32 PHP version: 5.1.1 PHP Bug Type: *Configuration Issues Bug description: Can only use c:\windows for php.ini dir. Description: Since php5.1 I have been unable to use php.ini from any directory other than c:\windows. This is a pain because i have apache2 running as a seperate user which I don't really want accessing any directories than it needs to. php5.0.* worked fine with php.ini in the \apache2\ directory. I tried overwriting my original php.ini (from when i installed 5.0) with the php.ini-dist from 5.1.1 with no avail. php refuses to see that it's there. I also trid the \php directory with both my php.ini and the default php.ini-dist. Neither worked. I first noticed this with 5.1.0 and the problem is still present in 5.1.1 Reproduce code: --- I just extracted php5.1.0 into the directory that I had php5.0.* installed into. -- Edit bug report at http://bugs.php.net/?id=35504&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35504&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35504&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35504&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35504&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35504&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35504&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35504&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35504&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35504&r=support Expected behavior:http://bugs.php.net/fix.php?id=35504&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35504&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35504&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35504&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35504&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35504&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35504&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35504&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35504&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35504&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35504&r=mysqlcfg
#35484 [Opn]: segmentation faults with multiple include virtual
ID: 35484 User updated by: minnoce at polito dot it Reported By: minnoce at polito dot it Status: Open Bug Type: Apache2 related Operating System: Linux RHEL 4 PHP Version: 5.1.1 New Comment: Obviously, the expected output is: TESTTEST Previous Comments: [2005-12-01 16:28:50] minnoce at polito dot it mmm... Compiling PHP with --enable-debug and reproducing the bug (getting the "test.html" with the two include virtuals) don't cause anymore segmentatio faults. But simply the last "include virtual" produce NO output at all (no errors in apache logs). The output received from browser getting "test.html" is: TEST Thanks, Mauro [2005-12-01 15:58:54] [EMAIL PROTECTED] Please provide current backtrace. And make sure you had --enable-debug in your configure line! Also, don't submit ALL the lines, just the relevant ones. (The "loading symbols.." lines are not needed) [2005-12-01 15:48:55] minnoce at polito dot it The bug persist even with the LATEST PHP 5.1 from CVS. The GDB backtrace is exactly the same already reported. Thanks, Mauro [2005-12-01 15:10:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-30 12:31:36] minnoce at polito dot it Description: I'm compiling PHP with this configuration line: ./configure \ "--prefix=/services/php-4.4-CVS" \ "--with-apxs2=/services/apache/bin/apxs" \ "--with-openssl" \ "--with-config-file-path=/services/httpd/conf" \ "--with-mysql=/usr" \ "--with-zlib" \ "--with-gd" \ "--with-jpeg-dir" \ "--with-png-dir" \ "--with-ldap" \ "--with-freetype-dir" \ "--with-mcrypt=/services/libmcrypt" \ "--with-curl" \ "--with-freetds=/services/freetds" \ "--enable-mbstring" All the PHP 4.3.11, 4.4.1, 4.4-LATEST-CVS used as module under Apache 2.0.54 work fine. All the PHP 4.3.11, 4.4.1m 4.4-LATEST-CVS used as module under Apache 2.0.55 cause a segmentation fault when I try to include some PHP script with more than one Apache's "include virtual" (even a simple ). Examples: - test.html - test.php With only one "include virtual" all works fine. With the two include virtual the Apache child process associated exit with segmentation fault after the output of the first include. -- Edit this bug report at http://bugs.php.net/?id=35484&edit=1
#35484 [Fbk->Opn]: segmentation faults with multiple include virtual
ID: 35484 User updated by: minnoce at polito dot it Reported By: minnoce at polito dot it -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Linux RHEL 4 PHP Version: 5.1.1 New Comment: mmm... Compiling PHP with --enable-debug and reproducing the bug (getting the "test.html" with the two include virtuals) don't cause anymore segmentatio faults. But simply the last "include virtual" produce NO output at all (no errors in apache logs). The output received from browser getting "test.html" is: TEST Thanks, Mauro Previous Comments: [2005-12-01 15:58:54] [EMAIL PROTECTED] Please provide current backtrace. And make sure you had --enable-debug in your configure line! Also, don't submit ALL the lines, just the relevant ones. (The "loading symbols.." lines are not needed) [2005-12-01 15:48:55] minnoce at polito dot it The bug persist even with the LATEST PHP 5.1 from CVS. The GDB backtrace is exactly the same already reported. Thanks, Mauro [2005-12-01 15:10:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-30 12:31:36] minnoce at polito dot it Description: I'm compiling PHP with this configuration line: ./configure \ "--prefix=/services/php-4.4-CVS" \ "--with-apxs2=/services/apache/bin/apxs" \ "--with-openssl" \ "--with-config-file-path=/services/httpd/conf" \ "--with-mysql=/usr" \ "--with-zlib" \ "--with-gd" \ "--with-jpeg-dir" \ "--with-png-dir" \ "--with-ldap" \ "--with-freetype-dir" \ "--with-mcrypt=/services/libmcrypt" \ "--with-curl" \ "--with-freetds=/services/freetds" \ "--enable-mbstring" All the PHP 4.3.11, 4.4.1, 4.4-LATEST-CVS used as module under Apache 2.0.54 work fine. All the PHP 4.3.11, 4.4.1m 4.4-LATEST-CVS used as module under Apache 2.0.55 cause a segmentation fault when I try to include some PHP script with more than one Apache's "include virtual" (even a simple ). Examples: - test.html - test.php With only one "include virtual" all works fine. With the two include virtual the Apache child process associated exit with segmentation fault after the output of the first include. -- Edit this bug report at http://bugs.php.net/?id=35484&edit=1
#35484 [Opn->Fbk]: segmentation faults with multiple include virtual
ID: 35484 Updated by: [EMAIL PROTECTED] Reported By: minnoce at polito dot it -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Linux RHEL 4 PHP Version: 5.1.1 New Comment: Please provide current backtrace. And make sure you had --enable-debug in your configure line! Also, don't submit ALL the lines, just the relevant ones. (The "loading symbols.." lines are not needed) Previous Comments: [2005-12-01 15:48:55] minnoce at polito dot it The bug persist even with the LATEST PHP 5.1 from CVS. The GDB backtrace is exactly the same already reported. Thanks, Mauro [2005-12-01 15:10:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-30 12:31:36] minnoce at polito dot it Description: I'm compiling PHP with this configuration line: ./configure \ "--prefix=/services/php-4.4-CVS" \ "--with-apxs2=/services/apache/bin/apxs" \ "--with-openssl" \ "--with-config-file-path=/services/httpd/conf" \ "--with-mysql=/usr" \ "--with-zlib" \ "--with-gd" \ "--with-jpeg-dir" \ "--with-png-dir" \ "--with-ldap" \ "--with-freetype-dir" \ "--with-mcrypt=/services/libmcrypt" \ "--with-curl" \ "--with-freetds=/services/freetds" \ "--enable-mbstring" All the PHP 4.3.11, 4.4.1, 4.4-LATEST-CVS used as module under Apache 2.0.54 work fine. All the PHP 4.3.11, 4.4.1m 4.4-LATEST-CVS used as module under Apache 2.0.55 cause a segmentation fault when I try to include some PHP script with more than one Apache's "include virtual" (even a simple ). Examples: - test.html - test.php With only one "include virtual" all works fine. With the two include virtual the Apache child process associated exit with segmentation fault after the output of the first include. -- Edit this bug report at http://bugs.php.net/?id=35484&edit=1
#32220 [Asn]: [PATCH] thread_resources for thread not getting freed when apache kills thread
ID: 32220 Updated by: [EMAIL PROTECTED] Reported By: kameshj at fastmail dot fm Status: Assigned Bug Type: Apache2 related Operating System: * PHP Version: 5CVS, 4CVS (2005-03-25) Assigned To: dmitry New Comment: I confirm that PHP doesn't call ts_free_thread() if Web Server (except IIS) kills some thread. As a result all thread resources are not freed before server shutdown. The proposed patch is invalid and even cannot be compiled on Linux. Previous Comments: [2005-11-10 18:36:39] [EMAIL PROTECTED] Yes, but did you check out the patch..? [2005-11-08 09:50:11] [EMAIL PROTECTED] I am not able to reproduce this. Seems like a mess in report. Apache2 worker MPM doesn't support StartThreads and MaxThreads directives. [2005-11-03 22:21:58] [EMAIL PROTECTED] Dmitry, can you check this out? [2005-03-25 02:05:13] [EMAIL PROTECTED] Zeev, here's another thread issue, can you take a look in the patch? [2005-03-25 02:04:47] [EMAIL PROTECTED] Assuming this is not fixed in latest HEAD, PHP_5_0 or PHP_4_3 CVS branches. 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/32220 -- Edit this bug report at http://bugs.php.net/?id=32220&edit=1
#35484 [Fbk->Opn]: segmentation faults with multiple include virtual
ID: 35484 User updated by: minnoce at polito dot it Reported By: minnoce at polito dot it -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Linux RHEL 4 PHP Version: 5.1.1 New Comment: The bug persist even with the LATEST PHP 5.1 from CVS. The GDB backtrace is exactly the same already reported. Thanks, Mauro Previous Comments: [2005-12-01 15:10:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-12-01 15:06:34] minnoce at polito dot it Please Re-Open! The bug #35029 as marked Closed, but the bug is still there! I reproduced this bug on Apache 2.0.55 + PHP 5.1.1 as module (all compiled from sources). The compile configurations are as shown above (in my previous comment). Follow the complete GDB backtrace: # gdb /services/apache/bin/httpd /tmp/php/core.29747 GNU gdb Red Hat Linux (6.3.0.0-1.63rh) 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 "i386-redhat-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/services/apache/bin/httpd -f /services/httpd/conf/httpd.conf -d /services/apac'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libssl.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libssl.so.4 Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /dati/services/apache_so-2.0.55/lib/libaprutil-0.so.0... (no debugging symbols found)...done. Loaded symbols for /services/apache_so-2.0.55/lib/libaprutil-0.so.0 Reading symbols from /usr/lib/libgdbm.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgdbm.so.2 Reading symbols from /lib/tls/i686/libdb-4.2.so...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/libdb-4.2.so Reading symbols from /usr/lib/libexpat.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /dati/services/apache_so-2.0.55/lib/libapr-0.so.0... (no debugging symbols found)...done. Loaded symbols for /services/apache_so-2.0.55/lib/libapr-0.so.0 Reading symbols from /lib/tls/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/librt.so.1 Reading symbols from /lib/tls/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libnsl.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /dati/services/apache_so-2.0.55/modules/libphp551.so...(no debugging symbols found)...done. Loaded symbols for /services/apache/modules/libphp551.so Reading symbols from /usr/lib/libmysqlclient.so.14... (no debugging symbols found)...done. Loaded symbols for /usr/li
#35484 [Opn->Fbk]: segmentation faults with multiple include virtual
ID: 35484 Updated by: [EMAIL PROTECTED] Reported By: minnoce at polito dot it -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Linux RHEL 4 PHP Version: 5.1.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-12-01 15:06:34] minnoce at polito dot it Please Re-Open! The bug #35029 as marked Closed, but the bug is still there! I reproduced this bug on Apache 2.0.55 + PHP 5.1.1 as module (all compiled from sources). The compile configurations are as shown above (in my previous comment). Follow the complete GDB backtrace: # gdb /services/apache/bin/httpd /tmp/php/core.29747 GNU gdb Red Hat Linux (6.3.0.0-1.63rh) 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 "i386-redhat-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/services/apache/bin/httpd -f /services/httpd/conf/httpd.conf -d /services/apac'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libssl.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libssl.so.4 Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /dati/services/apache_so-2.0.55/lib/libaprutil-0.so.0... (no debugging symbols found)...done. Loaded symbols for /services/apache_so-2.0.55/lib/libaprutil-0.so.0 Reading symbols from /usr/lib/libgdbm.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgdbm.so.2 Reading symbols from /lib/tls/i686/libdb-4.2.so...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/libdb-4.2.so Reading symbols from /usr/lib/libexpat.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /dati/services/apache_so-2.0.55/lib/libapr-0.so.0... (no debugging symbols found)...done. Loaded symbols for /services/apache_so-2.0.55/lib/libapr-0.so.0 Reading symbols from /lib/tls/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/librt.so.1 Reading symbols from /lib/tls/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libnsl.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /dati/services/apache_so-2.0.55/modules/libphp551.so...(no debugging symbols found)...done. Loaded symbols for /services/apache/modules/libphp551.so Reading symbols from /usr/lib/libmysqlclient.so.14... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libmysqlclient.so.14 Reading symbols from /dati/services/libmcrypt-2.5.7/lib/libmcrypt.so.4...(no debugging symbols found)...done. Loaded symbols for /services/libmcrypt-2.5.7/lib/libmcrypt.so.4 Reading symbols from /usr/lib/libltdl.so.3...(no deb
#35484 [Bgs->Opn]: segmentation faults with multiple include virtual
ID: 35484 User updated by: minnoce at polito dot it Reported By: minnoce at polito dot it -Status: Bogus +Status: Open Bug Type: Apache2 related Operating System: Linux RHEL 4 -PHP Version: 4.4.2RC1 +PHP Version: 5.1.1 New Comment: Please Re-Open! The bug #35029 as marked Closed, but the bug is still there! I reproduced this bug on Apache 2.0.55 + PHP 5.1.1 as module (all compiled from sources). The compile configurations are as shown above (in my previous comment). Follow the complete GDB backtrace: # gdb /services/apache/bin/httpd /tmp/php/core.29747 GNU gdb Red Hat Linux (6.3.0.0-1.63rh) 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 "i386-redhat-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/services/apache/bin/httpd -f /services/httpd/conf/httpd.conf -d /services/apac'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libssl.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libssl.so.4 Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /dati/services/apache_so-2.0.55/lib/libaprutil-0.so.0... (no debugging symbols found)...done. Loaded symbols for /services/apache_so-2.0.55/lib/libaprutil-0.so.0 Reading symbols from /usr/lib/libgdbm.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgdbm.so.2 Reading symbols from /lib/tls/i686/libdb-4.2.so...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/libdb-4.2.so Reading symbols from /usr/lib/libexpat.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /dati/services/apache_so-2.0.55/lib/libapr-0.so.0... (no debugging symbols found)...done. Loaded symbols for /services/apache_so-2.0.55/lib/libapr-0.so.0 Reading symbols from /lib/tls/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/librt.so.1 Reading symbols from /lib/tls/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libnsl.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /dati/services/apache_so-2.0.55/modules/libphp551.so...(no debugging symbols found)...done. Loaded symbols for /services/apache/modules/libphp551.so Reading symbols from /usr/lib/libmysqlclient.so.14... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libmysqlclient.so.14 Reading symbols from /dati/services/libmcrypt-2.5.7/lib/libmcrypt.so.4...(no debugging symbols found)...done. Loaded symbols for /services/libmcrypt-2.5.7/lib/libmcrypt.so.4 Reading symbols from /usr/lib/libltdl.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /usr/lib/libldap-2.2.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libldap-2.2.so.7 Reading symbols from /usr/lib/liblber-2.2.so.7... (no debuggin
#35490 [Opn->Csd]: socket_sendto() unable to handle IPv6 addresses
ID: 35490
Updated by: [EMAIL PROTECTED]
Reported By: Xavier dot Redon at polytech-lille dot fr
-Status: Open
+Status: Closed
Bug Type: Sockets related
Operating System: Linux 2.6
PHP Version: 5.1.1
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-11-30 14:55:45] Xavier dot Redon at polytech-lille dot fr
Description:
When executing the script below an error occurs.
A trace with strace show that the struct sockaddr of the system call
sendto is uninitialized (or badly initialized) :
sendto(3, "Test Message", 12, 0, {sa_family=0x45a0 /* AF_??? */,
sa_data="<\10\20\0\0\0\20\0\0\0\250\376\343\277"}, 16) = -1 EINVAL
(Invalid argument)
Reproduce code:
---
Expected result:
an IPv6 UDP datagram should be sent to the IPv6 loopback address.
Actual result:
--
Warning: socket_sendto(): unable to write to socket [22]: Invalid
argument in /tmp/toto.php on line 12
--
Edit this bug report at http://bugs.php.net/?id=35490&edit=1
#35499 [Asn]: strtotime with newline fails
ID: 35499
Updated by: [EMAIL PROTECTED]
Reported By: stabthecat at hotmail dot com
Status: Assigned
Bug Type: Date/time related
Operating System: Windows / Linux
PHP Version: 5.1.1
Assigned To: iliaa
New Comment:
http://mega.ist.utl.pt/~ncpl/php_35499_patch.txt
Previous Comments:
[2005-12-01 01:22:59] stabthecat at hotmail dot com
Description:
Since version 5.1
strtotime("11/20/2005 8:00 AM\r\n");
fails, and returns null
strtotime(trim("11/20/2005 8:00 AM\r\n"));
fixes it
Reproduce code:
---
print(strtotime("11/20/2005 8:00 AM\r\n"));
Expected result:
1132488000
--
Edit this bug report at http://bugs.php.net/?id=35499&edit=1
#35499 [Opn->Asn]: strtotime with newline fails
ID: 35499
Updated by: [EMAIL PROTECTED]
Reported By: stabthecat at hotmail dot com
-Status: Open
+Status: Assigned
Bug Type: Date/time related
Operating System: Windows / Linux
PHP Version: 5.1.1
-Assigned To:
+Assigned To: ilia
Previous Comments:
[2005-12-01 01:22:59] stabthecat at hotmail dot com
Description:
Since version 5.1
strtotime("11/20/2005 8:00 AM\r\n");
fails, and returns null
strtotime(trim("11/20/2005 8:00 AM\r\n"));
fixes it
Reproduce code:
---
print(strtotime("11/20/2005 8:00 AM\r\n"));
Expected result:
1132488000
--
Edit this bug report at http://bugs.php.net/?id=35499&edit=1
#35500 [Opn->Fbk]: auto_prepend_file seems to fail randomly
ID: 35500 Updated by: [EMAIL PROTECTED] Reported By: bugnet at gartenfreunde dot eu dot org -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: Linux 2.6.13-gentoo-r5 SMP AMD64 PHP Version: 5.1.1 Previous Comments: [2005-12-01 14:20:33] bugnet at gartenfreunde dot eu dot org I can't use source tarballs. I installed PHP 5.1.1 from http://svn.gnqs.org/projects/gentoo-php-overlay/wiki I'll report back if the problem still occurs. [2005-12-01 12:35:41] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-12-01 12:30:32] bugnet at gartenfreunde dot eu dot org Description: I'm using PHP Version 5.0.5-pl3-gentoo (no way to upgrade to 5.1.1) and Apache 2.0.54 with mpm_worker. Approx. 10 times a day I get an errormessage like the following, the rest of the time (5+ requests) everything works fine: [Thu Dec 01 11:17:18 2005] [error] [client x.x.x.x] PHP Warning: main() [function.include]: Failed opening 'lib_tools.php' for inclusion (include_path='/var/www/includes') in /var/www/htdocs/index.php on line 22, referer: http://xxx [Thu Dec 01 11:17:18 2005] [error] [client x.x.x.x] PHP Warning: main() [function.include]: Failed opening 'lib_session.php' for inclusion (include_path='/var/www/includes') in /var/www/htdocs/index.php on line 25, referer: http://xxx index.php looks like this: <-snip-> include_once ($lib_dir.'lib_tools.php'); include_once ($lib_dir.'lib_session.php'); <-snip-> $lib_dir is set in prepend.php, httpd.conf reads: php_value auto_prepend_file /var/www/prepend.php When the error occurs $lib_dir is empty, so it looks like the prepend file doesn't get prepended under some conditions. I'm not sure if this is an PHP or an Apache issue, on our old system running PHP4 and Apache 1.x the problem didn't occur. Reproduce code: --- occurs randomly approx 10 times a day, regardsless of systemload etc. Expected result: a file listed in auto_prepend_file should always be prepended -- Edit this bug report at http://bugs.php.net/?id=35500&edit=1
#35500 [Fbk->Opn]: auto_prepend_file seems to fail randomly
ID: 35500 User updated by: bugnet at gartenfreunde dot eu dot org Reported By: bugnet at gartenfreunde dot eu dot org -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Linux 2.6.13-gentoo-r5 SMP AMD64 PHP Version: 5.1.1 New Comment: I can't use source tarballs. I installed PHP 5.1.1 from http://svn.gnqs.org/projects/gentoo-php-overlay/wiki I'll report back if the problem still occurs. Previous Comments: [2005-12-01 12:35:41] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-12-01 12:30:32] bugnet at gartenfreunde dot eu dot org Description: I'm using PHP Version 5.0.5-pl3-gentoo (no way to upgrade to 5.1.1) and Apache 2.0.54 with mpm_worker. Approx. 10 times a day I get an errormessage like the following, the rest of the time (5+ requests) everything works fine: [Thu Dec 01 11:17:18 2005] [error] [client x.x.x.x] PHP Warning: main() [function.include]: Failed opening 'lib_tools.php' for inclusion (include_path='/var/www/includes') in /var/www/htdocs/index.php on line 22, referer: http://xxx [Thu Dec 01 11:17:18 2005] [error] [client x.x.x.x] PHP Warning: main() [function.include]: Failed opening 'lib_session.php' for inclusion (include_path='/var/www/includes') in /var/www/htdocs/index.php on line 25, referer: http://xxx index.php looks like this: <-snip-> include_once ($lib_dir.'lib_tools.php'); include_once ($lib_dir.'lib_session.php'); <-snip-> $lib_dir is set in prepend.php, httpd.conf reads: php_value auto_prepend_file /var/www/prepend.php When the error occurs $lib_dir is empty, so it looks like the prepend file doesn't get prepended under some conditions. I'm not sure if this is an PHP or an Apache issue, on our old system running PHP4 and Apache 1.x the problem didn't occur. Reproduce code: --- occurs randomly approx 10 times a day, regardsless of systemload etc. Expected result: a file listed in auto_prepend_file should always be prepended -- Edit this bug report at http://bugs.php.net/?id=35500&edit=1
#35437 [Asn->Csd]: Segfault or Invalid Opcode 137/1/4
ID: 35437
Updated by: [EMAIL PROTECTED]
Reported By: me at dither dot spb dot ru
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS-2005-11-28 (cvs)
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD, PHP_5_1 and PHP_5_0.
Previous Comments:
[2005-11-29 05:11:20] me at dither dot spb dot ru
That means bug has been confirmed?
[2005-11-28 17:53:25] [EMAIL PROTECTED]
Here's GDB backtrace:
0x0820c3bf in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe14f80) at
/usr/src/php_5_1/Zend/zend_vm_execute.h:131
131 if (EX(function_state).function->common.fn_flags &
ZEND_ACC_ABSTRACT) {
(gdb) bt
#0 0x0820c3bf in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe14f80) at
/usr/src/php_5_1/Zend/zend_vm_execute.h:131
#1 0x0820d0d7 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe14f80) at
/usr/src/php_5_1/Zend/zend_vm_execute.h:310
#2 0x0820c30c in execute (op_array=0x9bd5d2c) at
/usr/src/php_5_1/Zend/zend_vm_execute.h:88
#3 0x0820c792 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe150d0) at
/usr/src/php_5_1/Zend/zend_vm_execute.h:222
#4 0x0820d0d7 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe150d0) at
/usr/src/php_5_1/Zend/zend_vm_execute.h:310
#5 0x0820c30c in execute (op_array=0x9bcff0c) at
/usr/src/php_5_1/Zend/zend_vm_execute.h:88
#6 0x081e3eca in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php_5_1/Zend/zend.c:1090
#7 0x081a234e in php_execute_script (primary_file=0xbfe17500) at
/usr/src/php_5_1/main/main.c:1704
#8 0x08252300 in main (argc=2, argv=0xbfe175d4) at
/usr/src/php_5_1/sapi/cli/php_cli.c:1039
[2005-11-28 17:43:49] me at dither dot spb dot ru
PHP 5.1.2-dev (cli) (built: Nov 27 2005 20:24:18) (Win32).
No changes. Problem persists. Sorry, I dont have enought time to test
latest unix snapshot. If needed, I can do some testing across different
unix versions tomorrow.
Omg, sorry for my bad english..
[2005-11-28 09:13:58] [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-11-28 04:19:49] me at dither dot spb dot ru
Description:
PHP 5.1 Final Release.
(built: Nov 23 2005 23:59:35)
Easy repoducible segfault or Invalid opcode 137/1/4 Fatal Error.
Reproduce code:
---
Expected result:
PHP Should cause Strict level Notice "Non-static method
TestClass::testMethod() should not be called statically", and after
what error_handler err2exception() must be executed.
Finally, it must be an Uncaught exception 'Exception' with message
'Error occuried: Non-static method TestClass::testMethod() should not
be called statically'.
Actual result:
--
Segfault.
Uncommenting line //$GLOBALS['t'] = 'test' causes Invalid opcode
137/1/4 Fatal Error.
Commenting both $GLOBALS lines completly fixes bug.
Marking method testMethod() as static (... static function testMethod()
...) fixes bug too, but no exception will be thrown.
--
Edit this bug report at http://bugs.php.net/?id=35437&edit=1
#35502 [Bgs]: PHP 5.1.1 CGI does not attempt to read php.ini from current directory
ID: 35502
User updated by: andrew dot tulloch at maximalls dot com
Reported By: andrew dot tulloch at maximalls dot com
Status: Bogus
Bug Type: CGI related
Operating System: Linux
PHP Version: 5.1.1
New Comment:
Could I get a reason for this is not being a bug?
It certainly seems to be a regression from 5.0.5 unless this feature
was previously unintended and now considered corrected.
Previous Comments:
[2005-12-01 13:10:21] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2005-12-01 12:47:55] andrew dot tulloch at maximalls dot com
Description:
PHP 5.0.5 CGI SAPI attempts to read php.ini from the current directory,
PHP 5.1.1 CGI SAPI, compiled with same options does not.
Reproduce code:
---
strace php 2>&1 | grep php.ini
Expected result:
Expected and actual running PHP 5.0.5:
strace /opt/php-5.0.5/bin/php 2>&1 | grep php.ini
open("./php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/opt/php-5.0.5/bin//php.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/opt/php-5.0.5/lib/php.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
Note attempt to read php.ini from current directory.
Actual result:
--
Running PHP 5.1.1:
strace /opt/php-5.1.1/bin/php 2>&1 | grep php.ini
open("/opt/php-5.1.1/bin/php.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/opt/php-5.1.1/lib/php.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
No attempt to read php.ini from current directory.
--
Edit this bug report at http://bugs.php.net/?id=35502&edit=1
#35104 [Asn->Bgs]: __set() and read-only property prevents proper Class inheritence
ID: 35104
Updated by: [EMAIL PROTECTED]
Reported By: php at tjworld dot net
-Status: Assigned
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows 2003
PHP Version: 5.1.0RC5
Assigned To: dmitry
New Comment:
This is not a bug, but ext/dom limitation.
Nothing to fix.
Previous Comments:
[2005-11-05 03:03:07] php at tjworld dot net
... and I should have added that returning a DOMDocumentFragment is not
practical because adding attributes and nodes to the new element would
then require new indirect code in the application - you can't add them
to the returned DOMDocumentFragment.
So returning the new sub-class object requires it be removed from the
DOMDocumentFragment *and* more importantly have a variable-reference to
it so that its reference counter isn't zero when the method exits -
otherwise it is destroyed and the caller can't do anything with it, and
will get a:
Warning: DOMElement::setAttribute(): Couldn't fetch extDOMElement
in...
trying to set an attribute on the new sub-classed object.
[2005-11-05 02:56:43] php at tjworld dot net
Based on real-world experience the previous example is not sufficent -
the new Element is destroyed along with the DOMDocumentFragment when
the method exits.
The fix is to remove the new element from the DOMDocumentFragment
before returning it to the caller.
Here's an updated, tested example.
createDocumentFragment(); // lightweight
container maintains "ownerDocument"
$docFragment->appendChild($orphan); // attach
$ret = $docFragment->removeChild($orphan); // remove
return $ret; // ownerDocument set; won't be destroyed on method
exit
}
// .. more class definition
}
class extDOMElement extends DOMElement {
function __construct($name, $value='', $namespaceURI=null) {
parent::__construct($name, $value, $namespaceURI);
}
// ... more class definition here
}
$doc = new extDOMDocument('test');
$el = $doc->createElement('tagname');
// append discards the DOMDocumentFragment and just adds its child
nodes, but ownerDocument is maintained.
$doc->appendChild($el);
echo $doc->saveXML();
?>
[2005-11-05 01:00:04] php at tjworld dot net
And finally... for completeness here's a worked example that solves the
DOM case of setting the ownerDocument property.
createDocumentFragment(); // lightweight
container maintains "ownerDocument"
$docFragment->appendChild($orphan); // attach
return $docFragment;
}
// .. more class definition
}
class extDOMElement extends DOMElement {
function __construct($name, $value='', $namespaceURI=null) {
parent::__construct($name, $value, $namespaceURI);
}
// ... more class definition here
}
$doc = new extDOMDocument('test');
$el = $doc->createElement('tagname');
// append discards the DOMDocumentFragment and just adds its child
nodes, but ownerDocument is maintained.
$doc->appendChild($el);
echo $doc->saveXML();
?>
TJ.
[2005-11-05 00:02:41] php at tjworld dot net
Following on from my suggestion to provide a strong design template for
read-only properties and inheritence, I've put together the following
example.
It provides for inheritence of a read-only property so the property can
be modified from sub-classes.
realProperty = 12;
$this->test = 'read-only';
}
public function __set($name, $value) {
if($name=='test') {
if(get_class($this)==__CLASS__ &&
isset($this->dynamicProperty[$name]))
throw new Exception(self::CLASS_READ_ONLY_PROPERTY_ERR);
else
$this->dynamicProperty[$name] = $value;
}
}
public function __get($name) { return $this->dynamicProperty[$name];
}
public function getReal() {return $this->realProperty; }
public function getDynamic() {return $this->test; }
}
class Writeable extends ReadOnly {
function __construct($value) {
parent::__construct();
$this->realProperty = 25; // ok
$this->test = $value; // causes Fatal Error
}
}
echo "Testing Writeable...\r\n";
$test = new Writeable('write to me');
echo 'real: '.$test->getReal()."\r\n";
echo 'dynamic: '.$test->getDynamic()."\r\n";
echo "Testing ReadOnly...\r\n";
$test = new ReadOnly();
echo 'real: '.$test->getReal()."\r\n";
echo 'dynamic: '.$test->getDynamic()."\r\n";
try {
$test->test = "can't change me";
}
catch(Exception $e) {
if ($e->getMessage() == ReadOnly::CLASS_READ_ONLY_PROPERTY_ERR) echo
"Read-only Property Exception";
}
?>
Thanks for your prompt and considered attention to this issue.
Hopefully this provides a solution that elegantly solves the issue for
all concerned.
TJ.
Nottingham, UK
[2005-11-04 23:32:22] php at tjworld dot net
Thanks for the
#35501 [Opn->Bgs]: array storage and access
ID: 35501 Updated by: [EMAIL PROTECTED] Reported By: robing9 at yahoo dot com -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Windows XP SP2 -PHP Version: 5CVS-2005-12-01 (snap) +PHP Version: 5.0.4 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: [2005-12-01 12:40:10] robing9 at yahoo dot com Description: I am working with a uniserver with Apache 2.0.54, ActivePerl 5.8.7.813, PHP 5.0.4, MySQL 4.1.12a, phpMyAdmin-2.6.3-rc1 When I stored some data in a array with key field in integer but in a jumbled manner (insted of 1,2,3,4 as the key values i gave 0,1,4,2,3). Then when i printed it using the print_r function I got the data in the order of the key values 0,1,4,2,3. But shouldn't it have come in the order 0,1,2,3,4? I have written the code below. PS : I couldnt find a relevant PHP version so I selected 5CVS 2005-12-01(snap) Reproduce code: --- Expected result: Array ( [0] => robin [1] => tony [2] => pradeep [3] => prem [4] => Sini ) Actual result: -- Array ( [0] => robin [1] => tony [4] => Sini [2] => pradeep [3] => prem ) -- Edit this bug report at http://bugs.php.net/?id=35501&edit=1
#35482 [Opn->Bgs]: Bad performance of filesystem functions on Windows XP Professional
ID: 35482
Updated by: [EMAIL PROTECTED]
Reported By: tobias-bender at web dot de
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: Windows XP Professional
PHP Version: 5.1.1
New Comment:
Comparing PHP 5 with PHP 4 is like comparing apples and oranges. This
is inherent problem in Windows, not a bug.
Previous Comments:
[2005-12-01 00:03:12] tobias-bender at web dot de
I think this has to be analysed on a Windows platform
[2005-11-30 10:30:11] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Can't reproduce on Linux.
[2005-11-30 01:25:57] tobias-bender at web dot de
Description:
All filesystem functions got much slower with PHP 5.x.
With short relative paths PHP 4 is about twice as fast as PHP 5. PHP 5
is nearly 10 times slower when using absolute paths compared to PHP 4.
Reproduce code:
---
function getMicrotime(){
list($usec, $sec) = explode(' ', microtime());
return ((float)$usec + (float)$sec);
}
$iTime = getMicrotime();
$rHandle = opendir('C:/Apache2/htdocs/phpXplorer/test/vollvoll');
while (false !== ($sName = readdir($rHandle))) {
if (is_dir('C:/Apache2/htdocs/phpXplorer/test/vollvoll/' . $sName)){
echo 'C:/Apache2/htdocs/phpXplorer/test/vollvoll/' . $sName .
'';
}
}
echo getMicrotime() - $iTime;
--
Edit this bug report at http://bugs.php.net/?id=35482&edit=1
#35502 [Opn->Bgs]: PHP 5.1.1 CGI does not attempt to read php.ini from current directory
ID: 35502
Updated by: [EMAIL PROTECTED]
Reported By: andrew dot tulloch at maximalls dot com
-Status: Open
+Status: Bogus
Bug Type: CGI related
Operating System: Linux
PHP Version: 5.1.1
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2005-12-01 12:47:55] andrew dot tulloch at maximalls dot com
Description:
PHP 5.0.5 CGI SAPI attempts to read php.ini from the current directory,
PHP 5.1.1 CGI SAPI, compiled with same options does not.
Reproduce code:
---
strace php 2>&1 | grep php.ini
Expected result:
Expected and actual running PHP 5.0.5:
strace /opt/php-5.0.5/bin/php 2>&1 | grep php.ini
open("./php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/opt/php-5.0.5/bin//php.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/opt/php-5.0.5/lib/php.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
Note attempt to read php.ini from current directory.
Actual result:
--
Running PHP 5.1.1:
strace /opt/php-5.1.1/bin/php 2>&1 | grep php.ini
open("/opt/php-5.1.1/bin/php.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/opt/php-5.1.1/lib/php.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
No attempt to read php.ini from current directory.
--
Edit this bug report at http://bugs.php.net/?id=35502&edit=1
#35288 [Opn]: make test fails on FreeBSD
ID: 35288
User updated by: webmaster at negeta dot com
Reported By: webmaster at negeta dot com
Status: Open
Bug Type: ICONV related
Operating System: FreeBSD 5.4
-PHP Version: 5.1.0
+PHP Version: 5.1.1
New Comment:
I specified the path of iconv explicitly.
I ran './configure --with-iconv=/usr/local',
and HAVE_LIBICONV was defined.
'libiconv' comes before 'iconv' when the path is specified.
But above priority is inverted when the path is not specified.
I was able to avoid this problem by using this difference.
I hope 'libiconv' comes before 'iconv' automatically
on the system that has both functions.
But, I will back out this problem if this difference
was designed for changing priority of them manually.
Previous Comments:
[2005-11-23 13:51:20] webmaster at negeta dot com
FreeBSD base system has no iconv library
which is usable by other executable.
FreeBSD does not contain the glibc,
and libiconv.so is not installed in base system.
I found '/usr/include/sys/iconv.h',
but it is used by some kernel modules.
Conflict will not occur because PHP does not
include "sys/iconv.h."
I removed libiconv and ran './configure',
then following error occured:
% tail -15 config.log
configure:19817: gcc -o conftest -g -O2 -R/usr/local/lib
-L/usr/local/lib conftest.c
-lm -lxml2 -lz -liconv -lm 1>&5
/usr/bin/ld: cannot find -liconv
configure: failed program was:
#line 19806 "configure"
#include "confdefs.h"
char xmlInitParser();
int main() {
xmlInitParser();
return 0;
}
[2005-11-23 09:29:38] [EMAIL PROTECTED]
So you didn't read the comment above those checks?
Try removing that libiconv you installed and try again.
And make sure the installation of libiconv did NOT write over the
system iconv.h !!!
[2005-11-21 17:49:34] webmaster at negeta dot com
I ran "./configure"
I only installed libiconv-1.9.2 from FreeBSD ports
'converters/libiconv.'
libiconv has C function "iconv" in 'lib/iconv.c',
and alias name "libiconv" is defined in 'include/iconv.h.'
And a program can use "iconv" as "libiconv."
'configure' detects function "iconv" first.
And it detects "libiconv" when "iconv" was not found.
And HAVE_ICONV is defined and HAVE_LIBICONV is not defined.
When 'ext/iconv/iconv.c :line 68' is compiled,
PHP_NAMED_FE(iconv,php_if_iconv, ...
is understood as
PHP_NAMED_FE(libiconv,php_if_iconv, ...
by compiler. Because
#ifdef HAVE_LIBICONV
#undef iconv
#endif
skips undefine "iconv."
To solve this, I thought that HAVE_LIBICONV is necessary.
I read acinclude.m4, and found the order of "iconv" and "libiconv."
If 'configure' detect "libiconv" first,
then it will define HAVE_ICONV and HAVE_LIBICONV.
And if system has only "iconv", then it will not define HAVE_LIBICONV.
Maybe Linux system is not influenced by this problem.
Because these system has iconv of glibc, and there is no "libiconv."
[2005-11-21 16:06:49] [EMAIL PROTECTED]
What was the configure line used?
And where exactly is iconv AND libiconv defined in your system? Do you
have 2 different implementations installed under same prefix? If you
do, this is not PHP bug and not possible to solve with that patch.
[2005-11-21 05:35:31] webmaster at negeta dot com
> 0. C function "iconv" is exist, and "libiconv" is not.
It's not correct and my mistake.
Both functions are available in my system.
Please check "libiconv" before checking "iconv."
Then HAVE_ICONV and HAVE_LIBICONV are defined by configure,
and the problem is not reproduce in my system.
Please commit this patch if it looks like good.
http://www.negeta.com/misc/acinclude.m4.patch
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/35288
--
Edit this bug report at http://bugs.php.net/?id=35288&edit=1
#35461 [Com]: Ming extension fails to compile
ID: 35461 Comment by: patrick at pmenier dot dynalias dot net Reported By: hostmaster at xenterra dot net Status: Assigned Bug Type: Ming related Operating System: Slackware Linux 10.2 PHP Version: 5CVS-2005-11-29 (snap) Assigned To: helly New Comment: Same problem on debian 3.1 sarge. Compile fails if i use bundled ming or debian libming. Previous Comments: [2005-11-29 19:29:56] hostmaster at xenterra dot net The snapshot php5-200511291530 failed to compile with ext/ming with essentially the same error messages as were originally reported (see Actual Result below). It appears that the ming extension code has not yet been re-worked. [2005-11-29 10:10:12] [EMAIL PROTECTED] Could you plz try newer snapshot? >From what I can see, the problem still exists in the snapshot you've tried and has been fixed in newer ones. [2005-11-29 00:29:57] hostmaster at xenterra dot net Per your suggestion: http://snaps.php.net/php5-latest.tar.gz is, in fact, php5-200511282130.tar.gz, which is the CVS version I said I tried. It did not compile ext/ming with "latest" either. [2005-11-29 00:03:21] [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 Most likely fixed in CVS. [2005-11-28 23:56:40] hostmaster at xenterra dot net Description: No script; this is a compile error. Configure options: ./configure --with-apxs=/usr/local/apache/bin/apxs \ --with-pgsql=/usr/local/pgsql \ --enable-dba \ --with-flatfile \ --with-openssl \ --enable-exif \ --with-gd=/usr/local/gd-2.0.33 \ --with-jpeg-dir=/usr/lib \ --with-png-dir=/usr/lib \ --with-zlib-dir=/usr/lib \ --with-xpm-dir=/usr/X11R6/lib \ --with-imap=/usr/local/imap-2002d \ --with-imap-ssl=/usr/local/ssl \ --with-curl \ --with-curlwrappers \ --enable-ftp \ --enable-soap \ --with-libxml-dir=/usr/local/lib \ --with-ming=/usr/local/lib \ --enable-sockets Compilation also failed using CVS snapshot php5-200511282130 on Slackware 10.2, and on Slackware 10.1 using official release. Ming version is ming-0.3beta1. Reproduce code: --- No code. Expected result: N/A Actual result: -- Following is gcc output right before "make" quit: /usr/local/php-5.1.1/ext/ming/ming.c: In function `zif_swfbitmap___construct': /usr/local/php-5.1.1/ext/ming/ming.c:386: warning: assignment from incompatible pointer type /usr/local/php-5.1.1/ext/ming/ming.c: In function `zif_swfmovie_output': /usr/local/php-5.1.1/ext/ming/ming.c:2267: error: too few arguments to function `SWFMovie_output' /usr/local/php-5.1.1/ext/ming/ming.c: In function `zif_swfmovie_saveToFile': /usr/local/php-5.1.1/ext/ming/ming.c:2329: error: too few arguments to function `SWFMovie_output' /usr/local/php-5.1.1/ext/ming/ming.c: In function `zif_swfmovie_save': /usr/local/php-5.1.1/ext/ming/ming.c:2380: error: too few arguments to function `SWFMovie_output' /usr/local/php-5.1.1/ext/ming/ming.c:2399: error: too few arguments to function `SWFMovie_output' /usr/local/php-5.1.1/ext/ming/ming.c: In function `zif_swftextfield_setFont': /usr/local/php-5.1.1/ext/ming/ming.c:3741: warning: passing arg 2 of `SWFTextField_setFont' from incompatible pointer type make: *** [ext/ming/ming.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=35461&edit=1
#34729 [Asn->Csd]: SoapClient<->SoapServer crashes under apache with 5.10RC2
ID: 34729 Updated by: [EMAIL PROTECTED] Reported By: matthew_peters at uk dot ibm dot com -Status: Assigned +Status: Closed -Bug Type: SOAP related +Bug Type: Scripting Engine problem Operating System: WinXP PHP Version: 5CVS-2005-11-10 (snap) Assigned To: dmitry New Comment: The bug is fixed in CVS HEAD and PHP_5_1. The memory corruption was occur because zend_class_entry->static_members of internal classes were shared across threads. Previous Comments: [2005-11-29 14:02:04] matthew_peters at uk dot ibm dot com Dmitry, thank you for reproducing the bug - that makes us feel that better that we are not just doing something stupid here. Oddly, we find that it takes a different number of refreshes to reproduce the bug depending on whether we use InternetExplorer or Firefox. I have some time today and tomorrow so I will see if I can discover anything. [2005-11-28 13:18:58] [EMAIL PROTECTED] I reproduced the bug on win32 with Apache, but I haven't any idea how to debug it. Seems like a win32 specific memory corruption. :( [2005-11-25 11:52:33] [EMAIL PROTECTED] Dmitry, check this out please. [2005-11-24 17:51:32] matthew_peters at uk dot ibm dot com I already did this - it's lower down the bug report on 21st October and since the behaviour is unchanged I imagine that back trace is valid. Is there some other information you wanted that is not there? [2005-11-24 16:16:57] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/34729 -- Edit this bug report at http://bugs.php.net/?id=34729&edit=1
#35502 [NEW]: PHP 5.1.1 CGI does not attempt to read php.ini from current directory
From: andrew dot tulloch at maximalls dot com
Operating system: Linux
PHP version: 5.1.1
PHP Bug Type: CGI related
Bug description: PHP 5.1.1 CGI does not attempt to read php.ini from current
directory
Description:
PHP 5.0.5 CGI SAPI attempts to read php.ini from the current directory,
PHP 5.1.1 CGI SAPI, compiled with same options does not.
Reproduce code:
---
strace php 2>&1 | grep php.ini
Expected result:
Expected and actual running PHP 5.0.5:
strace /opt/php-5.0.5/bin/php 2>&1 | grep php.ini
open("./php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/opt/php-5.0.5/bin//php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/opt/php-5.0.5/lib/php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
Note attempt to read php.ini from current directory.
Actual result:
--
Running PHP 5.1.1:
strace /opt/php-5.1.1/bin/php 2>&1 | grep php.ini
open("/opt/php-5.1.1/bin/php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/opt/php-5.1.1/lib/php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
No attempt to read php.ini from current directory.
--
Edit bug report at http://bugs.php.net/?id=35502&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35502&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35502&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35502&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35502&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35502&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35502&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35502&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35502&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35502&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35502&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35502&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35502&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35502&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35502&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35502&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35502&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35502&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35502&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35502&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35502&r=mysqlcfg
#35501 [NEW]: array storage and access
From: robing9 at yahoo dot com Operating system: Windows XP SP2 PHP version: 5CVS-2005-12-01 (snap) PHP Bug Type: Arrays related Bug description: array storage and access Description: I am working with a uniserver with Apache 2.0.54, ActivePerl 5.8.7.813, PHP 5.0.4, MySQL 4.1.12a, phpMyAdmin-2.6.3-rc1 When I stored some data in a array with key field in integer but in a jumbled manner (insted of 1,2,3,4 as the key values i gave 0,1,4,2,3). Then when i printed it using the print_r function I got the data in the order of the key values 0,1,4,2,3. But shouldn't it have come in the order 0,1,2,3,4? I have written the code below. PS : I couldnt find a relevant PHP version so I selected 5CVS 2005-12-01(snap) Reproduce code: --- Expected result: Array ( [0] => robin [1] => tony [2] => pradeep [3] => prem [4] => Sini ) Actual result: -- Array ( [0] => robin [1] => tony [4] => Sini [2] => pradeep [3] => prem ) -- Edit bug report at http://bugs.php.net/?id=35501&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35501&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35501&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35501&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35501&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35501&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35501&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35501&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35501&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35501&r=support Expected behavior:http://bugs.php.net/fix.php?id=35501&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35501&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35501&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35501&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35501&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35501&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35501&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35501&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35501&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35501&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35501&r=mysqlcfg
#35500 [Opn->Fbk]: auto_prepend_file seems to fail randomly
ID: 35500 Updated by: [EMAIL PROTECTED] Reported By: bugnet at gartenfreunde dot eu dot org -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: Linux 2.6.13-gentoo-r5 SMP AMD64 PHP Version: 5.1.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-12-01 12:30:32] bugnet at gartenfreunde dot eu dot org Description: I'm using PHP Version 5.0.5-pl3-gentoo (no way to upgrade to 5.1.1) and Apache 2.0.54 with mpm_worker. Approx. 10 times a day I get an errormessage like the following, the rest of the time (5+ requests) everything works fine: [Thu Dec 01 11:17:18 2005] [error] [client x.x.x.x] PHP Warning: main() [function.include]: Failed opening 'lib_tools.php' for inclusion (include_path='/var/www/includes') in /var/www/htdocs/index.php on line 22, referer: http://xxx [Thu Dec 01 11:17:18 2005] [error] [client x.x.x.x] PHP Warning: main() [function.include]: Failed opening 'lib_session.php' for inclusion (include_path='/var/www/includes') in /var/www/htdocs/index.php on line 25, referer: http://xxx index.php looks like this: <-snip-> include_once ($lib_dir.'lib_tools.php'); include_once ($lib_dir.'lib_session.php'); <-snip-> $lib_dir is set in prepend.php, httpd.conf reads: php_value auto_prepend_file /var/www/prepend.php When the error occurs $lib_dir is empty, so it looks like the prepend file doesn't get prepended under some conditions. I'm not sure if this is an PHP or an Apache issue, on our old system running PHP4 and Apache 1.x the problem didn't occur. Reproduce code: --- occurs randomly approx 10 times a day, regardsless of systemload etc. Expected result: a file listed in auto_prepend_file should always be prepended -- Edit this bug report at http://bugs.php.net/?id=35500&edit=1
#35500 [NEW]: auto_prepend_file seems to fail randomly
From: bugnet at gartenfreunde dot eu dot org Operating system: Linux 2.6.13-gentoo-r5 SMP AMD64 PHP version: 5.1.1 PHP Bug Type: Unknown/Other Function Bug description: auto_prepend_file seems to fail randomly Description: I'm using PHP Version 5.0.5-pl3-gentoo (no way to upgrade to 5.1.1) and Apache 2.0.54 with mpm_worker. Approx. 10 times a day I get an errormessage like the following, the rest of the time (5+ requests) everything works fine: [Thu Dec 01 11:17:18 2005] [error] [client x.x.x.x] PHP Warning: main() [function.include]: Failed opening 'lib_tools.php' for inclusion (include_path='/var/www/includes') in /var/www/htdocs/index.php on line 22, referer: http://xxx [Thu Dec 01 11:17:18 2005] [error] [client x.x.x.x] PHP Warning: main() [function.include]: Failed opening 'lib_session.php' for inclusion (include_path='/var/www/includes') in /var/www/htdocs/index.php on line 25, referer: http://xxx index.php looks like this: <-snip-> include_once ($lib_dir.'lib_tools.php'); include_once ($lib_dir.'lib_session.php'); <-snip-> $lib_dir is set in prepend.php, httpd.conf reads: php_value auto_prepend_file /var/www/prepend.php When the error occurs $lib_dir is empty, so it looks like the prepend file doesn't get prepended under some conditions. I'm not sure if this is an PHP or an Apache issue, on our old system running PHP4 and Apache 1.x the problem didn't occur. Reproduce code: --- occurs randomly approx 10 times a day, regardsless of systemload etc. Expected result: a file listed in auto_prepend_file should always be prepended -- Edit bug report at http://bugs.php.net/?id=35500&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35500&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35500&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35500&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35500&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35500&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35500&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35500&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35500&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35500&r=support Expected behavior:http://bugs.php.net/fix.php?id=35500&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35500&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35500&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35500&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35500&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35500&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35500&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35500&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35500&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35500&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35500&r=mysqlcfg
#35498 [Opn->Asn]: GD cannot open majority of jpeg images
ID: 35498 Updated by: [EMAIL PROTECTED] Reported By: paniemin at cc dot hut dot fi -Status: Open +Status: Assigned Bug Type: GD related Operating System: Redhat Linux 7.3 PHP Version: 5.1.0 -Assigned To: +Assigned To: pajoye New Comment: Assigned to the maintainer. Previous Comments: [2005-12-01 10:45:31] paniemin at cc dot hut dot fi First I tryed to us blunded but when that failed I tested external library. I will try to find the location of bug in php source later today when I will be back home. Btw, corect version is 5.1.0 (the public release). [2005-12-01 10:24:43] [EMAIL PROTECTED] Try with the bundled GD, it's known to be less buggy and well maintained. [2005-12-01 01:18:25] paniemin at cc dot hut dot fi Description: I tryed to upgrade from 5.0.4 to 5.1. I use blunded GD version with freetype2, jpeg and png libraries. First I tried with old libraries that I used to build 5.0.4. Next I downloaded new version from freetype2. Next I downloaded GD 2.0.33 and tryed with it. I tried to find the problematic part but I failed to locate it outside php :( I found that imagecreatefromjpeg() fails to open jpeg files that older php version opened without problems. The failure to open seems to be random but about 60-70% images are 'corruped' for gd library. here is one of corrupted images: http://antin.net/imageshu/7363_1.jpg I will continue searching the real reason for this bug. I hope someone else can confirm same problem with 5.1 and GD. Reproduce code: --- $file = getFileForPerson($id, $imageNumber); $img = imagecreatefromjpeg($file); Expected result: I excepted imagecreatefromjpeg to load the image so next steps in code can manipulate it. Actual result: -- Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg: JPEG library reports unrecoverable error: in /home/customers/antin/public_html/huippu/ranki_dev.cgi on line 110 Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '../imageshu/7363_1.jpg' is not a valid JPEG file in /home/customers/antin/public_html/huippu/ranki_dev.cgi on line 110 With GD 2.0.33 the first warning is skipped which seems natural for me. -- Edit this bug report at http://bugs.php.net/?id=35498&edit=1
#35428 [Bgs]: crash when using mysqli with MySQL 5.0.16
ID: 35428 User updated by: marcing at smlw dot pl Reported By: marcing at smlw dot pl Status: Bogus Bug Type: MySQLi related Operating System: WinXP SP2 PHP Version: 5CVS-2005-11-28 (snap) Assigned To: georg New Comment: Fresh news - ive updated client version to 5.0.16, and the crash still occurs - only when using mysqli ext. Previous Comments: [2005-12-01 12:16:10] marcing at smlw dot pl But its not the MySQL that crashes, is it? PDO and mysql extensions somehow dont have problem with different client versions, everything works fine, why mysqli can't? [2005-12-01 10:37:51] [EMAIL PROTECTED] MySQL client bugs should be reported in another place and they are obviously not PHP bugs. [2005-12-01 10:27:51] marcing at smlw dot pl Right, its better to pretend there is no problem, just stick a label "bogus" and forget. Why did a have a feeling that u wont care anyway? In the bug - http://bugs.php.net/bug.php?id=35388, georg might have given the reason and possible solution for this problem (my client version is 4.1.7 too). That could explain why u cant reprocude it. But its so hard to think...i know... Its time for u to paste this "Please try using this CVS snapshot:" text, right? [2005-11-30 15:56:33] [EMAIL PROTECTED] Can't replicate on latest cvs. [2005-11-30 15:49:08] marcing at smlw dot pl The size is unchanged, the bug still exists, so where is the difference? 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/35428 -- Edit this bug report at http://bugs.php.net/?id=35428&edit=1
#35428 [Bgs]: crash when using mysqli with MySQL 5.0.16
ID: 35428 User updated by: marcing at smlw dot pl Reported By: marcing at smlw dot pl Status: Bogus Bug Type: MySQLi related Operating System: WinXP SP2 PHP Version: 5CVS-2005-11-28 (snap) Assigned To: georg New Comment: But its not the MySQL that crashes, is it? PDO and mysql extensions somehow dont have problem with different client versions, everything works fine, why mysqli can't? Previous Comments: [2005-12-01 10:37:51] [EMAIL PROTECTED] MySQL client bugs should be reported in another place and they are obviously not PHP bugs. [2005-12-01 10:27:51] marcing at smlw dot pl Right, its better to pretend there is no problem, just stick a label "bogus" and forget. Why did a have a feeling that u wont care anyway? In the bug - http://bugs.php.net/bug.php?id=35388, georg might have given the reason and possible solution for this problem (my client version is 4.1.7 too). That could explain why u cant reprocude it. But its so hard to think...i know... Its time for u to paste this "Please try using this CVS snapshot:" text, right? [2005-11-30 15:56:33] [EMAIL PROTECTED] Can't replicate on latest cvs. [2005-11-30 15:49:08] marcing at smlw dot pl The size is unchanged, the bug still exists, so where is the difference? [2005-11-30 14:49:26] [EMAIL PROTECTED] Why do you think it's unchanged? The url is the same, while file is regenerated every time. 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/35428 -- Edit this bug report at http://bugs.php.net/?id=35428&edit=1
#32954 [Com]: ifx_fetch_row() : SEGV if row has TEXT fields (PHP Apache Module only)
ID: 32954
Comment by: rait at krediidiinfo dot ee
Reported By: andreybl at matrix dot co dot il
Status: Assigned
Bug Type: Informix related
Operating System: Red Hat 3.0 ES
PHP Version: 5CVS, 4CVS, 6CVS (2005-09-04)
Assigned To: nobbie
New Comment:
My temporal workaround: I changed blob mode from memory to file mode.
(ifx_blobinfile_mode(0) -> ifx_blobinfile_mode(0))
Program, that generated a Segmentation fault:
And my workaround:
Previous Comments:
[2005-11-09 15:18:08] rait at krediidiinfo dot ee
I encoutered same problem. ifx_fetch_row produces "Segmentation fault"
whenever I tried to fetch query result including TEXT type field with
non-NULL value. When the TEXT type field value was NULL then
segmentation fault didn't occure.
It gave segmentation fault in Apache and commmand line.
Informix server version: IDS 9.40.UC2
PHP version 5.0.5
Informix SDK version: csdk_informix.2.90.UC2
apache2-prefork-2.0.49-27.8 (SLES9)
[2005-09-23 15:35:46] [EMAIL PROTECTED]
Assigned to the maintainer. Cornelius, if you get this mail, please
reply via email to me if you're actually maintaining this extension
anymore. (to [EMAIL PROTECTED])
[2005-09-04 15:20:43] andreybl at matrix dot co dot il
Checked with the last snapshot, recomended:
PHP 5.1.0-dev (cli) (built: Sep 4 2005 16:11:34) (DEBUG)
Nothing changed from my last post of 17 May 2005.
[2005-09-02 08:55:21] [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
And don't invent your own PHP version strings. The version must start
with a NUMBER in this bug system..
[2005-05-17 14:41:35] andreybl at matrix dot co dot il
Well, well.
I don know even what to do: cry :( or laugh :)
The good news is that the SEGV problem did not appear.
The bad news is that we still DO HAVE a problem with TEXT fields.
So. I have a table, called "registrars" with few rows. There is a field
in this table, called 'allowedips' and it is of type TEXT. It may have
NULL value. Here is a small test program run on PHP CGI (not Apache
module, but it does not matter):
$conn_id = ifx_connect(..);
$res_id = ifx_query('SELECT * FROM registrars', $conn_id);
while ($row = ifx_fetch_row($res_id))
{
if (!empty($row['allowedips']))
echo ifx_get_blob($row['allowedips'])."\n";
}
ifx_free_result($res_id);
ifx_close($conn_id);
Instead of the values for the 'allowedips' field I see in the output
the following:
/tmp/blbGmDdPT
/tmp/blb214Nct
/tmp/blbQM8yM2
/tmp/blbuQGH1T
I ran this test several times. And as You can guess the /tmp directory
was full with blb** emty files.
If in the beginning of the program I put:
ifx_textasvarchar(1);
then:
echo $row['allowedips';
will produce the same output and there will be same emty files.
BTW:
$rc = ifx_get_blob('blabla'); // 'blabla' is not a valid id
produces the Segmentation fault !!! that we all LOVE :)
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/32954
--
Edit this bug report at http://bugs.php.net/?id=32954&edit=1
#35498 [Fbk->Opn]: GD cannot open majority of jpeg images
ID: 35498 User updated by: paniemin at cc dot hut dot fi Reported By: paniemin at cc dot hut dot fi -Status: Feedback +Status: Open Bug Type: GD related Operating System: Redhat Linux 7.3 -PHP Version: 5.1.1 +PHP Version: 5.1.0 New Comment: First I tryed to us blunded but when that failed I tested external library. I will try to find the location of bug in php source later today when I will be back home. Btw, corect version is 5.1.0 (the public release). Previous Comments: [2005-12-01 10:24:43] [EMAIL PROTECTED] Try with the bundled GD, it's known to be less buggy and well maintained. [2005-12-01 01:18:25] paniemin at cc dot hut dot fi Description: I tryed to upgrade from 5.0.4 to 5.1. I use blunded GD version with freetype2, jpeg and png libraries. First I tried with old libraries that I used to build 5.0.4. Next I downloaded new version from freetype2. Next I downloaded GD 2.0.33 and tryed with it. I tried to find the problematic part but I failed to locate it outside php :( I found that imagecreatefromjpeg() fails to open jpeg files that older php version opened without problems. The failure to open seems to be random but about 60-70% images are 'corruped' for gd library. here is one of corrupted images: http://antin.net/imageshu/7363_1.jpg I will continue searching the real reason for this bug. I hope someone else can confirm same problem with 5.1 and GD. Reproduce code: --- $file = getFileForPerson($id, $imageNumber); $img = imagecreatefromjpeg($file); Expected result: I excepted imagecreatefromjpeg to load the image so next steps in code can manipulate it. Actual result: -- Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg: JPEG library reports unrecoverable error: in /home/customers/antin/public_html/huippu/ranki_dev.cgi on line 110 Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '../imageshu/7363_1.jpg' is not a valid JPEG file in /home/customers/antin/public_html/huippu/ranki_dev.cgi on line 110 With GD 2.0.33 the first warning is skipped which seems natural for me. -- Edit this bug report at http://bugs.php.net/?id=35498&edit=1
#35428 [Bgs]: crash when using mysqli with MySQL 5.0.16
ID: 35428 Updated by: [EMAIL PROTECTED] Reported By: marcing at smlw dot pl Status: Bogus Bug Type: MySQLi related Operating System: WinXP SP2 PHP Version: 5CVS-2005-11-28 (snap) Assigned To: georg New Comment: MySQL client bugs should be reported in another place and they are obviously not PHP bugs. Previous Comments: [2005-12-01 10:27:51] marcing at smlw dot pl Right, its better to pretend there is no problem, just stick a label "bogus" and forget. Why did a have a feeling that u wont care anyway? In the bug - http://bugs.php.net/bug.php?id=35388, georg might have given the reason and possible solution for this problem (my client version is 4.1.7 too). That could explain why u cant reprocude it. But its so hard to think...i know... Its time for u to paste this "Please try using this CVS snapshot:" text, right? [2005-11-30 15:56:33] [EMAIL PROTECTED] Can't replicate on latest cvs. [2005-11-30 15:49:08] marcing at smlw dot pl The size is unchanged, the bug still exists, so where is the difference? [2005-11-30 14:49:26] [EMAIL PROTECTED] Why do you think it's unchanged? The url is the same, while file is regenerated every time. [2005-11-30 14:47:43] [EMAIL PROTECTED] No, nothing. Don't bother, it's fixed. And reported by dozen other people too.. 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/35428 -- Edit this bug report at http://bugs.php.net/?id=35428&edit=1
#35428 [Bgs]: crash when using mysqli with MySQL 5.0.16
ID: 35428 User updated by: marcing at smlw dot pl Reported By: marcing at smlw dot pl Status: Bogus Bug Type: MySQLi related Operating System: WinXP SP2 PHP Version: 5CVS-2005-11-28 (snap) Assigned To: georg New Comment: Right, its better to pretend there is no problem, just stick a label "bogus" and forget. Why did a have a feeling that u wont care anyway? In the bug - http://bugs.php.net/bug.php?id=35388, georg might have given the reason and possible solution for this problem (my client version is 4.1.7 too). That could explain why u cant reprocude it. But its so hard to think...i know... Its time for u to paste this "Please try using this CVS snapshot:" text, right? Previous Comments: [2005-11-30 15:56:33] [EMAIL PROTECTED] Can't replicate on latest cvs. [2005-11-30 15:49:08] marcing at smlw dot pl The size is unchanged, the bug still exists, so where is the difference? [2005-11-30 14:49:26] [EMAIL PROTECTED] Why do you think it's unchanged? The url is the same, while file is regenerated every time. [2005-11-30 14:47:43] [EMAIL PROTECTED] No, nothing. Don't bother, it's fixed. And reported by dozen other people too.. [2005-11-30 14:45:16] marcing at smlw dot pl What's the point of checking the same and unchanged file again? 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/35428 -- Edit this bug report at http://bugs.php.net/?id=35428&edit=1
#35498 [Opn->Fbk]: GD cannot open majority of jpeg images
ID: 35498 Updated by: [EMAIL PROTECTED] Reported By: paniemin at cc dot hut dot fi -Status: Open +Status: Feedback Bug Type: GD related Operating System: Redhat Linux 7.3 PHP Version: 5.1.1 New Comment: Try with the bundled GD, it's known to be less buggy and well maintained. Previous Comments: [2005-12-01 01:18:25] paniemin at cc dot hut dot fi Description: I tryed to upgrade from 5.0.4 to 5.1. I use blunded GD version with freetype2, jpeg and png libraries. First I tried with old libraries that I used to build 5.0.4. Next I downloaded new version from freetype2. Next I downloaded GD 2.0.33 and tryed with it. I tried to find the problematic part but I failed to locate it outside php :( I found that imagecreatefromjpeg() fails to open jpeg files that older php version opened without problems. The failure to open seems to be random but about 60-70% images are 'corruped' for gd library. here is one of corrupted images: http://antin.net/imageshu/7363_1.jpg I will continue searching the real reason for this bug. I hope someone else can confirm same problem with 5.1 and GD. Reproduce code: --- $file = getFileForPerson($id, $imageNumber); $img = imagecreatefromjpeg($file); Expected result: I excepted imagecreatefromjpeg to load the image so next steps in code can manipulate it. Actual result: -- Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg: JPEG library reports unrecoverable error: in /home/customers/antin/public_html/huippu/ranki_dev.cgi on line 110 Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '../imageshu/7363_1.jpg' is not a valid JPEG file in /home/customers/antin/public_html/huippu/ranki_dev.cgi on line 110 With GD 2.0.33 the first warning is skipped which seems natural for me. -- Edit this bug report at http://bugs.php.net/?id=35498&edit=1
#35066 [Asn->Csd]: Crash using COM with ISAPI
ID: 35066
Updated by: [EMAIL PROTECTED]
Reported By: bke15 at gmx dot de
-Status: Assigned
+Status: Closed
Bug Type: COM related
Operating System: Windows 2003 Server
PHP Version: 5CVS-2005-11-28 (snap)
Assigned To: wez
New Comment:
Fixed -> closed.
Previous Comments:
[2005-12-01 02:38:50] IMarvinTPA at bigfoot dot com
My issue appears to be resolved.
Thank you!
IMarv
[2005-11-29 09:47:01] bke15 at gmx dot de
The error is now (PHP5.1.1) very seldom but still existent. Using a
loadtester on my Webserver i get application Errors each 5 Minutes.
Using the same script with 5.0.5 works fine.
[2005-11-28 15:14:56] [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-11-26 23:01:31] IMarvinTPA at bigfoot dot com
I'm getting this crash every time on WinXP SP1, PHP 5.1 release, IIS
5.1 (PWS)
The line of code that does it in:
$oCapicom = new COM("CAPICOM.EncryptedData");
IMarv
[2005-11-02 16:14:35] bke15 at gmx dot de
I am running on ISAPI on all cases.
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/35066
--
Edit this bug report at http://bugs.php.net/?id=35066&edit=1
