#38478 [NEW]: reset() does not work as expected on Iterator implementations

[[EMAIL PROTECTED]]

From: [EMAIL PROTECTED]
Operating system: Gentoo
PHP version:  5.2.0RC1
PHP Bug Type: SPL related
Bug description:  reset() does not work as expected on Iterator implementations

Description:

The Iterator interface (SPL) defines a method rewind(). When implementing
e.g. ArrayIterator to allow array access to an object, one would expect
that reset($object) would use the rewind method. This does not happen, but
the first property is returned.

Reproduce code:
---
?php

class testArray implements Iterator
{
protected $prop = array(
1 = 'one',
2 = 'two',
3 = 'three',
);

public function rewind()
{
return reset( $this-prop );
}

public function key()
{
return key( $this-prop );
}

public function current()
{
return current( $this-prop );
}

public function next()
{
return next( $this-prop );
}

public function valid()
{
return ( current( $this-prop ) !== false );
}
}

$array = new testArray();

Expected result:

// Expected: string(3) one
var_dump( $array-rewind() );

// Expected: string(3) one
var_dump( reset( $array ) );


Actual result:
--
// As expected: string(3) one
var_dump( $array-rewind() );

// Expected: string(3) one
var_dump( reset( $array ) );
/* Got:
array(3) {
  [1]=
  string(3) one
  [2]=
  string(3) two
  [3]=
  string(5) three
}
*/

-- 
Edit bug report at http://bugs.php.net/?id=38478edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=38478r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=38478r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=38478r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38478r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=38478r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=38478r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38478r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38478r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=38478r=support
Expected behavior:http://bugs.php.net/fix.php?id=38478r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=38478r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=38478r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38478r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=38478r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38478r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38478r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=38478r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=38478r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=38478r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38478r=mysqlcfg

#38479 [NEW]: php5_pcre port can not be compiled

[subscriber at osk dot com dot ua]

From: subscriber at osk dot com dot ua
Operating system: FreeBSD 6.0  6.1
PHP version:  5.1.4
PHP Bug Type: Compile Failure
Bug description:  php5_pcre port can not be compiled

Description:

php_pcre.c fails compilation


Actual result:
--
/usr/ports/devel/php5-pcre/work/php-5.1.4/ext/pcre/php_pcre.c:1630: error:
`fifth_arg_force_ref' undeclared here (not in a function)

/usr/ports/devel/php5-pcre/work/php-5.1.4/ext/pcre/php_pcre.c:1630: error:
initializer element is not constant

/usr/ports/devel/php5-pcre/work/php-5.1.4/ext/pcre/php_pcre.c:1630: error:
(near initialization for `pcre_functions[2].arg_info')
.

-- 
Edit bug report at http://bugs.php.net/?id=38479edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=38479r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=38479r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=38479r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38479r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=38479r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=38479r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38479r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38479r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=38479r=support
Expected behavior:http://bugs.php.net/fix.php?id=38479r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=38479r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=38479r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38479r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=38479r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38479r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38479r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=38479r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=38479r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=38479r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38479r=mysqlcfg

#38479 [Opn-Bgs]: php5_pcre port can not be compiled

[tony2001]

 ID:   38479
 Updated by:   [EMAIL PROTECTED]
 Reported By:  subscriber at osk dot com dot ua
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: FreeBSD 6.0  6.1
 PHP Version:  5.1.4
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

Please report that to FreeBSD.


Previous Comments:


[2006-08-17 08:50:26] subscriber at osk dot com dot ua

Description:

php_pcre.c fails compilation


Actual result:
--
/usr/ports/devel/php5-pcre/work/php-5.1.4/ext/pcre/php_pcre.c:1630:
error: `fifth_arg_force_ref' undeclared here (not in a function)

/usr/ports/devel/php5-pcre/work/php-5.1.4/ext/pcre/php_pcre.c:1630:
error: initializer element is not constant

/usr/ports/devel/php5-pcre/work/php-5.1.4/ext/pcre/php_pcre.c:1630:
error: (near initialization for `pcre_functions[2].arg_info')
.





-- 
Edit this bug report at http://bugs.php.net/?id=38479edit=1

#38475 [Bgs]: mysql_error doesn't reset after mysql_* func call

[mirya at matrix dot ua]

 ID:   38475
 User updated by:  mirya at matrix dot ua
 Reported By:  mirya at matrix dot ua
 Status:   Bogus
 Bug Type: MySQL related
 Operating System: FreeBSD6.1
 PHP Version:  5.1.4
 New Comment:

I recently found it being mentioned in mysql C API docs (for
mysql_fetch_row()), IMHO there should be a note in PHP docs too.

2 [EMAIL PROTECTED]: ensure you have mysql5 and no test.a, test.b tables
;)


Previous Comments:


[2006-08-17 05:46:39] [EMAIL PROTECTED]

see http://bugs.mysql.com/bug.php?id=706



[2006-08-16 23:20:43] [EMAIL PROTECTED]

Can't replicate.
Please provide reproduce code that really works.



[2006-08-16 18:03:49] mirya at matrix dot ua

Description:

Extract from mysql_error() php doc page:

Note that this function only returns the error text from the most
recently executed MySQL function (not including mysql_error() and
mysql_errno())...

I noticed that a error is not reset for mysql_fetch_*() call
(server/client 5.0.22), mean if you perform mysql_query() for some data
manipulation statement producing a error, then call mysql_fetch_*(),
mysql_error() will return mysql_query() error message.

So the docs page is inconsistent with current mysql lib behaviour

