#45384 [NEW]: parse_ini_file will result in parse error with no trailing newline
From: [EMAIL PROTECTED]
Operating system: Ubuntu
PHP version: 5.3CVS-2008-06-28 (CVS)
PHP Bug Type: Filesystem function related
Bug description: parse_ini_file will result in parse error with no trailing
newline
Description:
an ini file with no trailing newline will result in "Parse error", php5.3
only, 5.2 parses the file fine
Reproduce code:
---
$ echo -n "foo.bar = baz" > test.ini
$ /opt/php53/bin/php -r 'var_dump(parse_ini_file("test.ini"));'
Expected result:
array(1) {
["foo.bar"]=>
string(3) "baz"
}
Actual result:
--
Warning: syntax error, unexpected $end in test.ini on line 1
in Command line code on line 1
Call Stack:
0.0003 312916 1. {main}() Command line code:0
0.0128 312936 2. parse_ini_file() Command line code:1
array(0) {
}
--
Edit bug report at http://bugs.php.net/?id=45384&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45384&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45384&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45384&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45384&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45384&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45384&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45384&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45384&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45384&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45384&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45384&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45384&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45384&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45384&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45384&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45384&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45384&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45384&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45384&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45384&r=mysqlcfg
#45336 [Opn->Fbk]: Compile breaks on Generating phar.phar
ID: 45336 Updated by: [EMAIL PROTECTED] Reported By: pahan at hubbitus dot spb dot su -Status: Open +Status: Feedback Bug Type: *Compile Issues Operating System: Linux PHP Version: 5.3CVS-2008-06-23 (snap) New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi Previous Comments: [2008-06-23 15:02:10] pahan at hubbitus dot spb dot su Description: Compilation breaks on Generating phar.phar after generate of phar.php. Last few strings of output are: /bin/sh /usr/src/redhat/BUILD/php5.3-200806231230/build-cgi/libtool --silent --preserve-dup-deps --mode=install c p ext/zip/zip.la /usr/src/redhat/BUILD/php5.3-200806231230/build-cgi/modules Generating phar.php Generating phar.phar Unknown parameter '-f' to command pack, check ext/phar/phar.php help make: *** [ext/phar/phar.phar] Error 1 Reproduce code: --- configure make :) I anticipate that it is not depend of configure options, if --disable-phar not present. Expected result: Compile successfully. Actual result: -- Last error comes from command: /usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/sapi/cli/php -n -d extension_dir=/usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/modules -d open_basedir= -d output_buffering=0 -d memory_limit=-1 -d phar.readonly=0 ext/phar/phar.php pack -f ext/phar/phar.phar -a pharcommand -c auto -x CVS -p 0 -s /usr/src/redhat/BUILD/php5.3-200806230630/ext/phar/phar/phar.php -h sha1 -b /usr/bin/php /usr/src/redhat/BUILD/php5.3-200806230630/ext/phar/phar/ So, check help: bash-3.2$ /usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/sapi/cli/php -n -d extension_dir=/usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/modules -d open_basedir= -d output_buffering=0 -d memory_limit=-1 -d phar.readonly=0 ext/phar/phar.php help pack pack Pack files into a PHAR archive. When using -s , then the stub file is being excluded from the list of input files/dirs.To create an archive that contains PEAR class PHP_Archiave then point -p argument to PHP/Archive.php. Required arguments: -F Specifies the phar file to work on. ... Any number of input files and directories. If -i is in use then ONLY files and matching thegiven regular expression are being packed. If -x is given then files matching that regular expression are NOT being packed. Ok, try -F instead of -f, get another error: bash-3.2$ /usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/sapi/cli/php -n -d extension_dir=/usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/modules -d open_basedir= -d output_buffering=0 -d memory_limit=-1 -d phar.readonly=0 ext/phar/phar.php pack -F ext/phar/phar.phar -a pharcommand -c auto -x CVS -p 0 -s /usr/src/redhat/BUILD/php5.3-200806230630/ext/phar/phar/phar.php -h sha1 -b /usr/bin/php /usr/src/redhat/BUILD/php5.3-200806230630/ext/phar/phar/ Unknown parameter '-a' to command pack, check ext/phar/phar.php help Removing -a, and other parameters, which are unknown do not give result. It seems as make-command from Phar 2.0 on old Phar extension 1.49.2.8. Furthermore, it seems as old phar.php in new phar 2.0: bash-3.2$ /usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/sapi/cli/php -n -d extension_dir=/usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/modules -d open_basedir= -d output_buffering=0 -d memory_limit=-1 -d phar.readonly=0 ext/phar/phar.php version PHP Version: 5.3.0-dev phar.phar version: $Revision: 1.49.2.8 $ Phar EXT version: 2.0.0b2-dev Phar API version: 1.1.1 Phar-based phar archives: enabled Tar-based phar archives: enabled ZIP-based phar archives: enabled gzip compression: enabled bzip2 compression: enabled supported signatures: MD5, SHA-1, SHA-256, SHA-512, OpenSSL -- Edit this bug report at http://bugs.php.net/?id=45336&edit=1
#45383 [NEW]: Database create function ignores umask
From: beckera at softrends dot com Operating system: Linux (CentOS 5.1) PHP version: 5.2.6 PHP Bug Type: dBase related Bug description: Database create function ignores umask Description: Running CentOS 5.1 w/ Apache 2.2.3. Set Apache's umask to 002, ran a dbase create function to create a new dbase file. When finished, the file permissions were 644 instead of 664. Initially found this under version 5.1.6, tracked it down in source code, then checked 5.2.6 and the problem is still there. In the source file php-5.2.6/ext/dbase/dbase.c, find the function "dbase_create". About 30 lines into the function there is a function call VCWD_OPEN_MODE(Z_STRVAL_PP(filename), O_BINARY|O_RDWR|O_CREAT, 0644) which is responsible for creating the new file. The error is in the hard-coded third parameter 0644. This will fail to create the file with expected permissions unless umask is set to 022 (which is normally the default). This code needs to obtain the umask in effect at the time of the function call, compute the correct mode value, and use that in place of the current hard value 0644. CentOS 5 PHP is not compiled with dbase enabled by default. I obtained and installed the source RPM, modified the spec file to add " --enable-dbase" to the options used both for building the command-line and Apache module forms of PHP. -- Edit bug report at http://bugs.php.net/?id=45383&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45383&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45383&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45383&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45383&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45383&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45383&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45383&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45383&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45383&r=support Expected behavior:http://bugs.php.net/fix.php?id=45383&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45383&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45383&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45383&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45383&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45383&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45383&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45383&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45383&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45383&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45383&r=mysqlcfg
#45147 [Ver->Bgs]: unexpected T_ENDFOR
ID: 45147 Updated by: [EMAIL PROTECTED] Reported By: php at deegital dot de -Status: Verified +Status: Bogus Bug Type: Scripting Engine problem Operating System: Vista 32Bit PHP Version: 5.3CVS-2008-06-02 (snap) 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. bug #45372 is newer but about the same issues with more discussion. Closing this in favour of the other one. Previous Comments: [2008-06-02 09:16:27] php at deegital dot de Description: Tokenizer seems to have problems with some php/html mix constructions (found this in a "compiled" smarty template) Works, if if, else and endif is splitted into multiple lines Reproduce code: --- ## Expected result: # Actual result: -- Parse error: syntax error, unexpected T_ENDFOR in [foo] on line 3 -- Edit this bug report at http://bugs.php.net/?id=45147&edit=1
#45382 [NEW]: timeout bug in stream_socket_enable_crypto
From: vnegrier at optilian dot com
Operating system: linux 2.6
PHP version: 5.2.6
PHP Bug Type: OpenSSL related
Bug description: timeout bug in stream_socket_enable_crypto
Description:
there's a bug in the stream_socket_enable_crypto() timeout test: the
"timeout" var is only decremented when tve.sec and tvs.sec differ because
(at least with gcc-4.3.1) "tv_usec / 100" is cast as int, leading to
timeout inaccuracy, fix below :
--- xp_ssl.c.orig 2008-06-27 21:02:58.0 +0200
+++ xp_ssl.c2008-06-27 21:03:07.0 +0200
@@ -418,7 +418,7 @@
n = SSL_connect(sslsock->ssl_handle);
gettimeofday(&tve, &tz);
- timeout -= (tve.tv_sec + tve.tv_usec /
100) - (tvs.tv_sec + tvs.tv_usec / 100);
+ timeout -= (tve.tv_sec +
(float)tve.tv_usec / 100) - (tvs.tv_sec + (float)tvs.tv_usec /
100);
if (timeout < 0) {
php_error_docref(NULL TSRMLS_CC,
E_WARNING, "SSL: connection timeout");
return -1;
--
Edit bug report at http://bugs.php.net/?id=45382&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45382&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45382&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45382&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45382&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45382&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45382&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45382&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45382&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45382&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45382&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45382&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45382&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45382&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45382&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45382&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45382&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45382&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45382&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45382&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45382&r=mysqlcfg
#32564 [Com]: unset session in foreach
ID: 32564
Comment by: espaiz at gmail dot com
Reported By: echenavaz at mengine dot fr
Status: No Feedback
Bug Type: Session related
Operating System: debian 2.6.9
PHP Version: 5.0.4
New Comment:
Year 2008, this bug is still here. Simple recrusion function:
$parent){
if( $parent===$pid ){
$return[$id]= $level;
unset($array[$id]); /* remove this to get correct
results */
recrusion(&$array, &$return, $id, $level+1);
}
}
}
$return= array();
$array= array(1=>0,2=>1,3=>2,4=>3,5=>2,6=>2,7=>6,8=>6,9=>0,10=>0);
recrusion($array, &$return);
var_dump( $return );
?>
Result:
array(6) { [1]=> int(0) [2]=> int(1) [3]=> int(2) [4]=> int(3) [9]=>
int(0) [10]=> int(0) }
Should be:
array(10) { [1]=> int(0) [2]=> int(1) [3]=> int(2) [4]=> int(3) [5]=>
int(2) [6]=> int(2) [7]=> int(3) [8]=> int(3) [9]=> int(0) [10]=> int(0)
}
Tested with PHP 5.2.6 on Debian-40r3-amd64 and Windows Vista 32
It DOES work with bigger/deeper array though!
Previous Comments:
[2005-11-29 14:16:18] imoicianu at interaktonline dot com
is this bug fixed in the latest PHP versions? I see the bug report is
still not closed..
Regards,
Ionut
[2005-06-13 18:41:22] cristic at interaktonline dot com
This problem is duplicating on WinXP Pro (SP2) Apache 1.3.33 PHP 5.0.4
register_globals = Off
register_long_arrays= Off
If you have 3 php pages with the following code:
1.php:
click here for page 2
2.php:
$v){
unset($_SESSION[$k]);
}
var_dump($_SESSION);
?>
click here for page 3
3.php:
Finish!
The results in the browser will be:
1.php:
array(3) { ["var1"]=> string(4) "val1" ["var2"]=> string(4) "val2"
["var3"]=> string(4) "val3" }
click here for page 2
2.php:
array(0) { }
click here for page 3
3.php:
array(3) { ["var1"]=> string(4) "val1" ["var2"]=> string(4) "val2"
["var3"]=> string(4) "val3" } Finish!
Now, if you turn On the register_long_arrays this will work as expected
having on page 3 an empty session.
Also if you execute outside a foreach loop the unset is working as
well.
Contact me if you need more details.
[2005-04-27 17:53:09] bugs dot php dot net at enca dot cz
In this testcase the "write" function is not called. If you comment
line with "unset", the write function is called properly. If you delete
whole foreach cycle and use
"unset($_SESSION['A']);" instead, the "write" function si also called -
as expected. This bug appear only when you call "unset" inside foreach
cycle.
My environment:
MS Windows Server 2003 SE (Windows NT 5.2 build 3790)
Apache/2.0.53 (Win32) PHP/5.0.4
I can provide more information if you ask for them.
$lsVal){
if($lsKey != 'A'){
unset($_SESSION[$lsKey]); // if you comment this line, the
write function is called properly
}
}
print_r($_SESSION);
print("finished\n");
?>
[2005-04-12 01:00:05] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-04-05 17:07:33] derek dot ethier at humber dot ca
More information:
This "problem" does not exist with 5.0.2 on Windows 2003 (IIS6).
duh at dowebwedo dot com's method does work within the execution of
that one script, but the unset variables are not persistent. The
$_SESSION variables are restored on each subsequent page load even after
they have been unset which leads to problems with session fixation and
the inability to clean-up session values that are no longer needed.
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/32564
--
Edit this bug report at http://bugs.php.net/?id=32564&edit=1
#45381 [NEW]: All error_log calls firing twice under certain conditions...
From: evan dot kaufman at gmail dot com Operating system: All PHP version: 5.2.6 PHP Bug Type: Unknown/Other Function Bug description: All error_log calls firing twice under certain conditions... Description: Calls to error_log() are made, and certain output is echoed to the client. When script execution halts, all the previous calls to error_log() are apparently executed again, all at once and in the same order. This effectively results in doubling all logged messages. I have reproduced this in Mac OS X 10.5.3 running a MAMP distribution with PHP 5.2.5, in Ubuntu 8.04 running Zend Core with PHP 5.2.5, and in SunOS 5.8 running Apache2 with PHP 5.2.3. Curiously, this only occurs with a content type of text/html, and apparently has something to do with the javascript. Reproduce code: --- document.body.style.backgroundImage = 'url()'; HTMLCODE; Expected result: Should print out some html with embedded javascript, and write a single entry to the apache error_log file: [Fri Jun 27 13:28:36 2008] [error] some log message that, via a bug, will be logged twice Actual result: -- Prints out the html/javascript as expected, but writes TWO entries to the apache error_log file: [Fri Jun 27 13:28:36 2008] [error] some log message that, via a bug, will be logged twice [Fri Jun 27 13:28:36 2008] [error] some log message that, via a bug, will be logged twice -- Edit bug report at http://bugs.php.net/?id=45381&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45381&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45381&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45381&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45381&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45381&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45381&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45381&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45381&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45381&r=support Expected behavior:http://bugs.php.net/fix.php?id=45381&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45381&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45381&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45381&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45381&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45381&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45381&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45381&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45381&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45381&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45381&r=mysqlcfg
#43896 [Com]: htmlspecialchars returns empty string on invalid unicode sequence
ID: 43896 Comment by: sillyxone at yaoo dot com Reported By: arnaud dot lb at gmail dot com Status: Open Bug Type: Strings related Operating System: * PHP Version: 5.2CVS, 5.3CVS (2008-03-25) New Comment: is also affected in 5.2, for example: $str = 'Hello' . chr(160) . 'there'; print(htmlentities($str, ENT_COMPAT, 'UTF-8')); Instead of printing "Hello there", it prints nothing (empty string). The same for htmlspecialchars(). Both functions work fine in 5.1 Previous Comments: [2008-05-05 21:00:37] heurika at gmail dot com Hi, I've got the same Bug, posted on #43740. Please fix it. Thanks! [2008-02-17 13:25:22] andreas dot ravnestad at gmail dot com This seems to be breaking PEAR::Text_Wiki completely when using UTF-8: http://pear.php.net/bugs/bug.php?id=13136 [2008-01-24 20:51:11] tallyce at gmail dot com See also bugs 43294 and 43549 which seem to be the same thing. This is really starting to bite now. Please can this be fixed, or suggest how we can reliably process incoming user data in UTF8 given this behaviour change! [2008-01-24 12:29:58] arnaud dot lb at gmail dot com I made a patch for this bug: http://s3.amazonaws.com/arnaud.lb/php_htmlentities_utf.patch The internal get_next_char() function returns a status of FAILURE when it encounters a invalid or incomplete sequence, which causes the htmlspecialchars and htmlentities functions to return an empty string. This patch modify the behavior of these functions to skip invalid sequences, without discarding the whole string. This involves a very few changes and makes the behavior of theses functions more consistent with previous PHP versions. It also adds a few tests to htmlentities-utf.phpt. [2008-01-20 02:12:01] arnaud dot lb at gmail dot com Description: htmlspecialchars/htmlentities returns an empty string when the input contains an invalid unicode sequence. I think these functions should just skip the invalid sequences or encode them byte by byte (e.g. 0xE9 => é), instead of discarding the whole string. Sometimes you have to display arbitrary strings of unknow encoding. So you make them more safe using htmlspecialchars($string, ENT_COMPAT, "site_encoding, utf-8 in my case"), but if there is at least one invalid sequence in the string, it returns an empty string :/ Reproduce code: --- $string = "Voil\xE0"; // "Voilà", in ISO-8859-15 var_dump(htmlspecialchars($string, ENT_COMPAT, "utf-8")); Expected result: string(4) "Voil" OR string(10) "Voilà" Actual result: -- string(0) "" -- Edit this bug report at http://bugs.php.net/?id=43896&edit=1
#45380 [NEW]: Access multiple sessions in a request
From: jerome dot auge at anakeen dot com
Operating system: Linux
PHP version: 5.2.6
PHP Bug Type: Session related
Bug description: Access multiple sessions in a request
Description:
I want to access two distinct sessions content, but I only get access to
the first session, and the second session_name/session_start does not
change the content of the $_SESSION variable which remains the same as
the first one.
After investigation, when switching session with a call to
session_name('another_session')+session_start(), the session ID from the
first session_start() is re-used, and the sess ID from the new session
name 'another_session' is not used.
Reproduce code:
---
1) Call 'set_sess1.php' to set a session named 'sess1':
2) Call 'set_sess2.php' to set a session named 'sess2':
3) Try to access both session variables in 'get_sess.php':
$v) {
print "_COOKIE[$k] = $v\n";
}
print "sess1 = $sess1\n";
print "sess2 = $sess2\n";
?>
Expected result:
In 'get_sess.php', I expect to get access to the content of the 'sess2'
session by issuing a new session_name('sess2')+session_start(), but the
content of _SESSION remains the one from 'sess1'.
Expected output from 'get_sess.php':
_COOKIE[sess1] = n0f57lap2oabeqvfc6t6c0ap60
_COOKIE[sess2] = b4s2sr976f4qrbkimfh0i6kqm0
sess1 = session1:n0f57lap2oabeqvfc6t6c0ap60
sess2 = session2:b4s2sr976f4qrbkimfh0i6kqm0
Actual result:
--
Actuel output from 'get_sess.php':
_COOKIE[sess1] = 2ot2t22ccq0t9de2edhgcrh4h4
_COOKIE[sess2] = rt8jr3e6esvmp88id0e4o05091
sess1 = session1:2ot2t22ccq0t9de2edhgcrh4h4
sess2 =
The script also issue a "Set-Cookie: sess2=", and I
end up with the cookies 'sess1' and 'sess2' having the same ID.
I got around it by setting the session ID manually with
session_id($_COOKIE['new_session']), after calling
session_name('new_session') and before session_start()... but I was
expecting PHP to handle this automatically...
So here is a proposal patch to de-allocate PS(id) when calling
session_write_close(), in order to force session_start() to lookup the
session ID from the session name:
--8<--
--- php-5.2.6.orig/ext/session/session.c2008-04-29
16:42:38.0 +0200
+++ php-5.2.6/ext/session/session.c 2008-06-27 18:29:05.0
+0200
@@ -933,6 +933,11 @@
if (PS(mod_data))
PS(mod)->s_close(&PS(mod_data) TSRMLS_CC);
+
+ if (PS(id)) {
+ efree(PS(id));
+ PS(id) = NULL;
+ }
}
static char *month_names[] = {
-->8--
--
Edit bug report at http://bugs.php.net/?id=45380&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45380&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45380&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45380&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45380&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45380&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45380&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45380&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45380&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45380&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45380&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45380&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45380&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45380&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45380&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45380&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45380&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45380&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45380&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45380&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45380&r=mysqlcfg
#45378 [NEW]: Returning weird overwritten data in array
From: pwd_manager at hotmail dot com Operating system: Linux, Ubuntu and Redhat PHP version: 5.2.6 PHP Bug Type: Arrays related Bug description: Returning weird overwritten data in array Description: Php throwing weird data into an array. Reproduce code: --- The code is too large to post here. Since I currently do not have a hosting server and I am working on a clients website, I have no way of hosting the code. You can email me ([EMAIL PROTECTED]) and I can email you the test code. Expected result: The following code is supposed to loop through the massive array set the object type for each field. If you look at the original array, you will notice that all the types are clearly defined. There is no weird type called "Ant". However, if you look at the bottom of the test code, somewhere, the code returns a weird type of "Ant". There is no where that this information should be cropping up in the code. After hours of exhaustive debugging, I have learned that the error is reproduce-able on multiple OS's, that it seems to occur in the same place in this massive array of arrays, and that I am pretty sure it isn't a bug in my code. Actual result: -- See expected results. -- Edit bug report at http://bugs.php.net/?id=45378&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45378&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45378&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45378&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45378&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45378&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45378&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45378&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45378&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45378&r=support Expected behavior:http://bugs.php.net/fix.php?id=45378&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45378&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45378&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45378&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45378&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45378&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45378&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45378&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45378&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45378&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45378&r=mysqlcfg
#44905 [Com]: PHP 5.2.6 fails to load PostgreSQL related libraries
ID: 44905
Comment by: kenorb at gmail dot com
Reported By: ionut dot stan at yahoo dot com
Status: Assigned
Bug Type: Dynamic loading
Operating System: Windows XP professional 64bit
PHP Version: 5.2.6
Assigned To: pajoye
New Comment:
Hi,
After installed WAMP 2.0 on Vista and I have the same problem;(
It will be fixed in next version?
Previous Comments:
[2008-06-17 07:26:54] travisvz at gmail dot com
I have also experienced this problem (Apache 2.2 with PHP 5.2.6 on
Windows XP Pro 32-bit). I have found another workaround that may be
simpler if your PostgreSQL 8.3 is on the same system as your PHP
installation: Simply add your PostgreSQL bin directory ("C:\Program
Files\PostgreSQL\8.3\bin" on my system) to your system path. Same effect
as copying the necessary libraries to your PHP directory, but perhaps
easier to maintain (especially once a fix is found for this problem).
[2008-06-03 20:31:34] eric at myprojects dot srhost dot info
I have tested on 32bit windows that pgsql extension
could loaded but required download some files from pgsql server 8.3.1
binary.
This can be download from offical site or
I have packed a small archive that could downloaded.
url:
pgserver offical site download
http://wwwmaster.postgresql.org/download/mirrors-ftp?file=%2Fbinary%2Fv8.3.1%2Fwin32%2Fpostgresql-8.3.1-1-binaries-no-installer.zip
small archive.
http://myprojects.srhost.info/download/php_pgsql_files.zip
[2008-05-31 08:21:43] [EMAIL PROTECTED]
"How difficult can it be to test the most basic things, like starting
php, before making a release? Good grief. If you can't do the simple
things why do you think people should trust you with the complex
things?"
How difficult it is to test the RC? How difficult it is to report
issues before the stable release instead of waiting the final day?
That being said, we do run php and the tests suite before any release.
But as some dlls are in the path, I did not detect that the new version
(we upgraded libpq in 5.2.6, different version than with 5.2.5) was not
static by default. Given the time we had to pack this release, I'm
actually very happy that only this error remains (and have an easy work
around).
[2008-05-31 07:50:52] no at where dot zz
How difficult can it be to test the most basic things, like starting
php, before making a release? Good grief. If you can't do the simple
things why do you think people should trust you with the complex things?
[2008-05-30 12:14:58] [EMAIL PROTECTED]
The safer work around is to use the php 5.2.5 DLL extension.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/44905
--
Edit this bug report at http://bugs.php.net/?id=44905&edit=1
#45372 [Asn]: hash# check in new re2c parser breaks code
ID: 45372
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.3CVS-2008-06-27 (CVS)
Assigned To: helly
New Comment:
Not sure why re2c needs to deal with the #bang situation
looking at the code it would be better to eat that line outside of the
lexer..
Something like:
int ini_lex(zval *ini_lval TSRMLS_DC)
{
if ((YYCTYPE*)yytext == SCNG(yy_start) && *yych == '#') {
while(*yych != '\n' && *yych != '\n' && yych < yyend) {
yych++;
}
while((*yych == '\n' || *yych == '\n') && yych < yyend) {
yych++;
}
YYCURSOR = yych;
}
.
Previous Comments:
[2008-06-27 11:26:18] [EMAIL PROTECTED]
Duplicated... Bug #45147
[2008-06-27 09:31:21] [EMAIL PROTECTED]
This should work like in older releases, Marcus please check it!
[2008-06-27 09:05:48] [EMAIL PROTECTED]
(yyless(1) could just be used before the goto...)
Anyway, did you actually try that? AFAIK it still won't work, at least
with your single line example (which there's already been at least one
report about). While the local code fix is correct, the re2c code/logic
seems flawed to me. (Maybe this bug report can be about that instead, in
general, since I didn't get around to sending a follow-up message to the
internals@ list yet, explaining things. :-))
In this example, it will still be broken because of the YYFILL() check
-- each time it checks if the next character can match, even when it's
at the end of the input. YYFILL() then makes it return, completely
ignoring anything that has matched up to that point!
I'm not sure if this explanation is 100% correct, but I believe this
wrong behavior happens when EOF is encountered while trying to match the
variable length part of ANY rule; or something close to that. :-) It's
been over a month since I tried to track and figure out what was
happening. Granted, most of the cases (unlike yours), where the match is
aborted because of YYFILL(), it's with invalid code, but it shouldn't
happen. BTW, I think the part with the inline_char_handler label where
it looks for opening PHP tags in the HTML, while a good optimization
(using memchr() to find < etc.), was actually added as a workaround for
this re2c/YYFILL() behavior. I didn't try it, but from what I've
observed, I think whatever plain HTML was at the end of a file would
have been lost if a regular rule (like in Flex) was used to match it...
Oh, there are also some more bugs in the code that looks for opening
PHP tag, but they wouldn't be found as easily as this (and haven't been
reported so far). I think I know how it can be fixed nicely, along with
some more other scanner optimizations (for inline HTML and comments,
basically). But I haven't done anything yet since some of it won't even
work with these re2c/YYFILL() issues. :-/
Finally, to simplify what I think is the basic, underlying flaw with
the code of re2c and YYFILL() now, here's a super easy example. Say you
have one rule:
[a-z]+
It will NEVER match any input that a person would think, such as the
string "foo" -- seems pretty messed up to me!?
[2008-06-27 06:03:16] [EMAIL PROTECTED]
marking as critical
[2008-06-27 06:00:54] [EMAIL PROTECTED]
Description:
single line file:
#
produces a parse error:
get's caught with this rule from the re2c scanner.
"#".+ {NEWLINE} {
if ((YYCTYPE*)yytext == SCNG(yy_start)) {
/* ignore first line when it's started with a # */
goto restart;
} else {
goto inline_char_handler;
}
}
basically the scanner runs off the end, and eats everything after the
#
I've fixed it by changing the above to something like:
} else {
/* shunt back to just return the # on it's own.. */
YYCURSOR = YYMARKER;
yyleng = 1;
goto inline_char_handler;
}
--
Edit this bug report at http://bugs.php.net/?id=45372&edit=1
#45377 [NEW]: pg_escape_bytea + pg_query_params -> malformed data
From: kk219459 at students dot mimuw dot edu dot pl
Operating system: OpenBSD
PHP version: 5.2.6
PHP Bug Type: PostgreSQL related
Bug description: pg_escape_bytea + pg_query_params -> malformed data
Description:
OpenBSD 4.1
Apache/1.3.29
php5-core-5.1.6p1
postgresql-client-8.2.4
I want to insert some binary data to a table.
$q = "UPDATE tbl SET data = decode($1, 'base64') WHERE id = $2";
$params = array(base64_encode('binary string'), 123);
$res = pg_query_params($q, $params);
OK
$q = "UPDATE tbl SET data = $1::bytea WHERE id = $2";
$params = array('binary string', 123);
$res = pg_query_params($q, $params);
ERROR: invalid byte sequence for encoding "UTF8": 0x89 HINT: This error
can also happen if the byte sequence does not match the encoding expected
by the server, which is controlled by "client_encoding".
This could possibly work, but does not. Ok, not a problem.
(end of introduction)
Reproduce code:
---
# first
$q = "UPDATE tbl SET data = decode($1, 'escape') WHERE id = $2";
$params = array(pg_escape_bytea('binary string'), 123);
$res = pg_query_params($q, $params);
# second
$q = "UPDATE tbl SET data = $1::bytea WHERE id = $2";
$params = array(pg_escape_bytea('binary string'), 123);
$res = pg_query_params($q, $params);
Expected result:
Be sure to replace 'binary string' with something more challenging!
At least one of these should work (insert the data correctly)
Actual result:
--
Both approaches give the same result.
The data gets loaded, but incorrectly.
select length(data) from tbl; -- too large
data contains character sequences like '\000' instead of their values.
btw.
select content = decode(encode(data, 'escape'), 'escape') from tbl; --
works (sequence of TRUEs)
--
Edit bug report at http://bugs.php.net/?id=45377&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45377&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45377&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45377&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45377&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45377&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45377&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45377&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45377&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45377&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45377&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45377&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45377&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45377&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45377&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45377&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45377&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45377&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45377&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45377&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45377&r=mysqlcfg
#42547 [Com]: ext/iconv/iconv.c:2426: undefined reference to `libiconv_open'
ID: 42547 Comment by: ranrig at gmail dot com Reported By: dawidpachla at gmail dot com Status: No Feedback Bug Type: Compile Failure Operating System: CentOS 5 with DirectAdmin PHP Version: 5.2.4 New Comment: Whenever you see "undefined reference to `libiconv_open'", try make CFLAGS=-liconv Previous Comments: [2007-10-19 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-10-11 14:06:27] [EMAIL PROTECTED] Is there some reason you have libiconv installed in /usr/local when your glibc provides the same stuff? Did something else require it? As the fix is to simply uninstall libiconv.. [2007-10-08 10:36:29] dawidpachla at gmail dot com Here's the output of # grep ICONV main/php_config.h after 'compilation': [EMAIL PROTECTED] php-5.2.4]# grep ICONV main/php_config.h /* #undef HAVE_LIBICONV */ /* #undef HAVE_GICONV_H */ /* #undef HAVE_LIBICONV */ #define HAVE_ICONV 1 #define PHP_ICONV_IMPL "glibc" /* #undef HAVE_BSD_ICONV */ #define PHP_ICONV_IMPL "glibc" #define HAVE_GLIBC_ICONV 1 #define PHP_ICONV_IMPL "glibc" #define ICONV_SUPPORTS_ERRNO 0 #define ICONV_SUPPORTS_ERRNO 0 #define ICONV_SUPPORTS_ERRNO 0 #define PHP_ICONV_H_PATH /* #undef COMPILE_DL_ICONV */ /* #undef HAVE_LIBICONV */ /* #undef HAVE_GICONV_H */ /* #undef HAVE_LIBICONV */ #define HAVE_ICONV 1 [EMAIL PROTECTED] php-5.2.4]# [2007-09-21 09:15:14] [EMAIL PROTECTED] Try find that file first. It's $top_builddir/main/php_config.h [2007-09-19 14:42:46] dawidpachla at gmail dot com grep: main/php_config.h: No such file or directory 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/42547 -- Edit this bug report at http://bugs.php.net/?id=42547&edit=1
#45372 [Asn]: hash# check in new re2c parser breaks code
ID: 45372
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.3CVS-2008-06-27 (CVS)
Assigned To: helly
New Comment:
Duplicated... Bug #45147
Previous Comments:
[2008-06-27 09:31:21] [EMAIL PROTECTED]
This should work like in older releases, Marcus please check it!
[2008-06-27 09:05:48] [EMAIL PROTECTED]
(yyless(1) could just be used before the goto...)
Anyway, did you actually try that? AFAIK it still won't work, at least
with your single line example (which there's already been at least one
report about). While the local code fix is correct, the re2c code/logic
seems flawed to me. (Maybe this bug report can be about that instead, in
general, since I didn't get around to sending a follow-up message to the
internals@ list yet, explaining things. :-))
In this example, it will still be broken because of the YYFILL() check
-- each time it checks if the next character can match, even when it's
at the end of the input. YYFILL() then makes it return, completely
ignoring anything that has matched up to that point!
I'm not sure if this explanation is 100% correct, but I believe this
wrong behavior happens when EOF is encountered while trying to match the
variable length part of ANY rule; or something close to that. :-) It's
been over a month since I tried to track and figure out what was
happening. Granted, most of the cases (unlike yours), where the match is
aborted because of YYFILL(), it's with invalid code, but it shouldn't
happen. BTW, I think the part with the inline_char_handler label where
it looks for opening PHP tags in the HTML, while a good optimization
(using memchr() to find < etc.), was actually added as a workaround for
this re2c/YYFILL() behavior. I didn't try it, but from what I've
observed, I think whatever plain HTML was at the end of a file would
have been lost if a regular rule (like in Flex) was used to match it...
Oh, there are also some more bugs in the code that looks for opening
PHP tag, but they wouldn't be found as easily as this (and haven't been
reported so far). I think I know how it can be fixed nicely, along with
some more other scanner optimizations (for inline HTML and comments,
basically). But I haven't done anything yet since some of it won't even
work with these re2c/YYFILL() issues. :-/
Finally, to simplify what I think is the basic, underlying flaw with
the code of re2c and YYFILL() now, here's a super easy example. Say you
have one rule:
[a-z]+
It will NEVER match any input that a person would think, such as the
string "foo" -- seems pretty messed up to me!?
[2008-06-27 06:03:16] [EMAIL PROTECTED]
marking as critical
[2008-06-27 06:00:54] [EMAIL PROTECTED]
Description:
single line file:
#
produces a parse error:
get's caught with this rule from the re2c scanner.
"#".+ {NEWLINE} {
if ((YYCTYPE*)yytext == SCNG(yy_start)) {
/* ignore first line when it's started with a # */
goto restart;
} else {
goto inline_char_handler;
}
}
basically the scanner runs off the end, and eats everything after the
#
I've fixed it by changing the above to something like:
} else {
/* shunt back to just return the # on it's own.. */
YYCURSOR = YYMARKER;
yyleng = 1;
goto inline_char_handler;
}
--
Edit this bug report at http://bugs.php.net/?id=45372&edit=1
#45374 [Opn->Bgs]: Is not possible compile
ID: 45374 Updated by: [EMAIL PROTECTED] Reported By: jiri dot stefek at unibase dot cz -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Suse SLES 9 64 bit PHP Version: 5.2.6 Assigned To: pajoye New Comment: --with-png-dir=/usr/lib64 is wrong. you have to specify the prefix, not the lib dir. --with-png-dir=/usr/ Please now, ask further question in Suse forums or the install mailing lists. Previous Comments: [2008-06-27 10:30:20] jiri dot stefek at unibase dot cz ./configure --with-oci8=/opt/oracle/product/10GR1 --libdir=lib64 --enable-track-vars --enable-sigchild --with-iconv --with-freetype-dir --disable-dom --with-png-dir=/usr/lib64 --with-jpeg-dir=/usr/lib64 --disable-xml --disable-xmlreader --disable-xmlwriter --without-pear --disable-libxml --disable-simplexml --with-gd [2008-06-27 10:25:13] [EMAIL PROTECTED] what is your configure line? [2008-06-27 09:49:40] jiri dot stefek at unibase dot cz No, both packages was instaled. :~ # rpm -qa | grep libpng libpng-1.2.5-182.10 libpng-32bit-9-200408140621 libpng-devel-1.2.5-182.10 :~ # [2008-06-27 09:11:03] [EMAIL PROTECTED] No, you only installed libpng, not the development packages. Please ask further questions on the php install mailing list or one of the numerous Suse forums. [2008-06-27 08:49:36] jiri dot stefek at unibase dot cz libpng-devel is instaled. I must make 'ln -s /usr/lib/libpng.so.3.1.2.5 /usr/lib/libpng.so' 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/45374 -- Edit this bug report at http://bugs.php.net/?id=45374&edit=1
#45374 [Fbk->Opn]: Is not possible compile
ID: 45374 User updated by: jiri dot stefek at unibase dot cz Reported By: jiri dot stefek at unibase dot cz -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Suse SLES 9 64 bit PHP Version: 5.2.6 Assigned To: pajoye New Comment: ./configure --with-oci8=/opt/oracle/product/10GR1 --libdir=lib64 --enable-track-vars --enable-sigchild --with-iconv --with-freetype-dir --disable-dom --with-png-dir=/usr/lib64 --with-jpeg-dir=/usr/lib64 --disable-xml --disable-xmlreader --disable-xmlwriter --without-pear --disable-libxml --disable-simplexml --with-gd Previous Comments: [2008-06-27 10:25:13] [EMAIL PROTECTED] what is your configure line? [2008-06-27 09:49:40] jiri dot stefek at unibase dot cz No, both packages was instaled. :~ # rpm -qa | grep libpng libpng-1.2.5-182.10 libpng-32bit-9-200408140621 libpng-devel-1.2.5-182.10 :~ # [2008-06-27 09:11:03] [EMAIL PROTECTED] No, you only installed libpng, not the development packages. Please ask further questions on the php install mailing list or one of the numerous Suse forums. [2008-06-27 08:49:36] jiri dot stefek at unibase dot cz libpng-devel is instaled. I must make 'ln -s /usr/lib/libpng.so.3.1.2.5 /usr/lib/libpng.so' [2008-06-27 08:27:42] [EMAIL PROTECTED] Install the libpng development package. 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/45374 -- Edit this bug report at http://bugs.php.net/?id=45374&edit=1
#45374 [Bgs->Fbk]: Is not possible compile
ID: 45374 Updated by: [EMAIL PROTECTED] Reported By: jiri dot stefek at unibase dot cz -Status: Bogus +Status: Feedback Bug Type: Compile Failure Operating System: Suse SLES 9 64 bit PHP Version: 5.2.6 Assigned To: pajoye Previous Comments: [2008-06-27 10:25:13] [EMAIL PROTECTED] what is your configure line? [2008-06-27 09:49:40] jiri dot stefek at unibase dot cz No, both packages was instaled. :~ # rpm -qa | grep libpng libpng-1.2.5-182.10 libpng-32bit-9-200408140621 libpng-devel-1.2.5-182.10 :~ # [2008-06-27 09:11:03] [EMAIL PROTECTED] No, you only installed libpng, not the development packages. Please ask further questions on the php install mailing list or one of the numerous Suse forums. [2008-06-27 08:49:36] jiri dot stefek at unibase dot cz libpng-devel is instaled. I must make 'ln -s /usr/lib/libpng.so.3.1.2.5 /usr/lib/libpng.so' [2008-06-27 08:27:42] [EMAIL PROTECTED] Install the libpng development package. 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/45374 -- Edit this bug report at http://bugs.php.net/?id=45374&edit=1
#45374 [Bgs]: Is not possible compile
ID: 45374 Updated by: [EMAIL PROTECTED] Reported By: jiri dot stefek at unibase dot cz Status: Bogus Bug Type: Compile Failure Operating System: Suse SLES 9 64 bit PHP Version: 5.2.6 Assigned To: pajoye New Comment: what is your configure line? Previous Comments: [2008-06-27 09:49:40] jiri dot stefek at unibase dot cz No, both packages was instaled. :~ # rpm -qa | grep libpng libpng-1.2.5-182.10 libpng-32bit-9-200408140621 libpng-devel-1.2.5-182.10 :~ # [2008-06-27 09:11:03] [EMAIL PROTECTED] No, you only installed libpng, not the development packages. Please ask further questions on the php install mailing list or one of the numerous Suse forums. [2008-06-27 08:49:36] jiri dot stefek at unibase dot cz libpng-devel is instaled. I must make 'ln -s /usr/lib/libpng.so.3.1.2.5 /usr/lib/libpng.so' [2008-06-27 08:27:42] [EMAIL PROTECTED] Install the libpng development package. [2008-06-27 08:03:41] jiri dot stefek at unibase dot cz Description: Is'nt possible compile configure PHP 5.2.6 whith gd on SLES 9.3 64bit. Configrure ended with 'configure: error: libpng.(a|so) not found.' -- Edit this bug report at http://bugs.php.net/?id=45374&edit=1
#45374 [Bgs]: Is not possible compile
ID: 45374 User updated by: jiri dot stefek at unibase dot cz Reported By: jiri dot stefek at unibase dot cz Status: Bogus Bug Type: Compile Failure Operating System: Suse SLES 9 64 bit PHP Version: 5.2.6 Assigned To: pajoye New Comment: No, both packages was instaled. :~ # rpm -qa | grep libpng libpng-1.2.5-182.10 libpng-32bit-9-200408140621 libpng-devel-1.2.5-182.10 :~ # Previous Comments: [2008-06-27 09:11:03] [EMAIL PROTECTED] No, you only installed libpng, not the development packages. Please ask further questions on the php install mailing list or one of the numerous Suse forums. [2008-06-27 08:49:36] jiri dot stefek at unibase dot cz libpng-devel is instaled. I must make 'ln -s /usr/lib/libpng.so.3.1.2.5 /usr/lib/libpng.so' [2008-06-27 08:27:42] [EMAIL PROTECTED] Install the libpng development package. [2008-06-27 08:03:41] jiri dot stefek at unibase dot cz Description: Is'nt possible compile configure PHP 5.2.6 whith gd on SLES 9.3 64bit. Configrure ended with 'configure: error: libpng.(a|so) not found.' -- Edit this bug report at http://bugs.php.net/?id=45374&edit=1
#45376 [NEW]: popen causes HTTP Error 502.2
From: louis at steelbytes dot com
Operating system: Vista SP1 x64
PHP version: 5.2.6
PHP Bug Type: CGI related
Bug description: popen causes HTTP Error 502.2
Description:
1. proc_open('I_dont_exist.exe') returns true. I feel it shouldn't (I'm
guessing this is because php launches cmd.exe and asks it to run
I_dont_exist.exe)
2. popen('I_dont_exist.exe') returns true if I execute the script from the
commandline using php.exe -n -f test.php (see above for what I would
expect), but if I execute it via php-cgi.exe in IIS, I get HTTP Error 502.2
- Bad Gateway (see below).
Reproduce code:
---
$proc = @proc_open(
'c:\\I_dont_exist1.exe'
,array( 0=>array('file','nul','r'), 1=>array('file','nul','w'),
2=>array('file','nul','w') )
,$pipes
);
if ($proc===false)
die('failed proc_open');
proc_close($proc);
echo 'proc_open ok'."\r\n";
$proc = @popen('c:\\I_dont_exist2.exe','r');
if ($proc===false)
die('failed popen');
pclose($proc);
echo 'popen ok'."\r\n";
Expected result:
ideally both should fail, as the target .exe doesn't exist, but not cause
the script to die
Actual result:
--
HTTP Error 502.2 - Bad Gateway
The specified CGI application misbehaved by not returning a complete set
of HTTP headers. The headers it did return are "'c:\I_dont_exist2.exe' is
not recognized as an internal or external command, operable program or
batch file. X-Powered-By: PHP/5.2.6 Content-type: text/html start
proc_open ok popen ok end ".
--
Edit bug report at http://bugs.php.net/?id=45376&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45376&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45376&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45376&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45376&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45376&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45376&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45376&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45376&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45376&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45376&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45376&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45376&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45376&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45376&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45376&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45376&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45376&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45376&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45376&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45376&r=mysqlcfg
#45372 [Ctl->Asn]: hash# check in new re2c parser breaks code
ID: 45372
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Critical
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.3CVS-2008-06-27 (CVS)
-Assigned To:
+Assigned To: helly
New Comment:
This should work like in older releases, Marcus please check it!
Previous Comments:
[2008-06-27 09:05:48] [EMAIL PROTECTED]
(yyless(1) could just be used before the goto...)
Anyway, did you actually try that? AFAIK it still won't work, at least
with your single line example (which there's already been at least one
report about). While the local code fix is correct, the re2c code/logic
seems flawed to me. (Maybe this bug report can be about that instead, in
general, since I didn't get around to sending a follow-up message to the
internals@ list yet, explaining things. :-))
In this example, it will still be broken because of the YYFILL() check
-- each time it checks if the next character can match, even when it's
at the end of the input. YYFILL() then makes it return, completely
ignoring anything that has matched up to that point!
I'm not sure if this explanation is 100% correct, but I believe this
wrong behavior happens when EOF is encountered while trying to match the
variable length part of ANY rule; or something close to that. :-) It's
been over a month since I tried to track and figure out what was
happening. Granted, most of the cases (unlike yours), where the match is
aborted because of YYFILL(), it's with invalid code, but it shouldn't
happen. BTW, I think the part with the inline_char_handler label where
it looks for opening PHP tags in the HTML, while a good optimization
(using memchr() to find < etc.), was actually added as a workaround for
this re2c/YYFILL() behavior. I didn't try it, but from what I've
observed, I think whatever plain HTML was at the end of a file would
have been lost if a regular rule (like in Flex) was used to match it...
Oh, there are also some more bugs in the code that looks for opening
PHP tag, but they wouldn't be found as easily as this (and haven't been
reported so far). I think I know how it can be fixed nicely, along with
some more other scanner optimizations (for inline HTML and comments,
basically). But I haven't done anything yet since some of it won't even
work with these re2c/YYFILL() issues. :-/
Finally, to simplify what I think is the basic, underlying flaw with
the code of re2c and YYFILL() now, here's a super easy example. Say you
have one rule:
[a-z]+
It will NEVER match any input that a person would think, such as the
string "foo" -- seems pretty messed up to me!?
[2008-06-27 06:03:16] [EMAIL PROTECTED]
marking as critical
[2008-06-27 06:00:54] [EMAIL PROTECTED]
Description:
single line file:
#
produces a parse error:
get's caught with this rule from the re2c scanner.
"#".+ {NEWLINE} {
if ((YYCTYPE*)yytext == SCNG(yy_start)) {
/* ignore first line when it's started with a # */
goto restart;
} else {
goto inline_char_handler;
}
}
basically the scanner runs off the end, and eats everything after the
#
I've fixed it by changing the above to something like:
} else {
/* shunt back to just return the # on it's own.. */
YYCURSOR = YYMARKER;
yyleng = 1;
goto inline_char_handler;
}
--
Edit this bug report at http://bugs.php.net/?id=45372&edit=1
#45375 [NEW]: __object_vars() magic method
From: margus dot sipria at gmail dot com
Operating system: *
PHP version: 5.2.6
PHP Bug Type: Feature/Change Request
Bug description: __object_vars() magic method
Description:
When I use __set and __get methods on object i have set data to my object,
and when i wanna get thows methods i would only get public methods that are
non.
Same think is happened when i wanna example transfere Object to json
format, there should be some way that i could get data that i wanna.
This could be very useful example using with Zend Framwork encoding a
Database Table Row
(http://framework.zend.com/manual/en/zend.db.table.row.html) where data is
in private variable.
if not a Core function (that it should be in my opinion) then SPL
interface would be needed.
Reproduce code:
---
class Test {
protected $_data = array();
public function __set($var, $value) {$this->_data[$var] = $value;}
public function __get($var) {
if (isset($this->_data[$var])) {return $this->_data[$var]; }
trigger_error('Undefined property: ' . __CLASS__ . '::$' . $var,
E_USER_NOTICE);
return null;
}
public function __isset($var) {return isset($this->_data[$var]);}
public function __object_vars() {
return $this->_data;
}
}
$json = new Test();
$json->variable = 'value';
echo json_encode($json);
Expected result:
{"variable":"value"}
Actual result:
--
{}
--
Edit bug report at http://bugs.php.net/?id=45375&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45375&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45375&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45375&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45375&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45375&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45375&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45375&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45375&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45375&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45375&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45375&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45375&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45375&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45375&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45375&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45375&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45375&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45375&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45375&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45375&r=mysqlcfg
#45374 [Bgs]: Is not possible compile
ID: 45374 Updated by: [EMAIL PROTECTED] Reported By: jiri dot stefek at unibase dot cz Status: Bogus Bug Type: Compile Failure Operating System: Suse SLES 9 64 bit PHP Version: 5.2.6 Assigned To: pajoye New Comment: No, you only installed libpng, not the development packages. Please ask further questions on the php install mailing list or one of the numerous Suse forums. Previous Comments: [2008-06-27 08:49:36] jiri dot stefek at unibase dot cz libpng-devel is instaled. I must make 'ln -s /usr/lib/libpng.so.3.1.2.5 /usr/lib/libpng.so' [2008-06-27 08:27:42] [EMAIL PROTECTED] Install the libpng development package. [2008-06-27 08:03:41] jiri dot stefek at unibase dot cz Description: Is'nt possible compile configure PHP 5.2.6 whith gd on SLES 9.3 64bit. Configrure ended with 'configure: error: libpng.(a|so) not found.' -- Edit this bug report at http://bugs.php.net/?id=45374&edit=1
#45372 [Ctl]: hash# check in new re2c parser breaks code
ID: 45372
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.3CVS-2008-06-27 (CVS)
New Comment:
(yyless(1) could just be used before the goto...)
Anyway, did you actually try that? AFAIK it still won't work, at least
with your single line example (which there's already been at least one
report about). While the local code fix is correct, the re2c code/logic
seems flawed to me. (Maybe this bug report can be about that instead, in
general, since I didn't get around to sending a follow-up message to the
internals@ list yet, explaining things. :-))
In this example, it will still be broken because of the YYFILL() check
-- each time it checks if the next character can match, even when it's
at the end of the input. YYFILL() then makes it return, completely
ignoring anything that has matched up to that point!
I'm not sure if this explanation is 100% correct, but I believe this
wrong behavior happens when EOF is encountered while trying to match the
variable length part of ANY rule; or something close to that. :-) It's
been over a month since I tried to track and figure out what was
happening. Granted, most of the cases (unlike yours), where the match is
aborted because of YYFILL(), it's with invalid code, but it shouldn't
happen. BTW, I think the part with the inline_char_handler label where
it looks for opening PHP tags in the HTML, while a good optimization
(using memchr() to find < etc.), was actually added as a workaround for
this re2c/YYFILL() behavior. I didn't try it, but from what I've
observed, I think whatever plain HTML was at the end of a file would
have been lost if a regular rule (like in Flex) was used to match it...
Oh, there are also some more bugs in the code that looks for opening
PHP tag, but they wouldn't be found as easily as this (and haven't been
reported so far). I think I know how it can be fixed nicely, along with
some more other scanner optimizations (for inline HTML and comments,
basically). But I haven't done anything yet since some of it won't even
work with these re2c/YYFILL() issues. :-/
Finally, to simplify what I think is the basic, underlying flaw with
the code of re2c and YYFILL() now, here's a super easy example. Say you
have one rule:
[a-z]+
It will NEVER match any input that a person would think, such as the
string "foo" -- seems pretty messed up to me!?
Previous Comments:
[2008-06-27 06:03:16] [EMAIL PROTECTED]
marking as critical
[2008-06-27 06:00:54] [EMAIL PROTECTED]
Description:
single line file:
#
produces a parse error:
get's caught with this rule from the re2c scanner.
"#".+ {NEWLINE} {
if ((YYCTYPE*)yytext == SCNG(yy_start)) {
/* ignore first line when it's started with a # */
goto restart;
} else {
goto inline_char_handler;
}
}
basically the scanner runs off the end, and eats everything after the
#
I've fixed it by changing the above to something like:
} else {
/* shunt back to just return the # on it's own.. */
YYCURSOR = YYMARKER;
yyleng = 1;
goto inline_char_handler;
}
--
Edit this bug report at http://bugs.php.net/?id=45372&edit=1
#45374 [Bgs]: Is not possible compile
ID: 45374 User updated by: jiri dot stefek at unibase dot cz Reported By: jiri dot stefek at unibase dot cz Status: Bogus Bug Type: Compile Failure Operating System: Suse SLES 9 64 bit PHP Version: 5.2.6 Assigned To: pajoye New Comment: libpng-devel is instaled. I must make 'ln -s /usr/lib/libpng.so.3.1.2.5 /usr/lib/libpng.so' Previous Comments: [2008-06-27 08:27:42] [EMAIL PROTECTED] Install the libpng development package. [2008-06-27 08:03:41] jiri dot stefek at unibase dot cz Description: Is'nt possible compile configure PHP 5.2.6 whith gd on SLES 9.3 64bit. Configrure ended with 'configure: error: libpng.(a|so) not found.' -- Edit this bug report at http://bugs.php.net/?id=45374&edit=1
#45374 [Opn->Bgs]: Is not possible compile
ID: 45374 Updated by: [EMAIL PROTECTED] Reported By: jiri dot stefek at unibase dot cz -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Suse SLES 9 64 bit PHP Version: 5.2.6 -Assigned To: +Assigned To: pajyoe New Comment: Install the libpng development package. Previous Comments: [2008-06-27 08:03:41] jiri dot stefek at unibase dot cz Description: Is'nt possible compile configure PHP 5.2.6 whith gd on SLES 9.3 64bit. Configrure ended with 'configure: error: libpng.(a|so) not found.' -- Edit this bug report at http://bugs.php.net/?id=45374&edit=1
#45374 [NEW]: Is not possible compile
From: jiri dot stefek at unibase dot cz Operating system: Suse SLES 9 64 bit PHP version: 5.2.6 PHP Bug Type: Compile Failure Bug description: Is not possible compile Description: Is'nt possible compile configure PHP 5.2.6 whith gd on SLES 9.3 64bit. Configrure ended with 'configure: error: libpng.(a|so) not found.' -- Edit bug report at http://bugs.php.net/?id=45374&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45374&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45374&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45374&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45374&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45374&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45374&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45374&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45374&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45374&r=support Expected behavior:http://bugs.php.net/fix.php?id=45374&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45374&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45374&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45374&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45374&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45374&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45374&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45374&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45374&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45374&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45374&r=mysqlcfg
