#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