Reproduce code:
---
mysql_connect('localhost', 'mirya', 'my-passwd');
mysql_select_db('test');
mysql_query('CREATE TABLE a (a INT AUTO_INCREMENT PRIMARY KEY) ENGINE =
InnoDB');
mysql_query('CREATE TABLE b (b INT AUTO_INCREMENT PRIMARY KEY, a INT
NOT NULL, FOREIGN KEY (a) REFERENCES a(a) ON DELETE REST
mysql_query('INSERT a VALUES (1), (2), (3)');
$rs = mysql_query('SELECT a FROM a');
while ($row = mysql_fetch_assoc($rs)) {
if (mysql_error()) die('Shouldn\'t happen: '.mysql_error());
mysql_query('INSERT b (a) VALUES (4)');
if (mysql_error()) echo Foreign key constraint fails\n;
}
echo Finished w/o errors\n;

Expected result:

Foreign key constraint fails
Finished w/o errors

Actual result:
--
Foreign key constraint fails
Shouldn't happen: Cannot add or update a child row: a foreign key
constraint fails (`test/b`, CONSTRAINT `b_ibfk_1` FOREIGN KEY (`a`)
REFERENCES `a` (`a`))





-- 
Edit this bug report at http://bugs.php.net/?id=38475edit=1

#38134 [Com]: segfault while calling xslt_process

[gabriel dot zerbib at protilab dot com]

 ID:   38134
 Comment by:   gabriel dot zerbib at protilab dot com
 Reported By:  gerome dot fournier at infomaniak dot ch
 Status:   No Feedback
 Bug Type: XSLT related
 Operating System: Debian Sarge
 PHP Version:  4.4.2
 New Comment:

TEST DATA:

The files can be found at:
http://www.protilab.com/test/sample.xml
http://www.protilab.com/test/sample.xsl

And the PHP script can be run online at:
http://www.protilab.com/test/sample.php


SCENARIO:
An XSLT processor is instanciated using the XML and XSL files specified
in the arguments, in a loop of 100 iterations.
Among these 100 iterations, a seg-fault is likely to happen.



XML file to process (sample.xml):
---
?xml version=1.0 encoding=iso-8859-1?
?xml-stylesheet type=text/xsl href=sample.xsl?

root
node1 id=foo
subnodeASome Data A/subnodeA
subnodeA attr=123Some Mode Data A/subnodeA
/node1
node1 id=bar
subnodeASome Data A in another node/subnodeA
subnodeA attr=345Some Mode Data in second node/subnodeA
/node1
/root
---


XSL file to apply (sample.xsl):
---
?xml version=1.0 encoding=iso-8859-1?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;

xsl:template match=/
html
head
titleTitle here/title
/head

body
xsl:for-each select=/root/node1
xsl:value-of select=@id/
ul
xsl:for-each select=subnodeA
lixsl:value-of 
select=text()/ xsl:if test=@attr (
xsl:value-of select=@attr/ ) /xsl:if /li 
/xsl:for-each
/ul
/xsl:for-each
/body 
/html
/xsl:template

/xsl:stylesheet
---


PHP script (sample.php)
---
?
$xmlFile = 'sample.xml';
$xsl_url = 'sample.xsl';


for($i = 0; $i  100; ++$i)
{

$xh = xslt_create();
xslt_set_encoding($xh, 'iso-8859-1');
xslt_process($xh, $xmlFile, $xsl_url, 'result.html');
xslt_free($xh);

echo(iteration: $i = OK br/\n);

}
?
---


Previous Comments:


[2006-07-26 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2006-07-18 14:49:08] gabriel dot zerbib at protilab dot com

The same test data (XML  XSL) in same context (same PHP application,
same version) work and do not fail on Windows XP  IIS, whereas I
experience the same problem on submitter's platform.



[2006-07-18 14:14:50] [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 ?php and ends 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.





[2006-07-18 13:52:27] gerome dot fournier at infomaniak dot ch

Description:

Making a simple xml transformation using xslt_process
gives from time to time a segfault. The  php code looks like this:

$xmlFile = file.xml;
$xsl_url = file.xsl;
$result = xslt_process($xh, $xmlFile, $xsl_url);
if ($result) {
echo $result;
} else {
echo Error;
}
xslt_free($xh);

I provide hereafter a backtrace after the segfault occured:

Program received signal SIGPIPE, Broken pipe.
[Switching to Thread -120974 (LWP 4068)]
0xb7f1f5e8 in writev () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7f1f5e8 in writev () from /lib/tls/libc.so.6
#1  0xb6db9cbf in ssl_io_hook_writev () from
/opt/apache/libexec/libssl.so
#2  0xbf886f40 in ?? ()
#3  0x0002 in ?? ()
#4  0x081228c4 in ?? ()
#5  0x in ?? ()
#6  0x0017 in ?? ()

#38134 [NoF-Opn]: segfault while calling xslt_process

[gerome dot fournier at infomaniak dot ch]

 ID:   38134
 User updated by:  gerome dot fournier at infomaniak dot ch
 Reported By:  gerome dot fournier at infomaniak dot ch
-Status:   No Feedback
+Status:   Open
 Bug Type: XSLT related
 Operating System: Debian Sarge
 PHP Version:  4.4.2
 New Comment:

Re-opened as the owner of the web site provided new feedbacks.


Previous Comments:


[2006-08-17 09:22:12] gabriel dot zerbib at protilab dot com

TEST DATA:

The files can be found at:
http://www.protilab.com/test/sample.xml
http://www.protilab.com/test/sample.xsl

And the PHP script can be run online at:
http://www.protilab.com/test/sample.php


SCENARIO:
An XSLT processor is instanciated using the XML and XSL files specified
in the arguments, in a loop of 100 iterations.
Among these 100 iterations, a seg-fault is likely to happen.



XML file to process (sample.xml):
---
?xml version=1.0 encoding=iso-8859-1?
?xml-stylesheet type=text/xsl href=sample.xsl?

root
node1 id=foo
subnodeASome Data A/subnodeA
subnodeA attr=123Some Mode Data A/subnodeA
/node1
node1 id=bar
subnodeASome Data A in another node/subnodeA
subnodeA attr=345Some Mode Data in second node/subnodeA
/node1
/root
---


XSL file to apply (sample.xsl):
---
?xml version=1.0 encoding=iso-8859-1?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;

xsl:template match=/
html
head
titleTitle here/title
/head

body
xsl:for-each select=/root/node1
xsl:value-of select=@id/
ul
xsl:for-each select=subnodeA
lixsl:value-of 
select=text()/ xsl:if test=@attr (
xsl:value-of select=@attr/ ) /xsl:if /li 
/xsl:for-each
/ul
/xsl:for-each
/body 
/html
/xsl:template

/xsl:stylesheet
---


PHP script (sample.php)
---
?
$xmlFile = 'sample.xml';
$xsl_url = 'sample.xsl';


for($i = 0; $i  100; ++$i)
{

$xh = xslt_create();
xslt_set_encoding($xh, 'iso-8859-1');
xslt_process($xh, $xmlFile, $xsl_url, 'result.html');
xslt_free($xh);

echo(iteration: $i = OK br/\n);

}
?
---



[2006-07-26 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2006-07-18 14:49:08] gabriel dot zerbib at protilab dot com

The same test data (XML  XSL) in same context (same PHP application,
same version) work and do not fail on Windows XP  IIS, whereas I
experience the same problem on submitter's platform.



[2006-07-18 14:14:50] [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 ?php and ends 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.





[2006-07-18 13:52:27] gerome dot fournier at infomaniak dot ch

Description:

Making a simple xml transformation using xslt_process
gives from time to time a segfault. The  php code looks like this:

$xmlFile = file.xml;
$xsl_url = file.xsl;
$result = xslt_process($xh, $xmlFile, $xsl_url);
if ($result) {
echo $result;
} else {
echo Error;
}
xslt_free($xh);

I provide hereafter a backtrace after the segfault occured:

Program received signal SIGPIPE, Broken pipe.
[Switching to Thread -120974 (LWP 4068)]
0xb7f1f5e8 in writev () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7f1f5e8 in 

#38480 [NEW]: Signal handling simply does not work!

[bh at ez dot no]

From: bh at ez dot no
Operating system: Debian Linux, Unstable
PHP version:  5.1.4
PHP Bug Type: PCNTL related
Bug description:  Signal handling simply does not work!

Description:

PHP5-CLI: pcntl_signal is malfunctioning. It traps the desidred
signal(s) but it does not execute the code which is in the custom signal
handler! This is very annoying.

Reproduce code:
---
?php

function whatever( $signal )
{
echo( Inside whatever, got $signal\n );
}

pcntl_signal( SIGTERM, 'whatever' );
pcntl_signal( SIGUSR1, 'whatever' );

echo( 'My PID is: ' . getmypid() . \n );

// Hard-sleep for 30 secs.
time_sleep_until( microtime( true ) + 30 );

echo( Bye.\n );

?


Expected result:

Start up the provided source code using PHP5-CLI, remember the PID that
the script outputs and use kill -15 PID to send a SIGTERM to it.

The script should trap the signal, execute the custom signal handler code
and thus output:

Inside whatever, got 15

However, this does not happen. Note that the signal is in fact CAUGHT,
because if you remove the handler for SIGTERM and then send a signal 15 to
the script, it will self-terminate.

Apparently none of the other signals work either (checked with SIGUSR1/2,
etc.).


-- 
Edit bug report at http://bugs.php.net/?id=38480edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=38480r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=38480r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=38480r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38480r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=38480r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=38480r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38480r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38480r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=38480r=support
Expected behavior:http://bugs.php.net/fix.php?id=38480r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=38480r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=38480r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38480r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=38480r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38480r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38480r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=38480r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=38480r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=38480r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38480r=mysqlcfg

#38134 [Opn-NoF]: segfault while calling xslt_process

[tony2001]

 ID:   38134
 Updated by:   [EMAIL PROTECTED]
 Reported By:  gerome dot fournier at infomaniak dot ch
-Status:   Open
+Status:   No Feedback
 Bug Type: XSLT related
 Operating System: Debian Sarge
 PHP Version:  4.4.2
 New Comment:

Can't reproduce.


Previous Comments:


[2006-08-17 09:42:11] gerome dot fournier at infomaniak dot ch

Re-opened as the owner of the web site provided new feedbacks.



[2006-08-17 09:22:12] gabriel dot zerbib at protilab dot com

TEST DATA:

The files can be found at:
http://www.protilab.com/test/sample.xml
http://www.protilab.com/test/sample.xsl

And the PHP script can be run online at:
http://www.protilab.com/test/sample.php


SCENARIO:
An XSLT processor is instanciated using the XML and XSL files specified
in the arguments, in a loop of 100 iterations.
Among these 100 iterations, a seg-fault is likely to happen.



XML file to process (sample.xml):
---
?xml version=1.0 encoding=iso-8859-1?
?xml-stylesheet type=text/xsl href=sample.xsl?

root
node1 id=foo
subnodeASome Data A/subnodeA
subnodeA attr=123Some Mode Data A/subnodeA
/node1
node1 id=bar
subnodeASome Data A in another node/subnodeA
subnodeA attr=345Some Mode Data in second node/subnodeA
/node1
/root
---


XSL file to apply (sample.xsl):
---
?xml version=1.0 encoding=iso-8859-1?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;

xsl:template match=/
html
head
titleTitle here/title
/head

body
xsl:for-each select=/root/node1
xsl:value-of select=@id/
ul
xsl:for-each select=subnodeA
lixsl:value-of 
select=text()/ xsl:if test=@attr (
xsl:value-of select=@attr/ ) /xsl:if /li 
/xsl:for-each
/ul
/xsl:for-each
/body 
/html
/xsl:template

/xsl:stylesheet
---


PHP script (sample.php)
---
?
$xmlFile = 'sample.xml';
$xsl_url = 'sample.xsl';


for($i = 0; $i  100; ++$i)
{

$xh = xslt_create();
xslt_set_encoding($xh, 'iso-8859-1');
xslt_process($xh, $xmlFile, $xsl_url, 'result.html');
xslt_free($xh);

echo(iteration: $i = OK br/\n);

}
?
---



[2006-07-26 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2006-07-18 14:49:08] gabriel dot zerbib at protilab dot com

The same test data (XML  XSL) in same context (same PHP application,
same version) work and do not fail on Windows XP  IIS, whereas I
experience the same problem on submitter's platform.



[2006-07-18 14:14:50] [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 ?php and ends 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.





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/38134

-- 
Edit this bug report at http://bugs.php.net/?id=38134edit=1

#38134 [Com]: segfault while calling xslt_process

[gabriel dot zerbib at protilab dot com]

 ID:   38134
 Comment by:   gabriel dot zerbib at protilab dot com
 Reported By:  gerome dot fournier at infomaniak dot ch
 Status:   Feedback
 Bug Type: XSLT related
 Operating System: Debian Sarge
 PHP Version:  4.4.2
 New Comment:

I'm sorry Tony, you were a little bit quick in closing with can't
reproduce.

You can just try the online demo. You'll manage to achieve the 100
iterations for some time, but if you hit Refresh a few times, you sure
will run into the problem: the page will not come to you, your browser
will report some proxy error or some Host not found error, which is
in fact caused by a violent crash of the PHP script and PHP
interpreter, never returning a response to your browser.

Please do not close this bug report too fast, as sample data were
properly provided, and the target platform and system and version.

Thanks.


Previous Comments:


[2006-08-17 09:43:05] [EMAIL PROTECTED]

Can't reproduce.



[2006-08-17 09:42:11] gerome dot fournier at infomaniak dot ch

Re-opened as the owner of the web site provided new feedbacks.



[2006-08-17 09:22:12] gabriel dot zerbib at protilab dot com

TEST DATA:

The files can be found at:
http://www.protilab.com/test/sample.xml
http://www.protilab.com/test/sample.xsl

And the PHP script can be run online at:
http://www.protilab.com/test/sample.php


SCENARIO:
An XSLT processor is instanciated using the XML and XSL files specified
in the arguments, in a loop of 100 iterations.
Among these 100 iterations, a seg-fault is likely to happen.



XML file to process (sample.xml):
---
?xml version=1.0 encoding=iso-8859-1?
?xml-stylesheet type=text/xsl href=sample.xsl?

root
node1 id=foo
subnodeASome Data A/subnodeA
subnodeA attr=123Some Mode Data A/subnodeA
/node1
node1 id=bar
subnodeASome Data A in another node/subnodeA
subnodeA attr=345Some Mode Data in second node/subnodeA
/node1
/root
---


XSL file to apply (sample.xsl):
---
?xml version=1.0 encoding=iso-8859-1?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;

xsl:template match=/
html
head
titleTitle here/title
/head

body
xsl:for-each select=/root/node1
xsl:value-of select=@id/
ul
xsl:for-each select=subnodeA
lixsl:value-of 
select=text()/ xsl:if test=@attr (
xsl:value-of select=@attr/ ) /xsl:if /li 
/xsl:for-each
/ul
/xsl:for-each
/body 
/html
/xsl:template

/xsl:stylesheet
---


PHP script (sample.php)
---
?
$xmlFile = 'sample.xml';
$xsl_url = 'sample.xsl';


for($i = 0; $i  100; ++$i)
{

$xh = xslt_create();
xslt_set_encoding($xh, 'iso-8859-1');
xslt_process($xh, $xmlFile, $xsl_url, 'result.html');
xslt_free($xh);

echo(iteration: $i = OK br/\n);

}
?
---



[2006-07-26 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2006-07-18 14:49:08] gabriel dot zerbib at protilab dot com

The same test data (XML  XSL) in same context (same PHP application,
same version) work and do not fail on Windows XP  IIS, whereas I
experience the same problem on submitter's platform.



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/38134

-- 
Edit this bug report at http://bugs.php.net/?id=38134edit=1

#38480 [Opn-Bgs]: Signal handling simply does not work!

[tony2001]

 ID:   38480
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bh at ez dot no
-Status:   Open
+Status:   Bogus
 Bug Type: PCNTL related
 Operating System: Debian Linux, Unstable
 PHP Version:  5.1.4
 New Comment:

Ticks are required since 4.3.0:
declare(ticks = 1);


Previous Comments:


[2006-08-17 09:42:20] bh at ez dot no

Description:

PHP5-CLI: pcntl_signal is malfunctioning. It traps the desidred
signal(s) but it does not execute the code which is in the custom
signal handler! This is very annoying.

Reproduce code:
---
?php

function whatever( $signal )
{
echo( Inside whatever, got $signal\n );
}

pcntl_signal( SIGTERM, 'whatever' );
pcntl_signal( SIGUSR1, 'whatever' );

echo( 'My PID is: ' . getmypid() . \n );

// Hard-sleep for 30 secs.
time_sleep_until( microtime( true ) + 30 );

echo( Bye.\n );

?


Expected result:

Start up the provided source code using PHP5-CLI, remember the PID that
the script outputs and use kill -15 PID to send a SIGTERM to it.

The script should trap the signal, execute the custom signal handler
code and thus output:

Inside whatever, got 15

However, this does not happen. Note that the signal is in fact CAUGHT,
because if you remove the handler for SIGTERM and then send a signal 15
to the script, it will self-terminate.

Apparently none of the other signals work either (checked with
SIGUSR1/2, etc.).






-- 
Edit this bug report at http://bugs.php.net/?id=38480edit=1

#38134 [NoF-Fbk]: segfault while calling xslt_process

[tony2001]

 ID:   38134
 Updated by:   [EMAIL PROTECTED]
 Reported By:  gerome dot fournier at infomaniak dot ch
-Status:   No Feedback
+Status:   Feedback
 Bug Type: XSLT related
 Operating System: Debian Sarge
 PHP Version:  4.4.2


Previous Comments:


[2006-08-17 09:43:05] [EMAIL PROTECTED]

Can't reproduce.



[2006-08-17 09:42:11] gerome dot fournier at infomaniak dot ch

Re-opened as the owner of the web site provided new feedbacks.



[2006-08-17 09:22:12] gabriel dot zerbib at protilab dot com

TEST DATA:

The files can be found at:
http://www.protilab.com/test/sample.xml
http://www.protilab.com/test/sample.xsl

And the PHP script can be run online at:
http://www.protilab.com/test/sample.php


SCENARIO:
An XSLT processor is instanciated using the XML and XSL files specified
in the arguments, in a loop of 100 iterations.
Among these 100 iterations, a seg-fault is likely to happen.



XML file to process (sample.xml):
---
?xml version=1.0 encoding=iso-8859-1?
?xml-stylesheet type=text/xsl href=sample.xsl?

root
node1 id=foo
subnodeASome Data A/subnodeA
subnodeA attr=123Some Mode Data A/subnodeA
/node1
node1 id=bar
subnodeASome Data A in another node/subnodeA
subnodeA attr=345Some Mode Data in second node/subnodeA
/node1
/root
---


XSL file to apply (sample.xsl):
---
?xml version=1.0 encoding=iso-8859-1?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;

xsl:template match=/
html
head
titleTitle here/title
/head

body
xsl:for-each select=/root/node1
xsl:value-of select=@id/
ul
xsl:for-each select=subnodeA
lixsl:value-of 
select=text()/ xsl:if test=@attr (
xsl:value-of select=@attr/ ) /xsl:if /li 
/xsl:for-each
/ul
/xsl:for-each
/body 
/html
/xsl:template

/xsl:stylesheet
---


PHP script (sample.php)
---
?
$xmlFile = 'sample.xml';
$xsl_url = 'sample.xsl';


for($i = 0; $i  100; ++$i)
{

$xh = xslt_create();
xslt_set_encoding($xh, 'iso-8859-1');
xslt_process($xh, $xmlFile, $xsl_url, 'result.html');
xslt_free($xh);

echo(iteration: $i = OK br/\n);

}
?
---



[2006-07-26 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2006-07-18 14:49:08] gabriel dot zerbib at protilab dot com

The same test data (XML  XSL) in same context (same PHP application,
same version) work and do not fail on Windows XP  IIS, whereas I
experience the same problem on submitter's platform.



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/38134

-- 
Edit this bug report at http://bugs.php.net/?id=38134edit=1

#38481 [NEW]: strtotime return invalid timestamp (if input value is timestamp)

[oleg at programstar dot com]

From: oleg at programstar dot com
Operating system: Fedora 4.1
PHP version:  5.1.4
PHP Bug Type: Date/time related
Bug description:  strtotime return invalid timestamp (if input value is 
timestamp)

Description:

I#8217;ve found a bug in strtotime() function.
The present function does not return anything if you transmit
unix_timestamp as a function parameter. However, if the last four digits
of the value compose a valid year value, the function tries to calculate
the whole date with the last 5 digits. Probably it fails there so it
returns unix_timestamp the dates with the day and month equal to the
current one, as far as the year goes, it is the one that the function has
detected in the timestamp primary value. 

Example: 
Primary value: 1136412001 (January, 5, 2006)
On return: 998037401 (August, 17, 2001)

This way, a standard plug-in Smarty uses this function to transform the
UNIX_TIMESTAMP format data into any data value. 
PHP Version 5.1.4

Original here: http://hcjack.livejournal.com/322438.html (on russian)


-- 
Edit bug report at http://bugs.php.net/?id=38481edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=38481r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=38481r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=38481r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38481r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=38481r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=38481r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38481r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38481r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=38481r=support
Expected behavior:http://bugs.php.net/fix.php?id=38481r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=38481r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=38481r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38481r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=38481r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38481r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38481r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=38481r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=38481r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=38481r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38481r=mysqlcfg

#38481 [Opn-Fbk]: strtotime return invalid timestamp (if input value is timestamp)

[tony2001]

 ID:   38481
 Updated by:   [EMAIL PROTECTED]
 Reported By:  oleg at programstar dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Date/time related
 Operating System: Fedora 4.1
 PHP Version:  5.1.4
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

If you're still able to reproduce it - please provide short and
complete reproduce script.


Previous Comments:


[2006-08-17 11:01:33] oleg at programstar dot com

Description:

I#8217;ve found a bug in strtotime() function.
The present function does not return anything if you transmit
unix_timestamp as a function parameter. However, if the last four
digits of the value compose a valid year value, the function tries to
calculate the whole date with the last 5 digits. Probably it fails
there so it returns unix_timestamp the dates with the day and month
equal to the current one, as far as the year goes, it is the one that
the function has detected in the timestamp primary value. 

Example: 
Primary value: 1136412001 (January, 5, 2006)
On return: 998037401 (August, 17, 2001)

This way, a standard plug-in Smarty uses this function to transform the
UNIX_TIMESTAMP format data into any data value. 
PHP Version 5.1.4

Original here: http://hcjack.livejournal.com/322438.html (on russian)






-- 
Edit this bug report at http://bugs.php.net/?id=38481edit=1

#38481 [Bgs]: strtotime return invalid timestamp (if input value is timestamp)

[oleg at programstar dot com]

 ID:   38481
 User updated by:  oleg at programstar dot com
 Reported By:  oleg at programstar dot com
 Status:   Bogus
 Bug Type: Date/time related
 Operating System: Fedora 4.1
 PHP Version:  5.1.4
 New Comment:

Yes, certainly! But repetition - thereby function uses standart
function date_format in Smarty.
Sorry for my bad English


Previous Comments:


[2006-08-17 11:21:13] [EMAIL PROTECTED]

Actually, no need to try the snapshot, it's bogus.
The function was never intended to parse timestamps, it parses string
containing a US English date format.



[2006-08-17 11:04:04] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

If you're still able to reproduce it - please provide short and
complete reproduce script.



[2006-08-17 11:01:33] oleg at programstar dot com

Description:

I#8217;ve found a bug in strtotime() function.
The present function does not return anything if you transmit
unix_timestamp as a function parameter. However, if the last four
digits of the value compose a valid year value, the function tries to
calculate the whole date with the last 5 digits. Probably it fails
there so it returns unix_timestamp the dates with the day and month
equal to the current one, as far as the year goes, it is the one that
the function has detected in the timestamp primary value. 

Example: 
Primary value: 1136412001 (January, 5, 2006)
On return: 998037401 (August, 17, 2001)

This way, a standard plug-in Smarty uses this function to transform the
UNIX_TIMESTAMP format data into any data value. 
PHP Version 5.1.4

Original here: http://hcjack.livejournal.com/322438.html (on russian)






-- 
Edit this bug report at http://bugs.php.net/?id=38481edit=1

#38481 [Fbk-Bgs]: strtotime return invalid timestamp (if input value is timestamp)

[tony2001]

 ID:   38481
 Updated by:   [EMAIL PROTECTED]
 Reported By:  oleg at programstar dot com
-Status:   Feedback
+Status:   Bogus
 Bug Type: Date/time related
 Operating System: Fedora 4.1
 PHP Version:  5.1.4
 New Comment:

Actually, no need to try the snapshot, it's bogus.
The function was never intended to parse timestamps, it parses string
containing a US English date format.


Previous Comments:


[2006-08-17 11:04:04] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

If you're still able to reproduce it - please provide short and
complete reproduce script.



[2006-08-17 11:01:33] oleg at programstar dot com

Description:

I#8217;ve found a bug in strtotime() function.
The present function does not return anything if you transmit
unix_timestamp as a function parameter. However, if the last four
digits of the value compose a valid year value, the function tries to
calculate the whole date with the last 5 digits. Probably it fails
there so it returns unix_timestamp the dates with the day and month
equal to the current one, as far as the year goes, it is the one that
the function has detected in the timestamp primary value. 

Example: 
Primary value: 1136412001 (January, 5, 2006)
On return: 998037401 (August, 17, 2001)

This way, a standard plug-in Smarty uses this function to transform the
UNIX_TIMESTAMP format data into any data value. 
PHP Version 5.1.4

Original here: http://hcjack.livejournal.com/322438.html (on russian)






-- 
Edit this bug report at http://bugs.php.net/?id=38481edit=1

#38134 [Fbk-Opn]: segfault while calling xslt_process

[gerome dot fournier at infomaniak dot ch]

 ID:   38134
 User updated by:  gerome dot fournier at infomaniak dot ch
 Reported By:  gerome dot fournier at infomaniak dot ch
-Status:   Feedback
+Status:   Open
 Bug Type: XSLT related
 Operating System: Debian Sarge
 PHP Version:  4.4.2
 New Comment:

You can get the details about this server using the following URL:

http://imu60.infomaniak.ch/phpinfo.php

We're using sablotron version 1.0 as provided by Debian sarge, and the
configure command line is the following:

'./configure' '--disable-all' '--prefix=/opt/php'
'--with-apxs=/opt/apache/bin/apxs' '--disable-ipv6' '--with-pear'
'--enable-xml' '--with-expat-dir=/usr' '--with-pcre-regex'
'--enable-memory-limit' '--enable-ftp' '--with-mysql=/opt/misc/mysql'
'--with-zlib-dir=/usr' '--with-openssl=/usr' '--with-zlib=/usr'
'--enable-bcmath' '--enable-calendar' '--enable-ctype'
'--with-curl=/usr' '--with-dom' '--with-dom-xslt' '--with-dom-exslt'
'--enable-exif' '--with-gd' '--with-jpeg-dir' '--with-png-dir'
'--with-xpm-dir' '--with-ttf' '--with-freetype-dir'
'--enable-gd-native-ttf' '--with-gettext' '--with-iconv' '--with-imap'
'--with-kerberos' '--with-imap-ssl' '--enable-mbstring'
'--enable-mbregex' '--with-mcal=/usr' '--with-mcrypt' '--with-mhash'
'--enable-overload' '--enable-posix' '--enable-session'
'--enable-tokenizer' '--enable-wddx' '--enable-xml' '--enable-xslt'
'--with-xslt-sablot=/usr' '--with-zip' '--with-pdflib=/opt/misc/pdflib'
'--with-tiff-dir=/usr' '--with-ming=/opt/misc/ming'

I don't have a more detailed GDB backtrace to provide for the moment.


Previous Comments:


[2006-08-17 10:01:09] [EMAIL PROTECTED]

What is the version of Sablotron used?
Are you able to get a decent GDB backtrace (using PHP configured with
--enable-debug)?
What was your full configure line?

It works just fine here with 1.0.1  Linux i386.



[2006-08-17 09:48:45] gabriel dot zerbib at protilab dot com

I'm sorry Tony, you were a little bit quick in closing with can't
reproduce.

You can just try the online demo. You'll manage to achieve the 100
iterations for some time, but if you hit Refresh a few times, you sure
will run into the problem: the page will not come to you, your browser
will report some proxy error or some Host not found error, which is
in fact caused by a violent crash of the PHP script and PHP
interpreter, never returning a response to your browser.

Please do not close this bug report too fast, as sample data were
properly provided, and the target platform and system and version.

Thanks.



[2006-08-17 09:43:05] [EMAIL PROTECTED]

Can't reproduce.



[2006-08-17 09:42:11] gerome dot fournier at infomaniak dot ch

Re-opened as the owner of the web site provided new feedbacks.



[2006-08-17 09:22:12] gabriel dot zerbib at protilab dot com

TEST DATA:

The files can be found at:
http://www.protilab.com/test/sample.xml
http://www.protilab.com/test/sample.xsl

And the PHP script can be run online at:
http://www.protilab.com/test/sample.php


SCENARIO:
An XSLT processor is instanciated using the XML and XSL files specified
in the arguments, in a loop of 100 iterations.
Among these 100 iterations, a seg-fault is likely to happen.



XML file to process (sample.xml):
---
?xml version=1.0 encoding=iso-8859-1?
?xml-stylesheet type=text/xsl href=sample.xsl?

root
node1 id=foo
subnodeASome Data A/subnodeA
subnodeA attr=123Some Mode Data A/subnodeA
/node1
node1 id=bar
subnodeASome Data A in another node/subnodeA
subnodeA attr=345Some Mode Data in second node/subnodeA
/node1
/root
---


XSL file to apply (sample.xsl):
---
?xml version=1.0 encoding=iso-8859-1?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;

xsl:template match=/
html
head
titleTitle here/title
/head

body
xsl:for-each select=/root/node1
xsl:value-of select=@id/
ul
xsl:for-each select=subnodeA
lixsl:value-of 
select=text()/ xsl:if test=@attr (
xsl:value-of select=@attr/ ) /xsl:if /li 
/xsl:for-each
/ul
   

#38476 [Opn-Fbk]: PATH_INFO, ORIG_PATH_INFO, and PHP_SELF not set in Lighttpd1.4.11/PHP4.4.3

[tony2001]

 ID:   38476
 Updated by:   [EMAIL PROTECTED]
 Reported By:  fietka at rpi dot edu
-Status:   Open
+Status:   Feedback
 Bug Type: CGI related
 Operating System: Debian Linux
 PHP Version:  4.4.3
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip




Previous Comments:


[2006-08-16 23:38:59] fietka at rpi dot edu

Actually, bug 31892 is slightly different (only 1 of the 3 variables
I'm missing is missing in that bug). Also, the solutions, diffs, and
patches cited in that bug are long outdated, making that report
irrelevant.



[2006-08-16 23:15:14] [EMAIL PROTECTED]

Duplicate of bug #31892.



[2006-08-16 20:09:39] fietka at rpi dot edu

Description:

In the course of playing with my new Lighty server running on Debian, I
ran into a problem with the PHP_SELF, PATH_INFO, and ORIG_PATH_INFO
variables - specifically, Lighty doesn't provide them to my PHP
install.

Even after applying all the fixes I could find:

Adding broken-scriptfilename = enable to my PHP config in
lighttpd.conf

Set cgi.fix_pathinfo = 1 in /etc/php4/cgi/php.ini

Compiled PHP4 with ./configure --enable-fastcgi --enable-ftp
--with-mysql --enable-force-redirect --enable-discard-path

Various combinations of these fixes didn't work either (PHP compiled
with and without each/both of the cgi-related switches). I found a
workaround for the KnowledgeTree? DMS:
http://issues.ktdms.com/browse/KTS-1289 and a Google Answers post I
made generated some good kludges(though neither of them work):
http://google.com/answers/threadview?id=754764

This seems to be a fairly serious Lighty/PHP issue that affects a large
number of people and currently has no resolution. If anyone wants any
further information or wants to contribute ideas on how to fix this,
feel free to e-mail me. 

Reproduce code:
---
print $_SERVER[PATH_INFO];
print $_SERVER[PHP_SELF];
print $_SERVER[ORIG_PATH_INFO];

Expected result:

null
null
null

Actual result:
--
Given site.com/folder/script.php,
/folder
/folder/script.php
/folder





-- 
Edit this bug report at http://bugs.php.net/?id=38476edit=1

#38478 [Opn-Asn]: reset() does not work as expected on Iterator implementations

[tony2001]

 ID:   38478
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Assigned
 Bug Type: SPL related
 Operating System: Gentoo
 PHP Version:  5.2.0RC1
-Assigned To:  
+Assigned To:  helly


Previous Comments:


[2006-08-17 08:20:07] [EMAIL PROTECTED]

Description:

The Iterator interface (SPL) defines a method rewind(). When
implementing e.g. ArrayIterator to allow array access to an object, one
would expect that reset($object) would use the rewind method. This does
not happen, but the first property is returned.

Reproduce code:
---
?php

class testArray implements Iterator
{
protected $prop = array(
1 = 'one',
2 = 'two',
3 = 'three',
);

public function rewind()
{
return reset( $this-prop );
}

public function key()
{
return key( $this-prop );
}

public function current()
{
return current( $this-prop );
}

public function next()
{
return next( $this-prop );
}

public function valid()
{
return ( current( $this-prop ) !== false );
}
}

$array = new testArray();

Expected result:

// Expected: string(3) one
var_dump( $array-rewind() );

// Expected: string(3) one
var_dump( reset( $array ) );


Actual result:
--
// As expected: string(3) one
var_dump( $array-rewind() );

// Expected: string(3) one
var_dump( reset( $array ) );
/* Got:
array(3) {
  [1]=
  string(3) one
  [2]=
  string(3) two
  [3]=
  string(5) three
}
*/





-- 
Edit this bug report at http://bugs.php.net/?id=38478edit=1

#38466 [Opn-WFx]: error

[pajoye]

 ID:   38466
 Updated by:   [EMAIL PROTECTED]
 Reported By:  roland dot augustsson at sbkvast dot com
-Status:   Open
+Status:   Wont fix
 Bug Type: Unknown/Other Function
 Operating System: win xp sp2
 PHP Version:  4.4.3
 New Comment:

Things have changed. RM and release people does not want to do their
jobs. I cannot do it for them  won't fix.


Previous Comments:


[2006-08-17 12:36:20] roland dot augustsson at sbkvast dot com

i copied go-pear.php from go-pear.org and script not workt, same error

go-pear.php from php ver 4.4.2 work fine.


/R



[2006-08-16 14:08:19] [EMAIL PROTECTED]

Please save the contents of http://go-pear.org as go-pear.php and check
if it works for you.



[2006-08-15 22:12:37] roland dot augustsson at sbkvast dot com

NO, but i copy go-pear.php from php 4.4.2 and it funktions correct.

thanks for the help.


/Roland



[2006-08-15 20:18:35] [EMAIL PROTECTED]

can you fetch a recent go-pear.php here:

http://go-pear.org

save it as C:\PHP\PEAR\go-pear.php and run again go-pear.bat.





[2006-08-15 14:25:58] roland dot augustsson at sbkvast dot com

same error !


* copy from dos window *

Welcome to go-pear!

Go-pear will install the 'pear' command and all the files needed by
it.  This command is your tool for PEAR installation and maintenance.

Use 'php PEAR\go-pear.php local' to install a local copy of PEAR.

Go-pear also lets you download and install the PEAR packages bundled
with PHP: MDB2, Net_Socket, Net_SMTP, Mail, XML_Parser, PHPUnit.


If you wish to abort, press Control-C now, or press Enter to continue:

HTTP proxy (http://user:[EMAIL PROTECTED]:port), or Enter for
none::

Below is a suggested file layout for your new PEAR installation.  To
change individual locations, type the number in front of the
directory.  Type 'all' to change all of them or simply press Enter to
accept these locations.

 1. Installation prefix   : C:\PHP
 2. Binaries directory: $prefix
 3. PHP code directory ($php_dir) : $prefix\pear
 4. Documentation base directory  : $php_dir\docs
 5. Data base directory   : $php_dir\data
 6. Tests base directory  : $php_dir\tests
 7. Temporary files directory : $prefix\temp
 8. php.exe path  : c:/php/cli/php.exe

1-8, 'all' or Enter to continue:

The following PEAR packages are bundled with PHP: MDB2, Net_Socket,
Net_SMTP, Mail, XML_Parser, PHPUnit.
Would you like to install these as well? [Y/n] : y

Loading zlib: ok
Using local package: PEAR-stable..ok
Using local package: Archive_Tar-stableok
Using local package: Console_Getopt-stableok
Using local package: XML_RPC-stableok
Bootstrapping: PEAR...(remote) !DOCTYPE html PUBLIC
-//W3C//DT
D XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
!-- ViewVC :: http://www.viewvc.org/ --
head
titleViewVC Exception/title
/head
body
h3An Exception Has Occurred/h3


h4Python Traceback/h4
ppre
Traceback (most recent call last):
  File /usr/local/viewvc-1.1-dev/lib/viewvc.py, line 3623, in main
request.run_viewvc()
  File /usr/local/viewvc-1.1-dev/lib/viewvc.py, line 388, in
run_viewvc
self.view_func(self)
  File /usr/local/viewvc-1.1-dev/lib/viewvc.py, line 2122, in
view_checkout
fp, revision = request.repos.openfile(path, rev)
  File /usr/local/viewvc-1.1-dev/lib/vclib/bincvs/__init__.py, line
134, in op
enfile
filename, revision = _parse_co_header(fp)
  File /usr/local/viewvc-1.1-dev/lib/vclib/bincvs/__init__.py, line
549, in _p
arse_co_header
raise COMalformedOutput, Unable to find revision in co output
stream
COMalformedOutput: Unable to find revision in co output stream

/pre/p
/body
/html
ok
Bootstrapping: Archive_Tar(local) ok
Bootstrapping: Console_Getopt.(remote) ok
Downloading package: MDB2.ok
Downloading package: Net_Socket...ok
Downloading package: Net_SMTP.ok
Downloading package: Mail.ok
Downloading package: XML_Parser...ok
Downloading package: PHPUnit..ok

Fatal error: Undefined class name 'pear' in C:\PHP\PEAR\go-pear.php on
line 747
Tryck på en valfri tangent för att fortsätta...



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/38466

-- 
Edit this bug report at http://bugs.php.net/?id=38466edit=1

#38476 [Opn]: PATH_INFO, ORIG_PATH_INFO, and PHP_SELF not set in Lighttpd1.4.11/PHP4.4.3

[fietka at rpi dot edu]

 ID:   38476
 User updated by:  fietka at rpi dot edu
 Reported By:  fietka at rpi dot edu
 Status:   Open
 Bug Type: CGI related
 Operating System: Debian Linux
 PHP Version:  4.4.3
 New Comment:

Okay - upgrading to the latest 5.2 from CVS populated PHP_SELF
correctly, with ORIG_PATH_INFO and PATH_INFO still empty. I did notice
that php.ini with php5 no longer has the cgi.fix_pathinfo option
available - why is that?


Previous Comments:


[2006-08-17 12:44:16] fietka at rpi dot edu

I'll try to give that  try on a development machine,but as far as I
know, installing PHP5 will break most, if not all, of my PHP
applications. Is this actually a PHP4 bug?



[2006-08-17 11:45:56] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip





[2006-08-16 23:38:59] fietka at rpi dot edu

Actually, bug 31892 is slightly different (only 1 of the 3 variables
I'm missing is missing in that bug). Also, the solutions, diffs, and
patches cited in that bug are long outdated, making that report
irrelevant.



[2006-08-16 23:15:14] [EMAIL PROTECTED]

Duplicate of bug #31892.



[2006-08-16 20:09:39] fietka at rpi dot edu

Description:

In the course of playing with my new Lighty server running on Debian, I
ran into a problem with the PHP_SELF, PATH_INFO, and ORIG_PATH_INFO
variables - specifically, Lighty doesn't provide them to my PHP
install.

Even after applying all the fixes I could find:

Adding broken-scriptfilename = enable to my PHP config in
lighttpd.conf

Set cgi.fix_pathinfo = 1 in /etc/php4/cgi/php.ini

Compiled PHP4 with ./configure --enable-fastcgi --enable-ftp
--with-mysql --enable-force-redirect --enable-discard-path

Various combinations of these fixes didn't work either (PHP compiled
with and without each/both of the cgi-related switches). I found a
workaround for the KnowledgeTree? DMS:
http://issues.ktdms.com/browse/KTS-1289 and a Google Answers post I
made generated some good kludges(though neither of them work):
http://google.com/answers/threadview?id=754764

This seems to be a fairly serious Lighty/PHP issue that affects a large
number of people and currently has no resolution. If anyone wants any
further information or wants to contribute ideas on how to fix this,
feel free to e-mail me. 

Reproduce code:
---
print $_SERVER[PATH_INFO];
print $_SERVER[PHP_SELF];
print $_SERVER[ORIG_PATH_INFO];

Expected result:

null
null
null

Actual result:
--
Given site.com/folder/script.php,
/folder
/folder/script.php
/folder





-- 
Edit this bug report at http://bugs.php.net/?id=38476edit=1

#38483 [NEW]: DOM fragments ignore document encoding

[webmaster at bison-soft dot de]

From: webmaster at bison-soft dot de
Operating system: linux 2.4
PHP version:  5.1.4
PHP Bug Type: DOM XML related
Bug description:  DOM fragments ignore document encoding

Description:

An XML-String appended to a DOMDocumentFragment with
appendXML() must always be encoded with UTF-8, regardless
of the choosen DOMDocument encoding. Even worse, after
appending the fragment to the document, the charset in
the fragment remains UTF-8, which leads to a DOMDocument
with mixed encodings inside.

Reproduce code:
---
$dom = new DOMDocument('1.0','ISO-8859-1');
$dom-loadXML('parent /');
$frag = $dom-createDocumentFragment();
$frag-appendXML('childöäü/child');
$dom-documentElement-appendChild($frag);


Expected result:

the ISO-8859-1 encoded XML-String will cleanly import into
the document fragment.

Actual result:
--
Error:

DOMDocumentFragment::appendXML() Entity: line 1: parser error : Input is
not proper UTF-8, indicate encoding !!

When trying to use an XML-declaration containing the ISO-8859-1 encoding
in the child-XML-String:

Entity: line 1: parser error : XML declaration allowed only at the start
of the document

When you convert the child-XML-String to utf8 and append it, you have a
DOMDocument with mixed charset

-- 
Edit bug report at http://bugs.php.net/?id=38483edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=38483r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=38483r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=38483r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38483r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=38483r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=38483r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38483r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38483r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=38483r=support
Expected behavior:http://bugs.php.net/fix.php?id=38483r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=38483r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=38483r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38483r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=38483r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38483r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38483r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=38483r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=38483r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=38483r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38483r=mysqlcfg

#38483 [Opn-Asn]: DOM fragments ignore document encoding

[tony2001]

 ID:   38483
 Updated by:   [EMAIL PROTECTED]
 Reported By:  webmaster at bison-soft dot de
-Status:   Open
+Status:   Assigned
 Bug Type: DOM XML related
 Operating System: linux 2.4
 PHP Version:  5.1.4
-Assigned To:  
+Assigned To:  rrichards


Previous Comments:


[2006-08-17 14:04:26] webmaster at bison-soft dot de

Description:

An XML-String appended to a DOMDocumentFragment with
appendXML() must always be encoded with UTF-8, regardless
of the choosen DOMDocument encoding. Even worse, after
appending the fragment to the document, the charset in
the fragment remains UTF-8, which leads to a DOMDocument
with mixed encodings inside.

Reproduce code:
---
$dom = new DOMDocument('1.0','ISO-8859-1');
$dom-loadXML('parent /');
$frag = $dom-createDocumentFragment();
$frag-appendXML('childöäü/child');
$dom-documentElement-appendChild($frag);


Expected result:

the ISO-8859-1 encoded XML-String will cleanly import into
the document fragment.

Actual result:
--
Error:

DOMDocumentFragment::appendXML() Entity: line 1: parser error : Input
is not proper UTF-8, indicate encoding !!

When trying to use an XML-declaration containing the ISO-8859-1
encoding in the child-XML-String:

Entity: line 1: parser error : XML declaration allowed only at the
start of the document

When you convert the child-XML-String to utf8 and append it, you have a
DOMDocument with mixed charset





-- 
Edit this bug report at http://bugs.php.net/?id=38483edit=1

#38308 [Opn-Fbk]: is_file and file_exists return false for uploaded file

[tony2001]

 ID:   38308
 Updated by:   [EMAIL PROTECTED]
 Reported By:  fartal at lanbyte dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: windows 2000
 PHP Version:  4.4.3
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip




Previous Comments:


[2006-08-03 09:29:00] fartal at lanbyte dot com

Description:

Hi.
After uploading a file, functions is_file and file_exists return
false for the temp file

Probably related to Bug #37118 :is_file returns false for uploaded
file but getting false also with file_exists

Just upgraded to PHP Version 4.4.2 on Windows 2000 server SP4 from
4.3.11 where I found the same error


Reproduce code:
---
?php
echo 'is_file:' . (is_file($_FILES['myfile']['tmp_name']) ? 'true' :
'false');?br?
echo 'file_exists:' . (file_exists($_FILES['myfile']['tmp_name']) ?
'true' : 'false');?br?
echo 'is_uploaded_file:' .
(is_uploaded_file($_FILES['myfile']['tmp_name']) ?
'true' : 'false');
 ?
form action=?php echo $_SERVER['PHP_SELF'] ?
enctype=multipart/form-data method=post
input type=file name=myfile /
input type=submit /
/form

Expected result:

is_file:true
file_exists:true
is_uploaded_file:true

Actual result:
--
is_file:false
file_exists:false
is_uploaded_file:true





-- 
Edit this bug report at http://bugs.php.net/?id=38308edit=1

#38484 [NEW]: cannot extract correct camera make and model

[camka at email dot ee]

From: camka at email dot ee
Operating system: win xp
PHP version:  5.1.4
PHP Bug Type: EXIF related
Bug description:  cannot extract correct camera make and model

Description:

exif_read_data returns empty camera make. At the same time all know image
viewers/editors recognize it correctly.

Is the image itself is incorrectly formatted, or exif extension cannot
handle the format of this exif version?

image: http://www.hot.ee/camka/exif/16722_DKGY6J.jpg 

Reproduce code:
---
print_r(exif_read_data($file));

Expected result:

...
[Make] = KONICA MINOLTA
[Model] = DIMAGE Z6
...

Actual result:
--
...
[Make] = 
[Model] = GE Z6 v1.00
...

-- 
Edit bug report at http://bugs.php.net/?id=38484edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=38484r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=38484r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=38484r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38484r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=38484r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=38484r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38484r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38484r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=38484r=support
Expected behavior:http://bugs.php.net/fix.php?id=38484r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=38484r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=38484r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38484r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=38484r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38484r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38484r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=38484r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=38484r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=38484r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38484r=mysqlcfg

#38228 [Opn-Fbk]: Pcntl based parallel threads loose connection to MySQL server

[tony2001]

 ID:   38228
 Updated by:   [EMAIL PROTECTED]
 Reported By:  piotr at bulczak dot name
-Status:   Open
+Status:   Feedback
 Bug Type: MySQL related
 Operating System: Fedora Core 5 Linux
 PHP Version:  5.1.4
 New Comment:

Try with mysql_connect ( server, username, password, TRUE);


Previous Comments:


[2006-07-27 18:25:30] piotr at bulczak dot name

I compiled php5.2-latest.tar.gz on FC5 with configure options
'--enable-pcntl' '--with-mysql' '--with-mysqli' '--with-pdo-mysql'.
Undoftunately the bug still exist in this version. My test script
produced again error message MySQL server has gone away.

Looking for some workaround I noticed that the problem does not occure
if I close all MySQL connections in parrent script before forking
childs. Maybe this info will help to spot problem source.



[2006-07-26 23:23:31] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip





[2006-07-26 20:09:18] piotr at bulczak dot name

Description:

For long time I was using multithreaded scripts (pcntl module). Each
script was using their own connection to MySQL server (mysql module).
They are working properly on FC1 - FC4 linuxes (PHP 4.3.11 - 5.0.4). I
tried for the first time to tun them on FC5 which includes standard rpm
packages - PHP 5.1.4 in this case (iptables and selinux turned off).

I noticed that my threads fail with message server has gone away when
using mysql_select_db. The behaviour is the same regardless if it is
connection via unix socket file, tcp/ip connection to localhost or some
remote IP address. It does not matter what MySQL server version I am
connecting to (tried with 3.23.58 - 5.0.22)

I tried also switch to mysqli module on FC5 and the script started
working properly again so I assume only mysql module is affected.

I do not have major changes to standard php.ini... just
max_execution_time=300 and memory_limit=32M. Test script is just a
minimal version (without any threads synchronization, etc. stuff).

Please help :-)

Reproduce code:
---
http://www.buleksoft.pl/mysql_pcntl_test.html

Expected result:

[EMAIL PROTECTED] ~]# php -q test.php
Forking thread number 0
Thread 0 doing some mysql tasks
Forking thread number 1
Thread 1 doing some mysql tasks
Forking thread number 2
Thread 2 doing some mysql tasks
Forking thread number 3
Thread 3 doing some mysql tasks


Actual result:
--
[EMAIL PROTECTED] ~]# php -q test.php
Forking thread number 0
Thread 0 doing some mysql tasks
Forking thread number 1
Thread 1: Could not select DB because MySQL server has gone away
Forking thread number 2
Thread 2: Could not select DB because MySQL server has gone away
Forking thread number 3
Thread 3: Could not select DB because MySQL server has gone away






-- 
Edit this bug report at http://bugs.php.net/?id=38228edit=1

#38483 [Asn-Bgs]: DOM fragments ignore document encoding

[rrichards]

 ID:   38483
 Updated by:   [EMAIL PROTECTED]
 Reported By:  webmaster at bison-soft dot de
-Status:   Assigned
+Status:   Bogus
 Bug Type: DOM XML related
 Operating System: linux 2.4
 PHP Version:  5.1.4
 Assigned To:  rrichards
 New Comment:

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

string passed to appendXML() must be utf-8 encoded and doc is not mixed
- loadxml() creates a new document defaulting to utf-8 encoding since
you do not have an xml decl.


Previous Comments:


[2006-08-17 14:04:26] webmaster at bison-soft dot de

Description:

An XML-String appended to a DOMDocumentFragment with
appendXML() must always be encoded with UTF-8, regardless
of the choosen DOMDocument encoding. Even worse, after
appending the fragment to the document, the charset in
the fragment remains UTF-8, which leads to a DOMDocument
with mixed encodings inside.

Reproduce code:
---
$dom = new DOMDocument('1.0','ISO-8859-1');
$dom-loadXML('parent /');
$frag = $dom-createDocumentFragment();
$frag-appendXML('childöäü/child');
$dom-documentElement-appendChild($frag);


Expected result:

the ISO-8859-1 encoded XML-String will cleanly import into
the document fragment.

Actual result:
--
Error:

DOMDocumentFragment::appendXML() Entity: line 1: parser error : Input
is not proper UTF-8, indicate encoding !!

When trying to use an XML-declaration containing the ISO-8859-1
encoding in the child-XML-String:

Entity: line 1: parser error : XML declaration allowed only at the
start of the document

When you convert the child-XML-String to utf8 and append it, you have a
DOMDocument with mixed charset





-- 
Edit this bug report at http://bugs.php.net/?id=38483edit=1

#38484 [Opn-Fbk]: cannot extract correct camera make and model

[tony2001]

 ID:   38484
 Updated by:   [EMAIL PROTECTED]
 Reported By:  camka at email dot ee
-Status:   Open
+Status:   Feedback
 Bug Type: EXIF related
 Operating System: win xp
 PHP Version:  5.1.4
 New Comment:

Looks like there is some Unicode in the exif tags.
Can you check it out?


Previous Comments:


[2006-08-17 14:10:10] camka at email dot ee

Description:

exif_read_data returns empty camera make. At the same time all know
image viewers/editors recognize it correctly.

Is the image itself is incorrectly formatted, or exif extension cannot
handle the format of this exif version?

image: http://www.hot.ee/camka/exif/16722_DKGY6J.jpg 

Reproduce code:
---
print_r(exif_read_data($file));

Expected result:

...
[Make] = KONICA MINOLTA
[Model] = DIMAGE Z6
...

Actual result:
--
...
[Make] = 
[Model] = GE Z6 v1.00
...





-- 
Edit this bug report at http://bugs.php.net/?id=38484edit=1

#37274 [Com]: Array style COM property access

[phpbugs at mike-c dot com]

 ID:   37274
 Comment by:   phpbugs at mike-c dot com
 Reported By:  tp at synolon dot gr
 Status:   Open
 Bug Type: COM related
 Operating System: Windows XP Pro
 PHP Version:  5.1.3
 New Comment:

I recently started playing around with COM objects in PHP, and this bug
has been causing me a huge headache.  I've read several reports,
including one which was marked fixed, so I did some research...

The following syntax works on PHP 5.0.4:
$Obj-Attribute['Name'] = $Val;

However on PHP 5.0.5, it throws an exception:
Fatal error: Uncaught exception 'com_exception' with message 'Error
[0x8002000e] Invalid number of parameters.

This therefore appears to be a regression dating back to apr/may 05.


Previous Comments:


[2006-05-26 06:40:05] tp at synolon dot gr

For the '$': Sorry, I misstyped it, but only here. In my original code
this is OK. Unfortunately this is not the problem.
I wonder if the problem is that the array style property returns an
object and not a simple data type. When bug 28161 was fixed I saw that
it was related with array style properties that could be assigned a
value directly (eg a string, a number etc). But what about object COM
properties?



[2006-05-25 14:46:46] dtyschenko at soft-ukraine dot com

$this-kbmDetail-Field[ fieldname ]-Value = $fieldvalue;

Is it okay, that you type filedname without '$' ???



[2006-05-02 09:59:52] tp at synolon dot gr

Description:

This seems to be related with bug #28161 that, as I read, was fixed
since version 5.0. I want to access an array style COM property that is
actually an object and then get or set a property of that object. I get
a COM exception when I do that followed by apache crash.
I have tried all binary PHP distributions for Windows that I found from
5.1.2 to 5.1.3 (cvs also) and did not work.
My PHP setup is the typical one described in 'install.txt' of the PHP
package. The only change that I have made in php.ini (except of the
doc_root) is 'com.allow_dcom = true'.
I use Apache 1.3.27.
Please help!

Reproduce code:
---
public function setField( $fieldname , $fieldvalue , $masterobj = true
)
{
// kbm  kbmDetail are class member variables
// that were previously instanciated like this:
// $this-kbm = new COM( SasClient.kbm );
// The kbm object has an array style property
// 'Field' that returns an object. We want to  
// set the 'Value' property.
// In VB this code looks like this:
// kbm.Field( fieldname ).Value = fieldvalue

try
{
if( $masterobj )
$this-kbm-Field[ $fieldname ]-Value = $fieldvalue;
else
$this-kbmDetail-Field[ fieldname ]-Value = 
$fieldvalue;
}
catch( com_exception $e )
{
print( $e-__toString( ) );
}
}

Expected result:

The property should be set

Actual result:
--
exception 'com_exception' with message 'Error [0x8002000e] Invalid
number of parameters. ' in c:\data\www\senapi\CSen.php:259 Stack trace:
#0 c:\data\www\senapi\CSen.php(259): CSen::setField() #1
c:\data\www\senapi\sentest.php(206): CSen-setField('docid', -1001) #2
{main}docid = -1001





-- 
Edit this bug report at http://bugs.php.net/?id=37274edit=1

#38485 [NEW]: bz2 extension does not compile with current GCC versions

[judas dot iscariote at gmail dot com]

From: judas dot iscariote at gmail dot com
Operating system: linux
PHP version:  5.2.0RC2
PHP Bug Type: Bzip2 Related
Bug description:  bz2 extension does not compile with current GCC versions

Description:

bz2 extension fails to compile in current gcc 4.1.x series

Reproduce code:
---
compile it as a shared extension

Expected result:

no errors, as always.

Actual result:
--
/usr/src/packages/BUILD/php-5.2.0RC2/ext/bz2/bz2.c:181: error: static
declaration of 'php_stream_bz2io_ops' follows non-static declaration
/usr/src/packages/BUILD/php-5.2.0RC2/ext/bz2/php_bz2.h:55: error: previous
declaration of 'php_stream_bz2io_ops' was here
make: *** [ext/bz2/bz2.lo] Error 1


-- 
Edit bug report at http://bugs.php.net/?id=38485edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=38485r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=38485r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=38485r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38485r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=38485r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=38485r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38485r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38485r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=38485r=support
Expected behavior:http://bugs.php.net/fix.php?id=38485r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=38485r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=38485r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38485r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=38485r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38485r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38485r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=38485r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=38485r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=38485r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38485r=mysqlcfg

#38484 [Fbk-Opn]: cannot extract correct camera make and model

[camka at email dot ee]

 ID:   38484
 User updated by:  camka at email dot ee
 Reported By:  camka at email dot ee
-Status:   Feedback
+Status:   Open
 Bug Type: EXIF related
 Operating System: win xp
 PHP Version:  5.1.4
 New Comment:

As i can see from PhotoStudio's Markers Exif Info tab both camera make
and camera model fields are ascii strings. Can i ask you where you got
the unicode thing from?


Previous Comments:


[2006-08-17 14:41:58] [EMAIL PROTECTED]

Looks like there is some Unicode in the exif tags.
Can you check it out?



[2006-08-17 14:10:10] camka at email dot ee

Description:

exif_read_data returns empty camera make. At the same time all know
image viewers/editors recognize it correctly.

Is the image itself is incorrectly formatted, or exif extension cannot
handle the format of this exif version?

image: http://www.hot.ee/camka/exif/16722_DKGY6J.jpg 

Reproduce code:
---
print_r(exif_read_data($file));

Expected result:

...
[Make] = KONICA MINOLTA
[Model] = DIMAGE Z6
...

Actual result:
--
...
[Make] = 
[Model] = GE Z6 v1.00
...





-- 
Edit this bug report at http://bugs.php.net/?id=38484edit=1

#38484 [Opn]: cannot extract correct camera make and model

[tony2001]

 ID:   38484
 Updated by:   [EMAIL PROTECTED]
 Reported By:  camka at email dot ee
 Status:   Open
 Bug Type: EXIF related
 Operating System: win xp
 PHP Version:  5.1.4
 New Comment:

See the output of exif_read_data(). It looks pretty much like a b0rked
unicode.


Previous Comments:


[2006-08-17 22:29:18] camka at email dot ee

As i can see from PhotoStudio's Markers Exif Info tab both camera make
and camera model fields are ascii strings. Can i ask you where you got
the unicode thing from?



[2006-08-17 14:41:58] [EMAIL PROTECTED]

Looks like there is some Unicode in the exif tags.
Can you check it out?



[2006-08-17 14:10:10] camka at email dot ee

Description:

exif_read_data returns empty camera make. At the same time all know
image viewers/editors recognize it correctly.

Is the image itself is incorrectly formatted, or exif extension cannot
handle the format of this exif version?

image: http://www.hot.ee/camka/exif/16722_DKGY6J.jpg 

Reproduce code:
---
print_r(exif_read_data($file));

Expected result:

...
[Make] = KONICA MINOLTA
[Model] = DIMAGE Z6
...

Actual result:
--
...
[Make] = 
[Model] = GE Z6 v1.00
...





-- 
Edit this bug report at http://bugs.php.net/?id=38484edit=1

#38487 [NEW]: Improving switch statement

[dtyschenko at soft-ukraine dot com]

From: dtyschenko at soft-ukraine dot com
Operating system: 
PHP version:  5.1.5
PHP Bug Type: Feature/Change Request
Bug description:  Improving switch statement

Description:

I think use switch in case like this will be very useful  

Reproduce code:
---
?php
switch ($a instanceof) {
case Foo : echo Foo; break;
case Bar : echo Bar; break;
default : echo Unknown : break;
}
?


-- 
Edit bug report at http://bugs.php.net/?id=38487edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=38487r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=38487r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=38487r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38487r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=38487r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=38487r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38487r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38487r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=38487r=support
Expected behavior:http://bugs.php.net/fix.php?id=38487r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=38487r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=38487r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38487r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=38487r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38487r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38487r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=38487r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=38487r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=38487r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38487r=mysqlcfg

#38466 [WFx-Csd]: error

[roland dot augustsson at sbkvast dot com]

 ID:   38466
 User updated by:  roland dot augustsson at sbkvast dot com
 Reported By:  roland dot augustsson at sbkvast dot com
-Status:   Wont fix
+Status:   Closed
 Bug Type: Unknown/Other Function
 Operating System: win xp sp2
 PHP Version:  4.4.3
 New Comment:

i solve problem, copy go-pear.php from php v 4.4.2 and php v 4.4.4
works fine now.

thanks for the help.


/R


Previous Comments:


[2006-08-17 12:55:45] [EMAIL PROTECTED]

Things have changed. RM and release people does not want to do their
jobs. I cannot do it for them  won't fix.



[2006-08-17 12:36:20] roland dot augustsson at sbkvast dot com

i copied go-pear.php from go-pear.org and script not workt, same error

go-pear.php from php ver 4.4.2 work fine.


/R



[2006-08-16 14:08:19] [EMAIL PROTECTED]

Please save the contents of http://go-pear.org as go-pear.php and check
if it works for you.



[2006-08-15 22:12:37] roland dot augustsson at sbkvast dot com

NO, but i copy go-pear.php from php 4.4.2 and it funktions correct.

thanks for the help.


/Roland



[2006-08-15 20:18:35] [EMAIL PROTECTED]

can you fetch a recent go-pear.php here:

http://go-pear.org

save it as C:\PHP\PEAR\go-pear.php and run again go-pear.bat.





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/38466

-- 
Edit this bug report at http://bugs.php.net/?id=38466edit=1

#38378 [Com]: wddx_serialize_value geneates no wellformed xml

[hweidner at gmx dot net]

 ID:   38378
 Comment by:   hweidner at gmx dot net
 Reported By:  clemens at gutweiler dot net
 Status:   Open
 Bug Type: WDDX related
 Operating System: Linux
 PHP Version:  4.4.3
 New Comment:

The function wddx_serialize_vars seems also affected:

$array=array(aaa, bbb, ccc);
echo wddx_serialize_vars(array);

creates to the broken XML code unter PHP 4.4.3

wddxPacket version='1.0'header/datastructvararray
length='3'stringaaa/stringstringbbb/stringstringccc/string/array/var/struct/data/wddxPacket


Previous Comments:


[2006-08-08 09:57:13] clemens at gutweiler dot net

Description:

wddx_serialize_value generates an invalid wddx package/xml 
string.

in php version 4.4.2 the sample code works, in 4.4.3 not.

Reproduce code:
---
?php
$array = array(
'index' = array(
1 = 'integer key',
'string' = 'string key'
)
);
var_dump( wddx_serialize_value( $array ) );
?


Expected result:

/web/cg/playground# /usr/local/php-4.4.2-fastcgi/bin/php 
wddx.php 

string(219) wddxPacket version='1.0'header/
datastructvar name='index'structvar 
name='1'stringinteger key/string/varvar 
name='string'stringstring key/string/var/struct/
var/struct/data/wddxPacket


Actual result:
--
/web/cg/playground# /usr/local/php-4.4.3-fastcgi/bin/php 
wddx.php 

string(179) wddxPacket version='1.0'header/
datastructvar structstringinteger key/string/
varvar nstringstring key/string/var/struct/var/
struct/data/wddxPacket






-- 
Edit this bug report at http://bugs.php.net/?id=38378edit=1

#38134 [Opn-Fbk]: segfault while calling xslt_process

[tony2001]

 ID:   38134
 Updated by:   [EMAIL PROTECTED]
 Reported By:  gerome dot fournier at infomaniak dot ch
-Status:   Open
+Status:   Feedback
 Bug Type: XSLT related
 Operating System: Debian Sarge
 PHP Version:  4.4.2
 New Comment:

Please upgrade sablotron to the latest available version and see if it
helps.


Previous Comments:


[2006-08-17 11:17:41] gerome dot fournier at infomaniak dot ch

You can get the details about this server using the following URL:

http://imu60.infomaniak.ch/phpinfo.php

We're using sablotron version 1.0 as provided by Debian sarge, and the
configure command line is the following:

'./configure' '--disable-all' '--prefix=/opt/php'
'--with-apxs=/opt/apache/bin/apxs' '--disable-ipv6' '--with-pear'
'--enable-xml' '--with-expat-dir=/usr' '--with-pcre-regex'
'--enable-memory-limit' '--enable-ftp' '--with-mysql=/opt/misc/mysql'
'--with-zlib-dir=/usr' '--with-openssl=/usr' '--with-zlib=/usr'
'--enable-bcmath' '--enable-calendar' '--enable-ctype'
'--with-curl=/usr' '--with-dom' '--with-dom-xslt' '--with-dom-exslt'
'--enable-exif' '--with-gd' '--with-jpeg-dir' '--with-png-dir'
'--with-xpm-dir' '--with-ttf' '--with-freetype-dir'
'--enable-gd-native-ttf' '--with-gettext' '--with-iconv' '--with-imap'
'--with-kerberos' '--with-imap-ssl' '--enable-mbstring'
'--enable-mbregex' '--with-mcal=/usr' '--with-mcrypt' '--with-mhash'
'--enable-overload' '--enable-posix' '--enable-session'
'--enable-tokenizer' '--enable-wddx' '--enable-xml' '--enable-xslt'
'--with-xslt-sablot=/usr' '--with-zip' '--with-pdflib=/opt/misc/pdflib'
'--with-tiff-dir=/usr' '--with-ming=/opt/misc/ming'

I don't have a more detailed GDB backtrace to provide for the moment.



[2006-08-17 10:01:09] [EMAIL PROTECTED]

What is the version of Sablotron used?
Are you able to get a decent GDB backtrace (using PHP configured with
--enable-debug)?
What was your full configure line?

It works just fine here with 1.0.1  Linux i386.



[2006-08-17 09:48:45] gabriel dot zerbib at protilab dot com

I'm sorry Tony, you were a little bit quick in closing with can't
reproduce.

You can just try the online demo. You'll manage to achieve the 100
iterations for some time, but if you hit Refresh a few times, you sure
will run into the problem: the page will not come to you, your browser
will report some proxy error or some Host not found error, which is
in fact caused by a violent crash of the PHP script and PHP
interpreter, never returning a response to your browser.

Please do not close this bug report too fast, as sample data were
properly provided, and the target platform and system and version.

Thanks.



[2006-08-17 09:43:05] [EMAIL PROTECTED]

Can't reproduce.



[2006-08-17 09:42:11] gerome dot fournier at infomaniak dot ch

Re-opened as the owner of the web site provided new feedbacks.



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/38134

-- 
Edit this bug report at http://bugs.php.net/?id=38134edit=1

#38134 [Fbk]: segfault while calling xslt_process

[tony2001]

 ID:   38134
 Updated by:   [EMAIL PROTECTED]
 Reported By:  gerome dot fournier at infomaniak dot ch
 Status:   Feedback
 Bug Type: XSLT related
 Operating System: Debian Sarge
 PHP Version:  4.4.2
 New Comment:

What is the version of Sablotron used?
Are you able to get a decent GDB backtrace (using PHP configured with
--enable-debug)?
What was your full configure line?

It works just fine here with 1.0.1  Linux i386.


Previous Comments:


[2006-08-17 09:48:45] gabriel dot zerbib at protilab dot com

I'm sorry Tony, you were a little bit quick in closing with can't
reproduce.

You can just try the online demo. You'll manage to achieve the 100
iterations for some time, but if you hit Refresh a few times, you sure
will run into the problem: the page will not come to you, your browser
will report some proxy error or some Host not found error, which is
in fact caused by a violent crash of the PHP script and PHP
interpreter, never returning a response to your browser.

Please do not close this bug report too fast, as sample data were
properly provided, and the target platform and system and version.

Thanks.



[2006-08-17 09:43:05] [EMAIL PROTECTED]

Can't reproduce.



[2006-08-17 09:42:11] gerome dot fournier at infomaniak dot ch

Re-opened as the owner of the web site provided new feedbacks.



[2006-08-17 09:22:12] gabriel dot zerbib at protilab dot com

TEST DATA:

The files can be found at:
http://www.protilab.com/test/sample.xml
http://www.protilab.com/test/sample.xsl

And the PHP script can be run online at:
http://www.protilab.com/test/sample.php


SCENARIO:
An XSLT processor is instanciated using the XML and XSL files specified
in the arguments, in a loop of 100 iterations.
Among these 100 iterations, a seg-fault is likely to happen.



XML file to process (sample.xml):
---
?xml version=1.0 encoding=iso-8859-1?
?xml-stylesheet type=text/xsl href=sample.xsl?

root
node1 id=foo
subnodeASome Data A/subnodeA
subnodeA attr=123Some Mode Data A/subnodeA
/node1
node1 id=bar
subnodeASome Data A in another node/subnodeA
subnodeA attr=345Some Mode Data in second node/subnodeA
/node1
/root
---


XSL file to apply (sample.xsl):
---
?xml version=1.0 encoding=iso-8859-1?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;

xsl:template match=/
html
head
titleTitle here/title
/head

body
xsl:for-each select=/root/node1
xsl:value-of select=@id/
ul
xsl:for-each select=subnodeA
lixsl:value-of 
select=text()/ xsl:if test=@attr (
xsl:value-of select=@attr/ ) /xsl:if /li 
/xsl:for-each
/ul
/xsl:for-each
/body 
/html
/xsl:template

/xsl:stylesheet
---


PHP script (sample.php)
---
?
$xmlFile = 'sample.xml';
$xsl_url = 'sample.xsl';


for($i = 0; $i  100; ++$i)
{

$xh = xslt_create();
xslt_set_encoding($xh, 'iso-8859-1');
xslt_process($xh, $xmlFile, $xsl_url, 'result.html');
xslt_free($xh);

echo(iteration: $i = OK br/\n);

}
?
---



[2006-07-26 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



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/38134

-- 
Edit this bug report at http://bugs.php.net/?id=38134edit=1

#38488 [Opn]: Access to php://stdin and faily crashes PHP on win32

[fmk]

 ID:   38488
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Streams related
 Operating System: win32
 PHP Version:  5CVS-2006-08-18 (CVS)
 New Comment:

I'm unable to get my system to crash (CGI and CLI). What SAPI are you
using?


Previous Comments:


[2006-08-18 02:31:47] [EMAIL PROTECTED]

Description:

Access to standard streams using php://stdin and family names
produces crash. The reason probably is in a buggy _get_osfhandle()
function that doesn't return proper HANDLES for standard system
streams. We need find out a workaround for this problem.

the bug is probably related to bug #7960

Reproduce code:
---
?php
$f = fopen(php://stdout, w+);
fwrite($f, Hello\n);
?

Expected result:

Hello

Actual result:
--
Crash with the following stack trace

NTDLL! 7c90eb74()
NTDLL! 7c90eb94()
_php_stream_fopen_from_fd(int 0, const char * 0x00416fb0 `string',
const char * 0x, int 0, char * 0x1070a25c `string', unsigned
int 246, char * 0x, unsigned int 0, void * * * 0x02714fe0) line
200 + 24 bytes
php_stream_url_wrap_php(_php_stream_wrapper * 0x108a5d28
_php_stream_php_wrapper, char * 0x00416fa6, char * 0x00416fb0 `string',
int 8, char * * 0x, _php_stream_context * 0x, int 1,
char * 0x106dd51c `string', unsigned int 1774, char * 0x004165c8
`string', unsigned int 498, void * * * 0x02714fe0) line 246 + 41 bytes
_php_stream_open_wrapper_ex(char * 0x00416fa0 `string', char *
0x00416fb0 `string', int 0, char * * 0x, _php_stream_context *
0x, int 0, char * 0x004165c8 `string', unsigned int 498, char *
0x, unsigned int 0, void * * * 0x02714fe0) line 1774 + 111
bytes
cli_register_file_handles(void * * * 0x02714fe0) line 498 + 52 bytes
main(int 2, char * * 0x026f8fc0) line 1030 + 12 bytes






-- 
Edit this bug report at http://bugs.php.net/?id=38488edit=1