#44589 [Com]: pdo_oci crashes and aborts php script for LOB columns

2009-08-31 Thread kenashkov at gmail dot com
 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

2009-11-11 Thread kenashkov at gmail dot com
 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

2008-10-15 Thread kenashkov at gmail dot com
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

2008-10-15 Thread kenashkov at gmail dot com
 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

2008-10-15 Thread kenashkov at gmail dot com
 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

2008-10-15 Thread kenashkov at gmail dot com
 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

2005-11-29 Thread kenashkov at gmail dot com
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

2005-11-30 Thread kenashkov at gmail dot com
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

2005-11-30 Thread kenashkov at gmail dot com
 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

2005-11-30 Thread kenashkov at gmail dot com
 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

2007-08-19 Thread kenashkov at gmail dot com
 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

2006-05-14 Thread kenashkov at gmail dot com
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

2006-05-14 Thread kenashkov at gmail dot com
 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

2006-07-22 Thread kenashkov at gmail dot com
 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

2007-06-12 Thread kenashkov at gmail dot com
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

2007-06-12 Thread kenashkov at gmail dot com
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

2007-06-12 Thread kenashkov at gmail dot com
 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

2007-06-12 Thread kenashkov at gmail dot com
 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