#50576 [NEW]: XML_OPTION_SKIP_TAGSTART option has no effect
From: pgacv2 at gmail dot com Operating system: Ubuntu 9.10 PHP version: 5.2.12 PHP Bug Type: XML related Bug description: XML_OPTION_SKIP_TAGSTART option has no effect Description: I'm actually running PHP 5.2.10 (that came with Ubuntu 9.10), but I can't compile a newer snapshot because my system suffers from bug https://bugs.launchpad.net/ubuntu/+bug/81057 and the make install hangs when trying to fetch http://pear.php.net/install-pear-nozlib.phar. But there's nothing in the bug database with "XML_OPTION_SKIP_TAGSTART," so maybe no one's noticed this one before. Setting XML_OPTION_SKIP_TAGSTART through xml_parser_set_option($parser, XML_OPTION_SKIP_TAGSTART, $x) has no effect. Instead of skipping $x number of characters from the beginning of the tag name (like to remove a namespace), it leaves the tag name whole. Reproduce code: --- test.xml: http://www.fpdsng.com/FPDS";> 867 Code: Expected result: LISTOFAWARDS COUNT TOTAL Actual result: -- NS1:LISTOFAWARDS NS1:COUNT NS1:TOTAL -- Edit bug report at http://bugs.php.net/?id=50576&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50576&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50576&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50576&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50576&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50576&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50576&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50576&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50576&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50576&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50576&r=support Expected behavior: http://bugs.php.net/fix.php?id=50576&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50576&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50576&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50576&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50576&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50576&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50576&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50576&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50576&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50576&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50576&r=mysqlcfg
#50575 [Opn->Csd]: PDO_PGSQL LOBs are not compatible with PostgreSQL 8.5
ID: 50575 Updated by: mbecc...@php.net Reported By: mbecc...@php.net -Status: Open +Status: Closed Bug Type: PDO related Operating System: * PHP Version: 5.2.12 Assigned To: mbeccati New Comment: This bug has been fixed in SVN. 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: [2009-12-25 20:09:09] s...@php.net Automatic comment from SVN on behalf of mbeccati Revision: http://svn.php.net/viewvc/?view=revision&revision=292629 Log: - Fixed bug #50575 (PDO_PGSQL LOBs are not compatible with PostgreSQL 8.5) # Affects 5.2 only, no need to MFB [2009-12-25 20:01:08] mbecc...@php.net Description: Tested with 8.5alpha3. Some 5.3+ improvemnts were not backported to 5.2. Specifically ones that were raising the minimum requirements. PDO_PGSQL in PHP 5.2 doesn't use PQunescapeBytea, but a copy of its code taken from an old version of Postgres, thus can't properly decode bytea fields on 8.5 because the default encoding has changed to the new "hex" format, while 5.3+ can. -- Edit this bug report at http://bugs.php.net/?id=50575&edit=1
#50575 [NEW]: PDO_PGSQL LOBs are not compatible with PostgreSQL 8.5
From: mbecc...@php.net Operating system: * PHP version: 5.2.12 PHP Bug Type: PDO related Bug description: PDO_PGSQL LOBs are not compatible with PostgreSQL 8.5 Description: Tested with 8.5alpha3. Some 5.3+ improvemnts were not backported to 5.2. Specifically ones that were raising the minimum requirements. PDO_PGSQL in PHP 5.2 doesn't use PQunescapeBytea, but a copy of its code taken from an old version of Postgres, thus can't properly decode bytea fields on 8.5 because the default encoding has changed to the new "hex" format, while 5.3+ can. -- Edit bug report at http://bugs.php.net/?id=50575&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50575&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50575&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50575&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50575&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50575&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50575&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50575&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50575&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50575&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50575&r=support Expected behavior: http://bugs.php.net/fix.php?id=50575&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50575&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50575&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50575&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50575&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50575&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50575&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50575&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50575&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50575&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50575&r=mysqlcfg
#50021 [Fbk->Csd]: Predefined Statements doesn't allow Strings with more than 256 letters.
ID: 50021 User updated by: novitools dot novi at web dot de Reported By: novitools dot novi at web dot de -Status: Feedback +Status: Closed Bug Type: MySQLi related Operating System: Windows Vista PHP Version: 5.3.0 New Comment: I was ill for the last few day. Thats why it took me so long to answer. I tried to use the latest snapshot, but I had problems with a connection to a MySQL-Server. The installation of an apache and PHP itself worked fine, but every access to the MySQL-Server end in an Internal Server Error. However a new version of XAMPP has been offered since yesterday. The new Version inculdes PHP 5.3.1 . And now it runs. The problem I have described doesn't exists anymore in PHP Version 5.3.1 . Previous Comments: [2009-12-22 10:01:12] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-11-03 21:32:25] u...@php.net Thanks for the feedback! I feared that meta data would indicate the correct length. To be honest, I have no idea so far what may be causing it. [2009-11-03 14:33:21] novitools dot novi at web dot de Here is the result: Field 1: `You can only read the first 256 words of this text. That is why I must write such a long text, because I must reach the limit of 256 words. The same error occours, when you try to select a text column from the database. But I didn't had this error before ` Catalog:`def` Database: `` Table: `` Org_table: `` Type: VAR_STRING Collation: latin1_swedish_ci (8) Length: 284 Max_length: 284 Decimals: 31 Flags: NOT_NULL +--- ---+ | You can only read the first 256 words of this text. That is why I must write such a long text, because I must reach the limit of 256 words. The same error occours, when you try to select a text column from the database. But I didn't had this error before | +--- ---+ | You can only read the first 256 words of this text. That is why I must write such a long text, because I must reach the limit of 256 words. The same error occours, when you try to select a text column from the database. But I didn't had this error before in a previous version of php. | +--- ---+ 1 row in set (0.00 sec) [2009-11-03 09:54:50] u...@php.net Please run you query in the MySQL prompt and show the meta data that is returned from MySQL. Start the MySQL prompt with "mysql --column-type-info" followed by your usual "-u", "-p", "-h" etc. options. For example: nixn...@ulflinux:~> /usr/local/mysql/bin/mysql --column-type-info -uroot -proot Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 13 Server version: 5.1.39-debug Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> select 1; Field 1: `1` Catalog:`def` Database: `` Table: `` Org_table: `` Type: LONGLONG Collation: binary (63) Length: 1 Max_length: 1 Decimals: 0 Flags: NOT_NULL BINARY NUM +---+ | 1 | +---+ | 1 | +---+ 1 row in set (0.00 sec) But, of course, run your failing query and run mysql prompt on your system. Thanks, Ulf [2009-10-30 15:12:35] novitools dot novi at web dot de So the problem only occurs on specific versions: No Problem with this Versions: client_version 50005 server_version 50132 Big Problem with this Versions: client_version 50137 server_version 50137 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/50021 -- Edit this bug report at http://bugs.php.net/?id=50021&edit=1
#50574 [Opn->Csd]: PDO prepared statement failed with UPDATE and WHERE conditions
ID: 50574
User updated by: ajulien at gmail dot com
Reported By: ajulien at gmail dot com
-Status: Open
+Status: Closed
Bug Type: PDO related
Operating System: OSX 10.6
PHP Version: 5.2.12
New Comment:
Sounds like the bug is else where because this works :
query("DROP TABLE users");
$db->query("CREATE TABLE users (user MEDIUMTEXT ( 255 ), level INTEGER
( 2 ))");
$db->query("INSERT INTO users VALUES('foobar',2)");
$db->query("INSERT INTO users VALUES('John Doe',2)");
$db->query("INSERT INTO users VALUES('John Doe',2)");
$prep = $db->prepare('UPDATE "users" SET "level" = ? WHERE "user"= ?
');
var_dump($prep);
$prep->execute(array('99','foobar'));
var_dump($db->errorInfo());
?>
Previous Comments:
[2009-12-25 16:21:51] ajulien at gmail dot com
Description:
A simple prepared statement will fail with « bind or column index out
of
range » in some cases
Reproduce code:
---
$prep = $db->prepare('UPDATE "users" SET "force" = ? WHERE ( "user" = ?
)');
$prep->execute(array('bar','foo'));
Expected result:
The update should be executed
Actual result:
--
« bind or column index out of range »
--
Edit this bug report at http://bugs.php.net/?id=50574&edit=1
#50567 [Opn]: cron execution with safe-mode fails on file_exists
ID: 50567
Updated by: ras...@php.net
Reported By: svecpetr at svecpetr dot com
Status: Open
Bug Type: Safe Mode/open_basedir
Operating System: freebsd
PHP Version: 5.2SVN-2009-12-24 (snap)
New Comment:
Any symlinks involved anywhere along that path?
And yes, as Jani asked for, your relevant php.ini settings and a
reproducing script would help us determine what is going on here.
open_basedir works fine, so there is something you are not telling us.
Previous Comments:
[2009-12-25 15:12:49] svecpetr at svecpetr dot com
just read :o)
open_base dir is: /DISK2/WWW:/DISK3/WWW:/DISK2/TMP:/NET:/tmp
error message is: Warning: file_exists(): open_basedir restriction in
effect.
File('/DISK2/WWW/xxx.cz/www/index.php') is not within the allowed
path(s):
(/DISK2/WWW:/DISK3/WWW:/DISK2/TMP:/NET:/tmp) in
/DISK2/WWW/xxx.cz/www/index.php on line 7
[2009-12-24 23:22:54] j...@php.net
What is the exact error you get with exactly what line of code? And
what is open_basedir set to? (EXACTLY..)
[2009-12-24 09:36:30] svecpetr at svecpetr dot com
Description:
read how reproduce this bug FIRST!!!
try execute file_exists($_SERVER['SCRIPT_FILENAME']);
$_SERVER['SCRIPT_FILENAME'] is '/DISK2/WWW/xxx.cz/www/index.php'
it fails with error:
Warning: file_exists(): open_basedir restriction in effect.
File(underconstruction.html) is not within the allowed path(s):
(/DISK2/WWW:/DISK3/WWW:/DISK2/TMP:/NET:/tmp) in
/DISK2/WWW/xxx.cz/www/index.php on line 7
Reproduce code:
---
---
>From manual page: function.file-exists#Description
---
safe-mode ON
execute script by CRON, means $_SERVER['REMOTE_ADDR'] is empty
get of getcwd() returns '/'
Expected result:
why should I change
chdir('/DISK2/WWW/xxx.cz/www/')
before use of function
file_exists($_SERVER['SCRIPT_FILENAME']);
or
file_exists('/DISK2/WWW/xxx.cz/www/index.php')
when I ask this function for file that is IN ALLOWED PATH
Actual result:
--
correct file_exists function
--
Edit this bug report at http://bugs.php.net/?id=50567&edit=1
#50574 [NEW]: PDO prepared statement failed with UPDATE and WHERE conditions
From: ajulien at gmail dot com
Operating system: OSX 10.6
PHP version: 5.2.12
PHP Bug Type: PDO related
Bug description: PDO prepared statement failed with UPDATE and WHERE conditions
Description:
A simple prepared statement will fail with « bind or column index out of
range » in some cases
Reproduce code:
---
$prep = $db->prepare('UPDATE "users" SET "force" = ? WHERE ( "user" = ?
)');
$prep->execute(array('bar','foo'));
Expected result:
The update should be executed
Actual result:
--
« bind or column index out of range »
--
Edit bug report at http://bugs.php.net/?id=50574&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50574&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50574&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50574&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50574&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50574&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50574&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50574&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50574&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50574&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50574&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50574&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50574&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50574&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50574&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50574&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50574&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50574&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50574&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50574&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50574&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50574&r=mysqlcfg
#50567 [Fbk->Opn]: cron execution with safe-mode fails on file_exists
ID: 50567
User updated by: svecpetr at svecpetr dot com
Reported By: svecpetr at svecpetr dot com
-Status: Feedback
+Status: Open
Bug Type: Safe Mode/open_basedir
Operating System: freebsd
PHP Version: 5.2SVN-2009-12-24 (snap)
New Comment:
just read :o)
open_base dir is: /DISK2/WWW:/DISK3/WWW:/DISK2/TMP:/NET:/tmp
error message is: Warning: file_exists(): open_basedir restriction in
effect.
File('/DISK2/WWW/xxx.cz/www/index.php') is not within the allowed
path(s):
(/DISK2/WWW:/DISK3/WWW:/DISK2/TMP:/NET:/tmp) in
/DISK2/WWW/xxx.cz/www/index.php on line 7
Previous Comments:
[2009-12-24 23:22:54] j...@php.net
What is the exact error you get with exactly what line of code? And
what is open_basedir set to? (EXACTLY..)
[2009-12-24 09:36:30] svecpetr at svecpetr dot com
Description:
read how reproduce this bug FIRST!!!
try execute file_exists($_SERVER['SCRIPT_FILENAME']);
$_SERVER['SCRIPT_FILENAME'] is '/DISK2/WWW/xxx.cz/www/index.php'
it fails with error:
Warning: file_exists(): open_basedir restriction in effect.
File(underconstruction.html) is not within the allowed path(s):
(/DISK2/WWW:/DISK3/WWW:/DISK2/TMP:/NET:/tmp) in
/DISK2/WWW/xxx.cz/www/index.php on line 7
Reproduce code:
---
---
>From manual page: function.file-exists#Description
---
safe-mode ON
execute script by CRON, means $_SERVER['REMOTE_ADDR'] is empty
get of getcwd() returns '/'
Expected result:
why should I change
chdir('/DISK2/WWW/xxx.cz/www/')
before use of function
file_exists($_SERVER['SCRIPT_FILENAME']);
or
file_exists('/DISK2/WWW/xxx.cz/www/index.php')
when I ask this function for file that is IN ALLOWED PATH
Actual result:
--
correct file_exists function
--
Edit this bug report at http://bugs.php.net/?id=50567&edit=1
#50382 [Asn->Fbk]: garbage collection crashes
ID: 50382 Updated by: dmi...@php.net Reported By: dirk at bean-it dot nl -Status: Assigned +Status: Feedback Bug Type: Reproducible crash Operating System: Debian 5.0 PHP Version: 5.3, 6 Assigned To: dmitry New Comment: The bug #50519 is fixed, however, I can't be sure that this crash is caused by the same bug. Please check SVN snapshot. Previous Comments: [2009-12-18 18:47:16] j...@php.net See bug #50519 which has identical backtrace with short reproducing script. [2009-12-09 12:35:43] dirk at bean-it dot nl I'm going to prepare a server with the software. Please allow me a few days to arrange this. I'll email the details when things are ready. [2009-12-08 08:30:06] dmi...@php.net In case you can provide a long script with instruction it's an option too. It's not easy to identify the reason of crash caused by garbage collector and provide a short script. SSH access to a server where I can play with bug is also an option. [2009-12-07 08:43:02] dirk at bean-it dot nl I can confirm that setting: zend.enable_gc=Off makes the crash go away. I'm still looking to pinpoint the problem. I hope I can provide a short script which crashes php. [2009-12-06 15:23:28] srina...@php.net alternatively, you can also set "zend.enable_gc=Off" within your php.ini and this should make the crash go away as well. 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/50382 -- Edit this bug report at http://bugs.php.net/?id=50382&edit=1
#50519 [Asn->Csd]: segfault in garbage collection when using set_error_handler and DomDocument
ID: 50519 Updated by: dmi...@php.net Reported By: robin dot kunde at gmail dot com -Status: Assigned +Status: Closed Bug Type: Reproducible crash Operating System: * PHP Version: 5.3, 6 Assigned To: dmitry New Comment: This bug has been fixed in SVN. 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: [2009-12-25 13:11:19] s...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=292624 Log: Fixed bug #50519 (segfault in garbage collection when using set_error_handler and DomDocument) [2009-12-18 18:47:43] j...@php.net Quite likely same as bug #50382 [2009-12-18 18:46:05] j...@php.net Dmitry, check this out, it's your code crashing here. :) [2009-12-18 18:41:46] j...@php.net Happens with latest SVN, disabling GC makes the crash go away. Backtrace: Program received signal SIGSEGV, Segmentation fault. zval_mark_grey (pz=0xa6cb578) at /home/jani/src/php-5.3/Zend/zend_gc.c:360 360 pz = *(zval**)p->pData; (gdb) bt #0 zval_mark_grey (pz=0xa6cb578) at /home/jani/src/php-5.3/Zend/zend_gc.c:360 #1 0x082c5525 in gc_collect_cycles () at /home/jani/src/php-5.3/Zend/zend_gc.c:417 #2 0x082aa9d5 in zend_deactivate () at /home/jani/src/php-5.3/Zend/zend.c:900 #3 0x0825abcf in php_request_shutdown (dummy=0x0) at /home/jani/src/php-5.3/main/main.c:1606 #4 0x08329604 in main (argc=3, argv=0xbff82544) at /home/jani/src/php-5.3/sapi/cli/php_cli.c:1373 [2009-12-18 17:32:38] robin dot kunde at gmail dot com that snapshot (200912181530) seems to be identical to the one i used (200912181330). anyway, the problem persists. 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/50519 -- Edit this bug report at http://bugs.php.net/?id=50519&edit=1
