#44589 [Com]: pdo_oci crashes and aborts php script for LOB columns
ID: 44589
Comment by: kenashkov at gmail dot com
Reported By: s dot rost at ewerk dot com
Status: Assigned
Bug Type: PDO related
Operating System: Debian 2.6.18.dfsg.1-18etch1
PHP Version: 5.*, 6CVS (2009-04-25)
Assigned To: cjorcl
New Comment:
I have a very similar problem. Segfaults when executing two exactly
same queries each after another. The query must contain a JOIN and one
of the tables a CLOB (if it is against a single table without a join
works fine). If the query is executed only once it works.
== CODE ===
1);
$s = $db->prepare($q);
$s->execute($b);
$data = $s->fetchAll();
$q = "
SELECT
clob_column
FROM
table1
INNER JOIN table2 ON table2.tid=table1.tid
WHERE
main_table.tid = :tid
";
$b = array('tid'=>1);
$s = $db->prepare($q);
$s->execute($b);
$data = $s->fetchAll();
print 'ok';//never reached
?>
=== CONFIGURE OPTIONS ===
'./configure' '--prefix=/web/php5.3-debug'
'--with-apxs2=/web/apache2.2-php5.3-debug/bin/apxs'
'--enable-bcmath=shared' '--with-bz2=shared' '--enable-calendar=shared'
'--with-curl=shared' '--enable-dbase=shared' '--enable-dbx=shared'
'--enable-exif=shared' '--with-fam=shared' '--with-gettext=shared'
'--with-gmp=shared' '--with-iconv=shared' '--with-gd=shared'
'--with-ttf' '--with-freetype-dir' '--enable-gd-native-ttf'
'--with-jpeg-dir' '--with-png-dir' '--with-xpm-dir--with-imap-ssl'
'--with-kerberos' '--with-ldap=shared' '--with-ldap-sasl'
'--with-mcal=shared' '--with-mcrypt=shared' '--with-mhash=shared'
'--enable-mbstring=shared' '--with-mysql=shared,/usr'
'--with-mysqli=shared,/usr/bin/mysql_config' '--with-ncurses=shared'
'--with-openssl=shared' '--enable-pcntl=shared'
'--with-pgsql=shared,/usr/bin/pg_config' '--with-imap=shared'
'--with-imap-ssl'
'--with-oci8=shared,instantclient,/opt/oracle_instantclient_11,11.1.0.6.0'
'--enable-sysvsem=shared' '--enable-sysvshm=shared'
'--enable-sysvmsg=shared' '--enable-shmop' '--enable-mbstring'
'--with-zlib=shared' '--with-bz2=shared' '--with-xsl=shared'
'--with-pdo-mysql=shared' '--with-pdo-pgsql=shared'
'--with-pdo-oci=shared,instantclient,/opt/oracle_instantclient_11,11.1.0.6.0'
'--enable-debug'
=== BACKTRACE ==
#0 0x2b46f4b7148c in kohfri () from
/opt/oracle_instantclient_11/libclntsh.so.11.1
#1 0x2b46f5fe1fd1 in kohfrr () from
/opt/oracle_instantclient_11/libclntsh.so.11.1
#2 0x2b46f4b710e2 in kohfrw () from
/opt/oracle_instantclient_11/libclntsh.so.11.1
#3 0x2b46f4abdbeb in kollfrfn () from
/opt/oracle_instantclient_11/libclntsh.so.11.1
#4 0x2b46f47d472e in kpufdesc2 () from
/opt/oracle_instantclient_11/libclntsh.so.11.1
#5 0x2b46f47d3ebb in kpufdesc () from
/opt/oracle_instantclient_11/libclntsh.so.11.1
#6 0x2b46f47a8af9 in OCIDescriptorFree () from
/opt/oracle_instantclient_11/libclntsh.so.11.1
#7 0x2b46f7621aa6 in oci_blob_close (stream=0xa94680,
close_handle=1) at
/home/DATA/temp_compile/php-5.3.0/ext/pdo_oci/oci_statement.c:652
#8 0x2b46f0cc1105 in _php_stream_free (stream=0xa94680,
close_options=11) at
/home/DATA/temp_compile/php-5.3.0/main/streams/streams.c:356
#9 0x2b46f0cc3d7d in stream_resource_regular_dtor (rsrc=0xa94868)
at /home/DATA/temp_compile/php-5.3.0/main/streams/streams.c:1426
#10 0x2b46f0d35e38 in list_entry_destructor (ptr=0xa94868) at
/home/DATA/temp_compile/php-5.3.0/Zend/zend_list.c:184
#11 0x2b46f0d32d7b in zend_hash_del_key_or_index
(ht=0x2b46f15286b0, arKey=0x0, nKeyLength=0, h=3, flag=1) at
/home/DATA/temp_compile/php-5.3.0/Zend/zend_hash.c:497
#12 0x2b46f0d35905 in _zend_list_delete (id=3) at
/home/DATA/temp_compile/php-5.3.0/Zend/zend_list.c:58
#13 0x2b46f0d1fd57 in _zval_dtor_func (zvalue=0xa94590,
__zend_filename=0x2b46f1224d28
"/home/DATA/temp_compile/php-5.3.0/Zend/zend_execute_API.c",
__zend_lineno=435)
at /home/DATA/temp_compile/php-5.3.0/Zend/zend_variables.c:60
#14 0x2b46f0d0f6d5 in _zval_dtor (zvalue=0xa94590,
__zend_filename=0x2b46f1224d28
"/home/DATA/temp_compile/php-5.3.0/Zend/zend_execute_API.c",
__zend_lineno=435)
at /home/DATA/temp_compile/php-5.3.0/Zend/zend_variables.h:35
#15 0x2b46f0d0f9fc in _zval_ptr_dtor (zval_p
#48614 [Com]: Loading "pdo_sqlite.so" fails: undefined symbol: sqlite3_libversion
ID: 48614 Comment by: kenashkov at gmail dot com Reported By: kaspernj at gmail dot com Status: Assigned Bug Type: PDO related Operating System: Ubuntu Jaunty PHP Version: 5.3.0RC4 Assigned To: scottmac New Comment: I'm able to reproduce this with 5.3.1 RC3 on debian 5. Previous Comments: [2009-08-23 00:22:27] koubel at volny dot cz yes, same problem with php 5.3.0 final instalation on debian stable [2009-07-09 18:18:07] dkepplinger at gmail dot com I have the same problem with PHP 5.3 on Debian 5.0.2 when loading the pdo_sqlite.so extension in the config file. [2009-06-23 07:18:49] dominics at gmail dot com I can reproduce this bug (Debian Lenny) with the following minimal configure line: ./configure --with-zlib --enable-pdo=shared --with-sqlite=shared --with-pdo-sqlite=shared For now, not building PDO as shared seems to be a workaround. [2009-06-20 16:41:46] kaspernj at gmail dot com "sqlite3.so" loads fine. It does not help to load "pdo_sqlite.so" afterwards though - getting the exact same error. Here is what I did: #!/opt/php53/bin/php [2009-06-20 16:35:43] scott...@php.net If you load sqlite3.so first does it work? 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/48614 -- Edit this bug report at http://bugs.php.net/?id=48614&edit=1
#46304 [NEW]: define() namespaced constant is case sensitive
From: kenashkov at gmail dot com Operating system: GNU/Linux debian lenny PHP version: 5.3CVS-2008-10-15 (snap) PHP Bug Type: Scripting Engine problem Bug description: define() namespaced constant is case sensitive Description: The current implementatino of namespaces is case INSENSITIVE. But defining a constant using define and having capitals in the namespace makes the defined constant unreachable. We can verify this using get_defined_constants(). In case a constant was defined like: we can see the the defined constant/namespace is in fact: ns1::ns2::const1; But if the constant was defined using define(), it is kept with the capitalization: get_defined_constants() gives NS1::ns2::const1. But because the namespaces are case insensitive the call: resolves in fact to ns1::ns2::const1 which is undefined. Reproduce code: --- Expected result: value Actual result: -- Fatal error: Class 'NS1::ns2' not found in /home/local/tests/t35.php on line 3 -- Edit bug report at http://bugs.php.net/?id=46304&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46304&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46304&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46304&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46304&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46304&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46304&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46304&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46304&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46304&r=support Expected behavior:http://bugs.php.net/fix.php?id=46304&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46304&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46304&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46304&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46304&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46304&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46304&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46304&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46304&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46304&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46304&r=mysqlcfg
#46304 [Opn]: definening namespaced constant using define() defines CASE SENSITIVE namespace
ID: 46304 User updated by: kenashkov at gmail dot com -Summary: define() namespaced constant is case sensitive Reported By: kenashkov at gmail dot com Status: Open Bug Type: Scripting Engine problem Operating System: GNU/Linux debian lenny PHP Version: 5.3CVS-2008-10-15 (snap) New Comment: changed summary Previous Comments: [2008-10-15 15:33:34] kenashkov at gmail dot com I had a quick look again over the docs and nowhere is documented that the namespaces are case insensitive. I think this should go in the docs, as well if this issue with define() wont be fixed, to be documented too. [2008-10-15 15:29:42] kenashkov at gmail dot com Description: The current implementatino of namespaces is case INSENSITIVE. But defining a constant using define and having capitals in the namespace makes the defined constant unreachable. We can verify this using get_defined_constants(). In case a constant was defined like: we can see the the defined constant/namespace is in fact: ns1::ns2::const1; But if the constant was defined using define(), it is kept with the capitalization: get_defined_constants() gives NS1::ns2::const1. But because the namespaces are case insensitive the call: resolves in fact to ns1::ns2::const1 which is undefined. Reproduce code: --- Expected result: value Actual result: -- Fatal error: Class 'NS1::ns2' not found in /home/local/tests/t35.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=46304&edit=1
#46304 [Opn]: definening namespaced constant using define() defines CASE SENSITIVE namespace
ID: 46304 User updated by: kenashkov at gmail dot com Reported By: kenashkov at gmail dot com Status: Open Bug Type: Scripting Engine problem Operating System: GNU/Linux debian lenny PHP Version: 5.3CVS-2008-10-15 (snap) New Comment: '.print_r($dc['user'],true).''; ?> gives Array ( [ns1::ns2::const2] => value2 [NS1::ns2::const1] => value ) Previous Comments: ---- [2008-10-15 15:36:32] kenashkov at gmail dot com changed summary ---- [2008-10-15 15:33:34] kenashkov at gmail dot com I had a quick look again over the docs and nowhere is documented that the namespaces are case insensitive. I think this should go in the docs, as well if this issue with define() wont be fixed, to be documented too. ---- [2008-10-15 15:29:42] kenashkov at gmail dot com Description: The current implementatino of namespaces is case INSENSITIVE. But defining a constant using define and having capitals in the namespace makes the defined constant unreachable. We can verify this using get_defined_constants(). In case a constant was defined like: we can see the the defined constant/namespace is in fact: ns1::ns2::const1; But if the constant was defined using define(), it is kept with the capitalization: get_defined_constants() gives NS1::ns2::const1. But because the namespaces are case insensitive the call: resolves in fact to ns1::ns2::const1 which is undefined. Reproduce code: --- Expected result: value Actual result: -- Fatal error: Class 'NS1::ns2' not found in /home/local/tests/t35.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=46304&edit=1
#46304 [Opn]: define() namespaced constant is case sensitive
ID: 46304 User updated by: kenashkov at gmail dot com Reported By: kenashkov at gmail dot com Status: Open Bug Type: Scripting Engine problem Operating System: GNU/Linux debian lenny PHP Version: 5.3CVS-2008-10-15 (snap) New Comment: I had a quick look again over the docs and nowhere is documented that the namespaces are case insensitive. I think this should go in the docs, as well if this issue with define() wont be fixed, to be documented too. Previous Comments: [2008-10-15 15:29:42] kenashkov at gmail dot com Description: The current implementatino of namespaces is case INSENSITIVE. But defining a constant using define and having capitals in the namespace makes the defined constant unreachable. We can verify this using get_defined_constants(). In case a constant was defined like: we can see the the defined constant/namespace is in fact: ns1::ns2::const1; But if the constant was defined using define(), it is kept with the capitalization: get_defined_constants() gives NS1::ns2::const1. But because the namespaces are case insensitive the call: resolves in fact to ns1::ns2::const1 which is undefined. Reproduce code: --- Expected result: value Actual result: -- Fatal error: Class 'NS1::ns2' not found in /home/local/tests/t35.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=46304&edit=1
#35479 [NEW]: garbage_collector calling sequence
From: kenashkov at gmail dot com
Operating system: Fedora Core 4
PHP version: 4.4.1
PHP Bug Type: Session related
Bug description: garbage_collector calling sequence
Description:
Let suppose that we use the session_set_save_handler to register own
session handling functions and we have an expired session (but not cleaned
by the garbage collector yet). When we start the session with
session_start() we get the following sequence of calling the registered
functions:
open
read
gc
write
close
I think the garbage collector (gc) should be called BEFORE the read
function (in order to clean that expired session beofre it is read). In
the way it is, is possible for the web site visitor to use an old session
(only once of course, because immediately after read is called gc and for
the second visit the session will be already deleted).
Maybe the same problem exists when is not used the
session_set_save_handler, but with it the sequence can be seen.
Reproduce code:
---
'.PHP_EOL; return true; }
function close() { print 'close'.PHP_EOL; return true; }
function read() { print 'read'.PHP_EOL; return ''; }
function write() { print 'write'.PHP_EOL; return true; }
function destroy() { print 'destroy'.PHP_EOL; return true; }
function gc() { print 'gc'.PHP_EOL; return true; }
ini_set('session.gc_probability',1);
ini_set('session.gc_divisor',1);
session_set_save_handler('open','close','read','write','destroy','gc');
session_start();
session_write_close();
?>
Expected result:
open
gc
read
write
close
Actual result:
--
open
read
gc
write
close
--
Edit bug report at http://bugs.php.net/?id=35479&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35479&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35479&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35479&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35479&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35479&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35479&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35479&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35479&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35479&r=support
Expected behavior: http://bugs.php.net/fix.php?id=35479&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35479&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35479&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35479&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35479&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35479&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35479&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35479&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35479&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35479&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35479&r=mysqlcfg
#35488 [NEW]: serialize() segmentation fault
From: kenashkov at gmail dot com Operating system: Fedora Core 4 PHP version: 4.4.1 PHP Bug Type: Unknown/Other Function Bug description: serialize() segmentation fault Description: Segmentation fault when serializing multidimentional recursive arrays. The code below works fine with 4.3.11 (again on FC4). When the argument is passend by reference (which is deprecated): print_r(unserialize(serialize(&$arr1))); it is fine. Or passing a reference: print_r(unserialize(serialize($ref=&$arr1))); also works. No problem with serializing just $arr1[0]=&$arr; Reproduce code: --- Expected result: Array ( [0] => Array ( [0] => Array ( [0] => Array ( [0] => Array *RECURSION* ) ) ) ) Actual result: -- Segmentation fault -- Edit bug report at http://bugs.php.net/?id=35488&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35488&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35488&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35488&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35488&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35488&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35488&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35488&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35488&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35488&r=support Expected behavior:http://bugs.php.net/fix.php?id=35488&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35488&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35488&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35488&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35488&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35488&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35488&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35488&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35488&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35488&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35488&r=mysqlcfg
#35488 [Bgs->Opn]: serialize() segmentation fault
ID: 35488 User updated by: kenashkov at gmail dot com Reported By: kenashkov at gmail dot com -Status: Bogus +Status: Open Bug Type: *General Issues Operating System: Fedora Core 4 PHP Version: 4.4.1 New Comment: Quote from the docs of the function serialize(): "You can even serialize() arrays that contain references to itself. References inside the array/object you are serialize()ing will also be stored." Previous Comments: [2005-11-30 14:03:31] [EMAIL PROTECTED] Don't use references with serialize(). [2005-11-30 13:58:20] kenashkov at gmail dot com Description: Segmentation fault when serializing multidimentional recursive arrays. The code below works fine with 4.3.11 (again on FC4). When the argument is passend by reference (which is deprecated): print_r(unserialize(serialize(&$arr1))); it is fine. Or passing a reference: print_r(unserialize(serialize($ref=&$arr1))); also works. No problem with serializing just $arr1[0]=&$arr; Reproduce code: --- Expected result: Array ( [0] => Array ( [0] => Array ( [0] => Array ( [0] => Array *RECURSION* ) ) ) ) Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=35488&edit=1
#35479 [WFx]: garbage_collector calling sequence
ID: 35479
User updated by: kenashkov at gmail dot com
Reported By: kenashkov at gmail dot com
Status: Wont fix
Bug Type: Session related
Operating System: Fedora Core 4
PHP Version: 4.4.1
New Comment:
I think this can be a major security risk if the garbage collection
rule is based not on the session begin time, but on a inactivity time
(i.e. 1 hour since last read). Thus when long time there is no any
execution of the code (from other users/sessions) is possible a visitor
to use an abandoned session (i.e. not closed window on some computer)
and execute the page. Then the read function is called, it updates the
last activity time, and the gc will not delete the session, because it
is already updated. A work around is to update the last activity time
in the write function (which is AFTER the gc) but this way remains the
possibility to execute at least once an abandoned session.
And is that the order of calling of the internal functions when is used
the default handler? If it is I think it is important not to leave this
as is.
Maybe is possible to add php.ini directive that allows switching the
calling order. Something like "change_session_call_order" On/Off
PHP_INI_ALL. This way if there is no compatibility issues, one can turn
it On to get the proposed calling order. I know that there is already a
lot of session directives, but this is better than nothing.
Previous Comments:
[2005-11-29 22:55:29] [EMAIL PROTECTED]
It's fine as it is. Changing this now would break backwards
compatibility.
[2005-11-29 18:15:55] kenashkov at gmail dot com
Description:
Let suppose that we use the session_set_save_handler to register own
session handling functions and we have an expired session (but not
cleaned by the garbage collector yet). When we start the session with
session_start() we get the following sequence of calling the registered
functions:
open
read
gc
write
close
I think the garbage collector (gc) should be called BEFORE the read
function (in order to clean that expired session beofre it is read). In
the way it is, is possible for the web site visitor to use an old
session (only once of course, because immediately after read is called
gc and for the second visit the session will be already deleted).
Maybe the same problem exists when is not used the
session_set_save_handler, but with it the sequence can be seen.
Reproduce code:
---
'.PHP_EOL; return true; }
function close() { print 'close'.PHP_EOL; return true; }
function read() { print 'read'.PHP_EOL; return ''; }
function write() { print 'write'.PHP_EOL; return true; }
function destroy() { print 'destroy'.PHP_EOL; return true; }
function gc() { print 'gc'.PHP_EOL; return true; }
ini_set('session.gc_probability',1);
ini_set('session.gc_divisor',1);
session_set_save_handler('open','close','read','write','destroy','gc');
session_start();
session_write_close();
?>
Expected result:
open
gc
read
write
close
Actual result:
--
open
read
gc
write
close
--
Edit this bug report at http://bugs.php.net/?id=35479&edit=1
#41662 [Fbk->Opn]: SimpleXML->children() misleading result
ID: 41662 User updated by: kenashkov at gmail dot com Reported By: kenashkov at gmail dot com -Status: Feedback +Status: Open Bug Type: SimpleXML related Operating System: Fedora Core 4 -PHP Version: 5.2.3 +PHP Version: 5.2.4RC3-dev New Comment: Still the same result with 5.2.4RC3-dev. Previous Comments: [2007-08-17 13:38:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-08-17 02:37:22] [EMAIL PROTECTED] There's no reason why a node without subnode should return anything in its children(). Especially if there is attributes() method returning attributes. Please fix the sources. [2007-06-12 07:36:50] kenashkov at gmail dot com Description: Testing an SimpleXMLElement object for children is unconsistent. Here is an example: $str = ''; $x = new SimpleXMLElement($str); if($x->subnode->children()) print 'yes'; else print 'no'; - will print 'no'; If the $str=''; it will print yes. But the same will happen if the subnode has an attribute like: $str = ''; But if we use foreach($x->subnode->children() as $key=>$value) in the latter example we will not get anything (which is correct). I think is wrong the children() method to return object when there are no child objects and the node has attributes (because for querying the attributes we have the attributes() method). This was discussed in php-dev list - http://marc.info/?l=php-dev&m=118001203709813&w=2 If this is not a bug, I think a note regarding this behaviour must be added in the docs. Reproduce code: --- $str = ''; $x = new SimpleXMLElement($str); if($x->subnode->children()) print 'yes'; else print 'no'; Expected result: no Actual result: -- yes -- Edit this bug report at http://bugs.php.net/?id=41662&edit=1
#37440 [NEW]: Problem assigning multiple objects with XML parser within them to one variable
From: kenashkov at gmail dot com
Operating system: Fedora Core 4
PHP version: 4.4.2
PHP Bug Type: XML related
Bug description: Problem assigning multiple objects with XML parser within
them to one variable
Description:
When assigning multiple times to ane variable an object which contains a
XML parser, there is a problem when the xml_parse is called. The parser
can not call the registered handlers.
The problem can be avoided if the variable is unset before the second
call, or using $doc1 =& new xml_doc() for every assignment.
Reproduce code:
---
res = xml_parser_create_ns();
xml_set_object($this->res,$this);
xml_set_element_handler($this->res,'start_element','end_element');
}
function load_string($string)
{
xml_parse($this->res,$string);
}
function start_element()
{
}
function end_element()
{
}
}
$str = '';
$doc1 = new xml_doc();
$doc1->load_string($str);
//unset($doc1);//this solves the problem
//or using $doc1 =& new xml_doc(); in every assignment
$doc1 = new xml_doc();
$doc1->load_string($str);
?>
Expected result:
Nothing really... it is too simple to do real parsing.
Actual result:
--
Warning: xml_parse() [function.xml-parse.html]: Unable to call handler
start_element() in file.php on line 13
Warning: xml_parse() [function.xml-parse.html]: Unable to call handler
end_element() in file.php on line 13
--
Edit bug report at http://bugs.php.net/?id=37440&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37440&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37440&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37440&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37440&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37440&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37440&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37440&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37440&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37440&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37440&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37440&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37440&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37440&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37440&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37440&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37440&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37440&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37440&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37440&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37440&r=mysqlcfg
#37440 [Bgs->Opn]: Problem assigning multiple objects with XML parser within them to one variable
ID: 37440
User updated by: kenashkov at gmail dot com
Reported By: kenashkov at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: XML related
Operating System: Fedora Core 4
PHP Version: 4.4.2
New Comment:
No - it is not. I have a full working example class - the same result.
The inexpected here is that the parser can not call the registered
methods. Obviuosly I do not expect to work - the source is scaled down
to the bare minimum that reproduces the case.
Previous Comments:
[2006-05-14 20:29:16] [EMAIL PROTECTED]
This is expected since your handlers do not return anything.
[2006-05-14 20:11:51] kenashkov at gmail dot com
Description:
When assigning multiple times to ane variable an object which contains
a XML parser, there is a problem when the xml_parse is called. The
parser can not call the registered handlers.
The problem can be avoided if the variable is unset before the second
call, or using $doc1 =& new xml_doc() for every assignment.
Reproduce code:
---
res = xml_parser_create_ns();
xml_set_object($this->res,$this);
xml_set_element_handler($this->res,'start_element','end_element');
}
function load_string($string)
{
xml_parse($this->res,$string);
}
function start_element()
{
}
function end_element()
{
}
}
$str = '';
$doc1 = new xml_doc();
$doc1->load_string($str);
//unset($doc1);//this solves the problem
//or using $doc1 =& new xml_doc(); in every assignment
$doc1 = new xml_doc();
$doc1->load_string($str);
?>
Expected result:
Nothing really... it is too simple to do real parsing.
Actual result:
--
Warning: xml_parse() [function.xml-parse.html]: Unable to call handler
start_element() in file.php on line 13
Warning: xml_parse() [function.xml-parse.html]: Unable to call handler
end_element() in file.php on line 13
--
Edit this bug report at http://bugs.php.net/?id=37440&edit=1
#37440 [Fbk->Opn]: Problem assigning multiple objects with XML parser within them to one variable
ID: 37440
User updated by: kenashkov at gmail dot com
Reported By: kenashkov at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: XML related
Operating System: Fedora Core 4
PHP Version: 4.4.2
New Comment:
This can be reproduced useing the example from xml_set_object()
function reference found here:
http://www.php.net/manual/en/function.xml-set-object.php
Here is the exact reproduce code:
-
parser = xml_parser_create();
xml_set_object($this->parser, $this);
xml_set_element_handler($this->parser, "tag_open",
"tag_close");
xml_set_character_data_handler($this->parser, "cdata");
}
function parse($data)
{
xml_parse($this->parser, $data);
}
function tag_open($parser, $tag, $attributes)
{
var_dump($parser, $tag, $attributes);
}
function cdata($parser, $cdata)
{
var_dump($parser, $cdata);
}
function tag_close($parser, $tag)
{
var_dump($parser, $tag);
}
} // end of class xml
$xml_parser = new xml();
$xml_parser->parse("PHP");
$xml_parser = new xml();
$xml_parser->parse("PHP");
?>
-
The only modification in comparison with the given example in the
manual is the second assignment of $xml_parser to a new object.
The result is:
-
resource(2) of type (xml) string(1) "A" array(1) { ["ID"]=> string(5)
"hallo" } resource(2) of type (xml) string(3) "PHP" resource(2) of type
(xml) string(1) "A"
Warning: xml_parse() [function.xml-parse.html]: Unable to call handler
tag_open() in /home/local/dev.kenashkov.com/XPATS/bug_test/t4.php on
line 16
Warning: xml_parse() [function.xml-parse.html]: Unable to call handler
cdata() in /home/local/dev.kenashkov.com/XPATS/bug_test/t4.php on line
16
Warning: xml_parse() [function.xml-parse.html]: Unable to call handler
tag_close() in /home/local/dev.kenashkov.com/XPATS/bug_test/t4.php on
line 16
-
It works as expected in PHP 5.1.4
The code produces the bug in PHP 4.4.2 with the following cofigure
line:
-
'./configure' '--prefix=/web/php4.4.2'
'--with-apxs2=/web/apache2-php4/bin/apxs' '--enable-bcmath=shared'
'--with-bz2=shared' '--enable-calendar=shared' '--enable-ctype=shared'
'--with-curl=shared' '--enable-dba=shared' '--enable-dbase=shared'
'--enable-dbx=shared' '--enable-dio=shared' '--with-dom=shared'
'--with-dom-xsl=shared' '--with-dom-xslt=shared'
'--with-dom-exslt=shared' '--enable-exif=shared' '--with-fam=shared'
'--enable-ftp=shared' '--with-gettext=shared' '--with-gmp=shared'
'--with-iconv=shared' '--with-gd=shared' '--with-jpeg-dir'
'--with-png-dir' '--with-xpm-dir' '--with-ttf' '--with-freetype-dir'
'--enable-gd-native-ttf' '--with-ldap=shared' '--enable-mbstring=all'
'--enable-mbstr-enc-trans' '--enable-mbregex'
'--with-mime-magic=shared'
'--with-mysql=/web/mysql-max-5.0.15-linux-i686-glibc23'
'--with-ncurses=shared' '--with-openssl=shared'
'--enable-overload=shared' '--enable-pcntl=shared'
'--with-pgsql=shared' '--with-regex' '--enable-maintainer-zts'
'--enable-sysvsem=shared' '--enable-sysvshm=shared'
'--enable-sysvmsg=shared' '--enable-shmop=shared'
'--enable-sockets=shared' '--enable-memory-limit'
'--enable-wddx=shared' '--with-zlib=shared' '--with-mhash=shared'
'--with-mcrypt=shared' '--enable-xslt=shared' '--with-xslt-sablot'
'--with-mssql=shared' '--with-kerberos=shared' '--enable-yp'
'--enable-fastcgi' '--with-oci8=/u01/app/oracle/product/10.1.0/Db_1'
-------------
Previous Comments:
[2006-07-22 13:00:05] [EMAIL PROTECTED]
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.
[2
#41662 [NEW]: SimpleXML->children() misleading result
From: kenashkov at gmail dot com Operating system: Fedora Core 4 PHP version: 5.2.3 PHP Bug Type: SimpleXML related Bug description: SimpleXML->children() misleading result Description: Testing an SimpleXMLElement object for children is unconsistent. Here is an example: $str = ''; $x = new SimpleXMLElement($str); if($x->subnode->children()) print 'yes'; else print 'no'; - will print 'no'; If the $str=''; it will print yes. But the same will happen if the subnode has an attribute like: $str = ''; But if we use foreach($x->subnode->children() as $key=>$value) in the latter example we will not get anything (which is correct). I think is wrong the children() method to return object when there are no child objects and the node has attributes (because for querying the attributes we have the attributes() method). This was discussed in php-dev list - http://marc.info/?l=php-dev&m=118001203709813&w=2 If this is not a bug, I think a note regarding this behaviour must be added in the docs. Reproduce code: --- $str = ''; $x = new SimpleXMLElement($str); if($x->subnode->children()) print 'yes'; else print 'no'; Expected result: no Actual result: -- yes -- Edit bug report at http://bugs.php.net/?id=41662&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41662&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41662&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41662&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41662&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41662&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41662&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41662&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41662&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41662&r=support Expected behavior:http://bugs.php.net/fix.php?id=41662&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41662&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41662&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41662&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41662&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41662&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41662&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41662&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41662&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41662&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41662&r=mysqlcfg
#41663 [NEW]: Xpath evaluation in SimpleXMLElement
From: kenashkov at gmail dot com
Operating system: Fedora Core 4
PHP version: 5.2.3
PHP Bug Type: SimpleXML related
Bug description: Xpath evaluation in SimpleXMLElement
Description:
The evaluation of the Xpath expressions is not relative to the node
against which they are called ([2]). Worse - even after cloning a node from
the structure and evaluating the xpath, the xpath expression seems to be
evaluated against the original structure, not against the new one (which is
a copy of a part of the original) ([3]).
This was discussed in the dev-list here:
http://marc.info/?l=php-dev&m=118001203709813&w=2
If this is not a bug, but expected result, I think a note addressing this
behaviour must be added in the docs.
Reproduce code:
---
$str =
'';
$x = new SimpleXMLElement($str);
//[1]
$r1 = $x->xpath('/*');
print $r1[0]->getName().' ';
//[2]
$r2 = $x->level1_node1[0]->xpath('/*');
print $r2[0]->getName().' ';
//[3]
$z = clone $x->level1_node1[0];
$r3 = $z->xpath('/*');
print $r3[0]->getName().' ';
Expected result:
rootnode level1_node1 level1_node1
Actual result:
--
rootnode rootnode rootnode
--
Edit bug report at http://bugs.php.net/?id=41663&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41663&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41663&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41663&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41663&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41663&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41663&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41663&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41663&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41663&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41663&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41663&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41663&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41663&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41663&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41663&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41663&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41663&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41663&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41663&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41663&r=mysqlcfg
#41663 [Bgs]: Xpath evaluation in SimpleXMLElement
ID: 41663
User updated by: kenashkov at gmail dot com
Reported By: kenashkov at gmail dot com
Status: Bogus
Bug Type: SimpleXML related
Operating System: Fedora Core 4
PHP Version: 5.2.3
New Comment:
Yes - I use absolute expression. But at least in the last example [3]:
$z = clone $x->level1_node1[0];
$r3 = $z->xpath('/*');
print $r3[0]->getName().' ';
I use the $z object - not the x. And the $z object does not has any
node called rootnode. The expression is again evaluated against the $x
structure, not the $z.
This could be a problem in the case:
$z = clone $x->level1_node1[0];
function do_something($z)
{
$z->xpath('/*');//some absolute expression
}
Where the function do_something is totally unaware of the existance of
the $x var. If this is still expected then how one can evaluate an
absolute xpath expression inside the do_something function, as it will
always do it for the $x structure, not the locally available $z
structure.
I think at least this must be documented and a workaround must be
provide in the docs.
Previous Comments:
[2007-06-12 12:44:16] [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
The results are exactly what you requested based on your XPath
expression. You used absolute paths not relative:
http://www.w3.org/TR/xpath#location-paths
------------
[2007-06-12 08:10:55] kenashkov at gmail dot com
Description:
The evaluation of the Xpath expressions is not relative to the node
against which they are called ([2]). Worse - even after cloning a node
from the structure and evaluating the xpath, the xpath expression seems
to be evaluated against the original structure, not against the new one
(which is a copy of a part of the original) ([3]).
This was discussed in the dev-list here:
http://marc.info/?l=php-dev&m=118001203709813&w=2
If this is not a bug, but expected result, I think a note addressing
this behaviour must be added in the docs.
Reproduce code:
---
$str =
'';
$x = new SimpleXMLElement($str);
//[1]
$r1 = $x->xpath('/*');
print $r1[0]->getName().' ';
//[2]
$r2 = $x->level1_node1[0]->xpath('/*');
print $r2[0]->getName().' ';
//[3]
$z = clone $x->level1_node1[0];
$r3 = $z->xpath('/*');
print $r3[0]->getName().' ';
Expected result:
rootnode level1_node1 level1_node1
Actual result:
--
rootnode rootnode rootnode
--
Edit this bug report at http://bugs.php.net/?id=41663&edit=1
#41663 [Bgs]: Xpath evaluation in SimpleXMLElement
ID: 41663
User updated by: kenashkov at gmail dot com
Reported By: kenashkov at gmail dot com
Status: Bogus
Bug Type: SimpleXML related
Operating System: Fedora Core 4
PHP Version: 5.2.3
New Comment:
Yes, I experienced strange behaviour with the relative path (exactly in
a function - like the example I gave) and this is why I gave now the
example with absolute path.
I just expected clone to get the node out of the structure.
Case closed.
Previous Comments:
[2007-06-12 13:08:00] [EMAIL PROTECTED]
Still incorrect:
The cloned node is still part of the document (just not linked in).
Using / causes expression to be evaluated against the document.
/* will select the top level element in the same document as the
context node
Use ./ to evaluate against and in scope of context node
Note: There was a bug in earlier versions of SimpleXML (pre 5.2 I
believe) where the relative path didn't work correctly against the
context.
[2007-06-12 12:50:48] kenashkov at gmail dot com
Yes - I use absolute expression. But at least in the last example [3]:
$z = clone $x->level1_node1[0];
$r3 = $z->xpath('/*');
print $r3[0]->getName().' ';
I use the $z object - not the x. And the $z object does not has any
node called rootnode. The expression is again evaluated against the $x
structure, not the $z.
This could be a problem in the case:
$z = clone $x->level1_node1[0];
function do_something($z)
{
$z->xpath('/*');//some absolute expression
}
Where the function do_something is totally unaware of the existance of
the $x var. If this is still expected then how one can evaluate an
absolute xpath expression inside the do_something function, as it will
always do it for the $x structure, not the locally available $z
structure.
I think at least this must be documented and a workaround must be
provide in the docs.
[2007-06-12 12:44:16] [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
The results are exactly what you requested based on your XPath
expression. You used absolute paths not relative:
http://www.w3.org/TR/xpath#location-paths
----------------
[2007-06-12 08:10:55] kenashkov at gmail dot com
Description:
The evaluation of the Xpath expressions is not relative to the node
against which they are called ([2]). Worse - even after cloning a node
from the structure and evaluating the xpath, the xpath expression seems
to be evaluated against the original structure, not against the new one
(which is a copy of a part of the original) ([3]).
This was discussed in the dev-list here:
http://marc.info/?l=php-dev&m=118001203709813&w=2
If this is not a bug, but expected result, I think a note addressing
this behaviour must be added in the docs.
Reproduce code:
---
$str =
'';
$x = new SimpleXMLElement($str);
//[1]
$r1 = $x->xpath('/*');
print $r1[0]->getName().' ';
//[2]
$r2 = $x->level1_node1[0]->xpath('/*');
print $r2[0]->getName().' ';
//[3]
$z = clone $x->level1_node1[0];
$r3 = $z->xpath('/*');
print $r3[0]->getName().' ';
Expected result:
rootnode level1_node1 level1_node1
Actual result:
--
rootnode rootnode rootnode
--
Edit this bug report at http://bugs.php.net/?id=41663&edit=1
