Bug #49155 [Com]: SoapServer passes parameters as null if one has special wsdl definition
Edit report at https://bugs.php.net/bug.php?id=49155edit=1 ID: 49155 Comment by: jeroen at asystance dot nl Reported by:jeroen at asystance dot nl Summary:SoapServer passes parameters as null if one has special wsdl definition Status: Feedback Type: Bug Package:SOAP related Operating System: linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: I just tested 5.5.2-dev as well: fails. Previous Comments: [2013-08-02 15:04:11] jeroen at asystance dot nl Still not fixed in PHP 5.4.19-dev [2013-08-02 04:26:54] yohg...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I see several fixes in soap module. Could you try 5.4? [2012-04-26 08:30:22] nicolodien at gmx dot de Hi everybody I just want to confirm that this is still an issue! I've spent more than 3 hours debugging until I finally found this bug description giving me a solution. Please DO fix this problem... Thanks [2011-02-11 12:25:22] jeroen at asystance dot nl Just wanted to verify that this bug is still present in 5.3.3 [2009-08-05 12:22:29] jeroen at asystance dot nl Sorry for posting yet another comment, but it gets even weirder: wsdl:message name=someRequest wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=customerDetails element=tns:customer/wsdl:part /wsdl:message This will not work, because in the first part, the name==element However, wsdl:message name=someRequest wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=customer element=tns:customer/wsdl:part /wsdl:message _will_ work! Notice that now both parts are specified with name==element! My conclusion so far is that either _all_ of the parts need to be specified with the name==element pattern, or _none_. If one of the parts uses the pattern, the rest needs to conform, or else the SoapServer passes them as null. I sure hope this helps! I've been struggling with this for a while now. 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 https://bugs.php.net/bug.php?id=49155 -- Edit this bug report at https://bugs.php.net/bug.php?id=49155edit=1
Bug #49155 [Com]: SoapServer passes parameters as null if one has special wsdl definition
Edit report at https://bugs.php.net/bug.php?id=49155edit=1 ID: 49155 Comment by: jeroen at asystance dot nl Reported by:jeroen at asystance dot nl Summary:SoapServer passes parameters as null if one has special wsdl definition Status: Feedback Type: Bug Package:SOAP related Operating System: linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Still not fixed in PHP 5.4.19-dev Previous Comments: [2013-08-02 04:26:54] yohg...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I see several fixes in soap module. Could you try 5.4? [2012-04-26 08:30:22] nicolodien at gmx dot de Hi everybody I just want to confirm that this is still an issue! I've spent more than 3 hours debugging until I finally found this bug description giving me a solution. Please DO fix this problem... Thanks [2011-02-11 12:25:22] jeroen at asystance dot nl Just wanted to verify that this bug is still present in 5.3.3 [2009-08-05 12:22:29] jeroen at asystance dot nl Sorry for posting yet another comment, but it gets even weirder: wsdl:message name=someRequest wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=customerDetails element=tns:customer/wsdl:part /wsdl:message This will not work, because in the first part, the name==element However, wsdl:message name=someRequest wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=customer element=tns:customer/wsdl:part /wsdl:message _will_ work! Notice that now both parts are specified with name==element! My conclusion so far is that either _all_ of the parts need to be specified with the name==element pattern, or _none_. If one of the parts uses the pattern, the rest needs to conform, or else the SoapServer passes them as null. I sure hope this helps! I've been struggling with this for a while now. [2009-08-05 11:53:25] jeroen at asystance dot nl I have been able to further pin down the bug. The 2nd parameter is passed as null if, in the wsdl:message definition, the 1st wsdl:part element's name attribute is the same as the element attribute! wsdl:message name=someRequest wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=fail element=tns:customerId/wsdl:part /wsdl:message Here the 1st parameter works, but the second is always null! wsdl:message name=someRequest wsdl:part name=cid element=tns:customerId/wsdl:part wsdl:part name=win element=tns:customerId/wsdl:part /wsdl:message Now both parameters work. More generally, if one wsdl:part is specified in this way (name and element are the same), _every other parameter_ is passed as null: wsdl:message name=someRequest wsdl:part name=p1 element=tns:customerId/wsdl:part wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=p3 element=tns:customerId/wsdl:part /wsdl:message Here, p1 and p2 will be null, and customerId will work. Happy bugfixing! :) 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 https://bugs.php.net/bug.php?id=49155 -- Edit this bug report at https://bugs.php.net/bug.php?id=49155edit=1
Req #49513 [Com]: SoapServer-fault() shouldn't halt execution
Edit report at https://bugs.php.net/bug.php?id=49513edit=1
ID: 49513
Comment by: jeroen at asystance dot nl
Reported by:amr dot mostafa at gmail dot com
Summary:SoapServer-fault() shouldn't halt execution
Status: Open
Type: Feature/Change Request
Package:SOAP related
Operating System: GNU/Linux
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
This behavior is very undesirable!
How can I let a client know about the fault _and_ do server-side Exception
handling?
I'd love to do
try {
$server-handle();
} catch (Exception $e) {
$server-fault($e-getCode(), $e-getMessage());
throw $e;
}
To have default handling for uncaught Exceptions (which logs to file, email,
whatever), but that's not possible.
Previous Comments:
[2009-09-09 12:54:09] amr dot mostafa at gmail dot com
Description:
Calling SoapServer-fault() causes execution to terminate, there is no way for
the developer to get the XML response itself and process it differently.
Reproduce code:
---
$server = SoapServer(NULL, array('location' = 'http://example.com', 'uri' =
'http://example.com'));
$server-fault('foo', 'bar');
echo 'We are past $sever-fault()!'
Expected result:
We are past $server-fault()!
Actual result:
--
We are past $server-fault()! is never printed, only the XML for the SOAP
Fault is.
--
Edit this bug report at https://bugs.php.net/bug.php?id=49513edit=1
Req #38955 [Com]: PDO DBLIB driver does not support transactions
Edit report at https://bugs.php.net/bug.php?id=38955edit=1 ID: 38955 Comment by: vds dot jeroen at gmail dot com Reported by:remery at seminolesheriff dot org Summary:PDO DBLIB driver does not support transactions Status: Closed Type: Feature/Change Request Package:*General Issues Operating System: Linux PHP Version:5.1.6 Assigned To:ssufficool Block user comment: N Private report: N New Comment: Patch should be added to 5.3 branch Previous Comments: [2011-05-07 19:11:36] ssuffic...@php.net No developer cares about it, but plenty of users have and do care. I don't use PHP much anymore, but that may change. When it does, I will consider maintaining this in two different places. Until then, the patches are here and the currently working and tested module resides in svn trunk. [2011-04-30 21:19:14] paj...@php.net It is marked as such because nobody cares about it. And before you came in, it should have marked as such in core as well. Anyway, I do it for zip, enchant and planing to do so for more extensions as well. This is a very good way to provide more frequent releases to our users and especially to the distros. [2011-04-30 21:04:23] ssuffic...@php.net I do not see a practical way to PECL this because PDO is already core to PHP and marked depreciated in PECL. [2011-04-30 20:32:05] paj...@php.net I don't see why you could do releases via PECL as well. That will free you from the slower PHP release cycles. [2011-04-30 17:48:38] ssuffic...@php.net The whole of the PDO DBLIB needs to me moved to a release. There are many fixes and features as well as new tests. I have lobbied for these changes several times, now it is up to the release manager. 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 https://bugs.php.net/bug.php?id=38955 -- Edit this bug report at https://bugs.php.net/bug.php?id=38955edit=1
[PHP-BUG] Bug #54620 [NEW]: ReflectionClass::setStaticPropertyValue does not work for protected/private
From:
Operating system: linux
PHP version: 5.3.6
Package: Reflection related
Bug Type: Bug
Bug description:ReflectionClass::setStaticPropertyValue does not work for
protected/private
Description:
---
From manual page:
http://www.php.net/reflectionclass.setstaticpropertyvalue#Description
---
ReflectionClass::getProperties() shows public, protected and private
members, but ReflectionClass::setStaticPropertyValue throws a fatal error
if a protected or private member is set.
The error message says that Class Tehst does not have a property named
prot, which is plain wrong.
Test script:
---
?php
class Tehst {
public static $pub = 'pub';
protected static $prot = 'prot';
private static $priv = 'priv';
}
$rT = new ReflectionClass( 'Tehst' );
var_export( $rT-getProperties() );
$rT-setStaticPropertyValue( 'pub', 'myPub' );
$rT-setStaticPropertyValue( 'prot', 'myProt' );
$rT-setStaticPropertyValue( 'priv', 'myPriv' );
?
Expected result:
array (
0 =
ReflectionProperty::__set_state(array(
'name' = 'pub',
'class' = 'Tehst',
)),
1 =
ReflectionProperty::__set_state(array(
'name' = 'prot',
'class' = 'Tehst',
)),
2 =
ReflectionProperty::__set_state(array(
'name' = 'priv',
'class' = 'Tehst',
)),
)pub: myPub
Actual result:
--
array (
0 =
ReflectionProperty::__set_state(array(
'name' = 'pub',
'class' = 'Tehst',
)),
1 =
ReflectionProperty::__set_state(array(
'name' = 'prot',
'class' = 'Tehst',
)),
2 =
ReflectionProperty::__set_state(array(
'name' = 'priv',
'class' = 'Tehst',
)),
)pub: myPub
PHP Fatal error: Uncaught exception 'ReflectionException' with message
'Class Tehst does not have a property named prot' in
/home/jay/public_html/alis/newfile.php:14
Stack trace:
#0 /home/jay/public_html/alis/newfile.php(14):
ReflectionClass-setStaticPropertyValue('prot', 'myProt')
#1 {main}
thrown in /home/jay/public_html/alis/newfile.php on line 14
Fatal error: Uncaught exception 'ReflectionException' with message 'Class
Tehst does not have a property named prot' in
/home/jay/public_html/alis/newfile.php:14
Stack trace:
#0 /home/jay/public_html/alis/newfile.php(14):
ReflectionClass-setStaticPropertyValue('prot', 'myProt')
#1 {main}
thrown in /home/jay/public_html/alis/newfile.php on line 14
--
Edit bug report at http://bugs.php.net/bug.php?id=54620edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54620r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54620r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54620r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54620r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54620r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54620r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54620r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54620r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54620r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54620r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54620r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54620r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54620r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54620r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54620r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54620r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54620r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54620r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54620r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54620r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54620r=mysqlcfg
Bug #54620 [Opn]: ReflectionClass::setStaticPropertyValue does not work for protected/private
Edit report at http://bugs.php.net/bug.php?id=54620edit=1
ID: 54620
User updated by:jeroen at asystance dot nl
Reported by:jeroen at asystance dot nl
Summary:ReflectionClass::setStaticPropertyValue does not
work for protected/private
Status: Open
Type: Bug
Package:Reflection related
Operating System: linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Thanks for the workaround.
Access modifiers are for visibility between classes, so I don't see
circumventing them through Reflection as a problem. If you cast en
object to an array, you also get the private / protected variables (see
#44273).
Your workaround (using getProperty) also works just fine.
So I think the way to go is just enable access to private / protected
members.
Whatever the design decision though, a Fatal Error is certainly a bug :)
Previous Comments:
[2011-04-28 16:25:19] felipecg00 at gmail dot com
I can reproduce this, still I think that in this case, protecting the
private and protected resources is the correct behavior.
You might want to check this:
$rT = new ReflectionClass( 'Tehst' );
var_dump( $s = $rT-getProperty('prot') );
var_dump( $s-isStatic() );
$s-setAccessible(1);
$s-setValue(myProt);
var_dump( $s-getValue() );
[2011-04-28 12:45:27] jeroen at asystance dot nl
Description:
---
From manual page:
http://www.php.net/reflectionclass.setstaticpropertyvalue#Description
---
ReflectionClass::getProperties() shows public, protected and private
members, but ReflectionClass::setStaticPropertyValue throws a fatal
error if a protected or private member is set.
The error message says that Class Tehst does not have a property named
prot, which is plain wrong.
Test script:
---
?php
class Tehst {
public static $pub = 'pub';
protected static $prot = 'prot';
private static $priv = 'priv';
}
$rT = new ReflectionClass( 'Tehst' );
var_export( $rT-getProperties() );
$rT-setStaticPropertyValue( 'pub', 'myPub' );
$rT-setStaticPropertyValue( 'prot', 'myProt' );
$rT-setStaticPropertyValue( 'priv', 'myPriv' );
?
Expected result:
array (
0 =
ReflectionProperty::__set_state(array(
'name' = 'pub',
'class' = 'Tehst',
)),
1 =
ReflectionProperty::__set_state(array(
'name' = 'prot',
'class' = 'Tehst',
)),
2 =
ReflectionProperty::__set_state(array(
'name' = 'priv',
'class' = 'Tehst',
)),
)pub: myPub
Actual result:
--
array (
0 =
ReflectionProperty::__set_state(array(
'name' = 'pub',
'class' = 'Tehst',
)),
1 =
ReflectionProperty::__set_state(array(
'name' = 'prot',
'class' = 'Tehst',
)),
2 =
ReflectionProperty::__set_state(array(
'name' = 'priv',
'class' = 'Tehst',
)),
)pub: myPub
PHP Fatal error: Uncaught exception 'ReflectionException' with message
'Class Tehst does not have a property named prot' in
/home/jay/public_html/alis/newfile.php:14
Stack trace:
#0 /home/jay/public_html/alis/newfile.php(14):
ReflectionClass-setStaticPropertyValue('prot', 'myProt')
#1 {main}
thrown in /home/jay/public_html/alis/newfile.php on line 14
Fatal error: Uncaught exception 'ReflectionException' with message
'Class Tehst does not have a property named prot' in
/home/jay/public_html/alis/newfile.php:14
Stack trace:
#0 /home/jay/public_html/alis/newfile.php(14):
ReflectionClass-setStaticPropertyValue('prot', 'myProt')
#1 {main}
thrown in /home/jay/public_html/alis/newfile.php on line 14
--
Edit this bug report at http://bugs.php.net/bug.php?id=54620edit=1
[PHP-BUG] Bug #54099 [NEW]: PCRE preg_match incorrectly matches negated character class
From:
Operating system: Linux, Windows
PHP version: 5.3.5
Package: PCRE related
Bug Type: Bug
Bug description:PCRE preg_match incorrectly matches negated character class
Description:
The perl-compatible regex matcher somehow matches a negated character class
if the string to match contains the same characters, and in the same order,
as the character class.
I don't see why /[^ab]/ should match ab but not ba. Perl agrees:
$ perl -e 'for(ab,ba) { print $_: ; if( /[^ab]/ ) {print match\n}
else {print no match\n}}'
ab: no match
ba: no match
Test script:
---
?php
echo expecting 0, 0, 0, 0, 0\n;
echo preg_match( '[^ab]', 'ba' ) . \n;// expected no match,
passes
echo preg_match( '[^ab]', 'ab' ) . \n;// expected no match,
fails
echo preg_match( '([^ab])', 'ab' ) . \n; // expected no match,
passes
echo preg_match( '[^ab]', 'aba' ) . \n;// expected no match, fails
echo preg_match( '[^ab]', 'abb' ) . \n;// expected no match, fails
echo preg_match( '([^ab])', 'abb' ) . \n;// expected no match,
passes
?
Expected result:
expecting 0, 0, 0, 0, 0, 0
0
0
0
0
0
0
Actual result:
--
expecting 0, 0, 0, 0, 0, 0
0
1
0
1
1
0
--
Edit bug report at http://bugs.php.net/bug.php?id=54099edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54099r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54099r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54099r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54099r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54099r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54099r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54099r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54099r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54099r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54099r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54099r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54099r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54099r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54099r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54099r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54099r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54099r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54099r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54099r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54099r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54099r=mysqlcfg
Bug #54099 [Com]: PCRE preg_match incorrectly matches negated character class
Edit report at http://bugs.php.net/bug.php?id=54099edit=1
ID: 54099
Comment by: jeroen at asystance dot nl
Reported by:jeroen at asystance dot nl
Summary:PCRE preg_match incorrectly matches negated
character class
Status: Bogus
Type: Bug
Package:PCRE related
Operating System: Linux, Windows
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Argh, sorry, can't believe I didn't notice that!
Thanks for the swift reply!
Previous Comments:
[2011-02-25 10:33:54] ras...@php.net
You forgot your delimiters.
eg.
echo preg_match( '/[^ab]/', 'ab' ) . \n;
You didn't forget them in the Perl version which is why it worked there.
[2011-02-25 10:24:58] jeroen at asystance dot nl
Description:
The perl-compatible regex matcher somehow matches a negated character
class if the string to match contains the same characters, and in the
same order, as the character class.
I don't see why /[^ab]/ should match ab but not ba. Perl agrees:
$ perl -e 'for(ab,ba) { print $_: ; if( /[^ab]/ ) {print
match\n} else {print no match\n}}'
ab: no match
ba: no match
Test script:
---
?php
echo expecting 0, 0, 0, 0, 0\n;
echo preg_match( '[^ab]', 'ba' ) . \n;// expected no match,
passes
echo preg_match( '[^ab]', 'ab' ) . \n;// expected no match,
fails
echo preg_match( '([^ab])', 'ab' ) . \n; // expected no match,
passes
echo preg_match( '[^ab]', 'aba' ) . \n;// expected no match,
fails
echo preg_match( '[^ab]', 'abb' ) . \n;// expected no match,
fails
echo preg_match( '([^ab])', 'abb' ) . \n;// expected no match,
passes
?
Expected result:
expecting 0, 0, 0, 0, 0, 0
0
0
0
0
0
0
Actual result:
--
expecting 0, 0, 0, 0, 0, 0
0
1
0
1
1
0
--
Edit this bug report at http://bugs.php.net/bug.php?id=54099edit=1
Bug #49155 [Opn]: SoapServer passes parameters as null if one has special wsdl definition
Edit report at http://bugs.php.net/bug.php?id=49155edit=1 ID: 49155 User updated by:jeroen at asystance dot nl Reported by:jeroen at asystance dot nl Summary:SoapServer passes parameters as null if one has special wsdl definition Status: Open Type: Bug Package:SOAP related Operating System: linux -PHP Version:5.2SVN-2009-08-04 (snap) +PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Just wanted to verify that this bug is still present in 5.3.3 Previous Comments: [2009-08-05 12:22:29] jeroen at asystance dot nl Sorry for posting yet another comment, but it gets even weirder: wsdl:message name=someRequest wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=customerDetails element=tns:customer/wsdl:part /wsdl:message This will not work, because in the first part, the name==element However, wsdl:message name=someRequest wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=customer element=tns:customer/wsdl:part /wsdl:message _will_ work! Notice that now both parts are specified with name==element! My conclusion so far is that either _all_ of the parts need to be specified with the name==element pattern, or _none_. If one of the parts uses the pattern, the rest needs to conform, or else the SoapServer passes them as null. I sure hope this helps! I've been struggling with this for a while now. [2009-08-05 11:53:25] jeroen at asystance dot nl I have been able to further pin down the bug. The 2nd parameter is passed as null if, in the wsdl:message definition, the 1st wsdl:part element's name attribute is the same as the element attribute! wsdl:message name=someRequest wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=fail element=tns:customerId/wsdl:part /wsdl:message Here the 1st parameter works, but the second is always null! wsdl:message name=someRequest wsdl:part name=cid element=tns:customerId/wsdl:part wsdl:part name=win element=tns:customerId/wsdl:part /wsdl:message Now both parameters work. More generally, if one wsdl:part is specified in this way (name and element are the same), _every other parameter_ is passed as null: wsdl:message name=someRequest wsdl:part name=p1 element=tns:customerId/wsdl:part wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=p3 element=tns:customerId/wsdl:part /wsdl:message Here, p1 and p2 will be null, and customerId will work. Happy bugfixing! :) [2009-08-04 14:47:58] jeroen at asystance dot nl Description: I have a WSDL with three types: customerId, customer and order. Calling a function with just a customer works, but a calling a function with parameters (customerId, customer) does not - the customer parameter is always null. Another function, specified as (customerId, order), always works, so the problem is not using more than one parameter (which could be a problem since I'm using document/literal, and having more than one message part does not conform to WS-I). I have also tried switching the parameters and lots of other things but I cannot find the underlying problem. Reproduce code: --- http://jayvee.nl/soaptest.tar This includes a php file that runs a client as well as a server - so be sure to change the service URL in interface.wsdl before you run this. Expected result: When SoapServer calls function addCustomer ( $p1, $p2 ), $p2 should be a stdClass object (or array) Actual result: -- $p2 is null -- Edit this bug report at http://bugs.php.net/bug.php?id=49155edit=1
Bug #49278 [Ver]: SoapClient::__getLastResponseHeaders returns NULL if wsdl operation !has output
Edit report at http://bugs.php.net/bug.php?id=49278edit=1 ID: 49278 User updated by:jeroen at asystance dot nl Reported by:jeroen at asystance dot nl Summary:SoapClient::__getLastResponseHeaders returns NULL if wsdl operation !has output Status: Verified Type: Bug Package:SOAP related Operating System: linux -PHP Version:5.3SVN-2009-08-17 (snap) +PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Just wanted to confirm this bug is still present in 5.3.3 Previous Comments: [2009-09-19 20:19:00] sjo...@php.net Thank you for your bug report. Apparently, the response is not parsed at all when the method returns nothing. This gives problems with getLastResponseHeaders, as the bug reporter described. Furthermore, if the server returns a HTTP status such as 404 Not Found or 500 Internal Error, the client should does not throw a SoapFault, where it should. See ext/soap/php_http.c:771. [2009-08-17 10:07:52] jeroen at asystance dot nl Description: For wsdl:operations that do not have output, SoapClient does not return last response headers. Reproduce code: --- download http://jayvee.nl/soaptest3.tar change URL in interface.wsdl to point to SOAPtest.php SOAPtest.php contains both client and server code, so just run php SOAPtest.php Expected result: SoapClient::getLastResponseHeaders should return string Actual result: -- SoapClient::getLastResponseHeaders returns NULL -- Edit this bug report at http://bugs.php.net/bug.php?id=49278edit=1
Bug #49169 [Ver]: SoapServer calls wrong function, although SOAP action header is correct
Edit report at http://bugs.php.net/bug.php?id=49169edit=1 ID: 49169 User updated by:jeroen at asystance dot nl Reported by:jeroen at asystance dot nl Summary:SoapServer calls wrong function, although SOAP action header is correct Status: Verified Type: Bug Package:SOAP related Operating System: linux -PHP Version:5.2SVN-2009-08-05 (snap) +PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Just wanted to verify this bug is still present in 5.3.3 Previous Comments: [2010-09-08 14:04:08] rkm at nykredit dot dk Well, maybe the RPC-protocol will work, but where I work, it is mandatory to create services using style=document, and it really isn't to the advantage of PHP to tell the servicepeople in the Java dept. that we can't handle document styles. Actually I circumvented the problem, by putting all the message definitions in separate files, which I then include in the schema-part of the wsdl. Then PHP can handle the soap:binding style=document just fine, so the problem only occurs if the names are duplicated within the same file. [2010-09-08 13:54:12] hoffmeister dot c at gmx dot de This is no bug. I guess you used style=document in the wsdl file operation description. In this case there is no operation name passed from the client to the server. Try style=rpc (remote procedure call) instead. That works pretty well. [2010-03-30 12:19:42] rkm at nykredit dot dk Adding to the above comment - If first SoapServer fails to read your WSDL properly, it will end up calling all known methods of the object added to SoapServer. - By known I mean, that if the .wsdl describes *another* binding to *another* method, than the one called - The other method gets called as well, and the result added to the SOAP-ENV:Header tag in the return. [2010-03-30 11:03:12] rkm at nykredit dot dk It's not even enough to change the message name (I didn't get that from the initial comments) - One needs to change the element of the part. Thus wsdl:message name=getByIdRequest wsdl:part name=parameters element=tmp:ClientId/ /wsdl:message Will not work with (reusing tmp:ClientId): wsdl:message name=getByIdRequest2 wsdl:part name=parameters element=tmp:ClientId/ /wsdl:message You'll have to create a new element, wich makes it hard to use i a corporate environment, where you have to use standard elemnts - Thus this is not a valid option, even though it works: wsdl:message name=getByIdRequest2 wsdl:part name=parameters element=tmp:ClientId_Clone/ /wsdl:message This bug has been here for a while, any movement against a solution? So far I have to create a WSDL for each operation, which is not very PHP-smooth! [2009-11-04 17:08:04] spyowl at gmail dot com Confirmed on 5.3.1RC3 using WSDL. The problem seems to be the matching first argument name between methods (not the whole signature) - as long as 2 or more methods have the same name for the first argument the SoapServer will always execute the first method listed, regardless of soapAction, and even if there are additional arguments for those methods that are different from each other. This is a pretty serious bug. 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/bug.php?id=49169 -- Edit this bug report at http://bugs.php.net/bug.php?id=49169edit=1
Bug #49278 [Ver]: SoapClient::__getLastResponseHeaders returns NULL if wsdl operation !has output
Edit report at http://bugs.php.net/bug.php?id=49278edit=1 ID: 49278 User updated by:jeroen at asystance dot nl Reported by:jeroen at asystance dot nl Summary:SoapClient::__getLastResponseHeaders returns NULL if wsdl operation !has output Status: Verified Type: Bug Package:SOAP related Operating System: linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Also, if I add 'feature' = SOAP_WAIT_ONE_WAY_CALLS to the options array in the SoapClient constructor, instead of nothing, I get PHP Fatal error: Uncaught SoapFault exception: [Client] looks like we got no XML document Previous Comments: [2011-02-11 12:31:01] jeroen at asystance dot nl Just wanted to confirm this bug is still present in 5.3.3 [2009-09-19 20:19:00] sjo...@php.net Thank you for your bug report. Apparently, the response is not parsed at all when the method returns nothing. This gives problems with getLastResponseHeaders, as the bug reporter described. Furthermore, if the server returns a HTTP status such as 404 Not Found or 500 Internal Error, the client should does not throw a SoapFault, where it should. See ext/soap/php_http.c:771. [2009-08-17 10:07:52] jeroen at asystance dot nl Description: For wsdl:operations that do not have output, SoapClient does not return last response headers. Reproduce code: --- download http://jayvee.nl/soaptest3.tar change URL in interface.wsdl to point to SOAPtest.php SOAPtest.php contains both client and server code, so just run php SOAPtest.php Expected result: SoapClient::getLastResponseHeaders should return string Actual result: -- SoapClient::getLastResponseHeaders returns NULL -- Edit this bug report at http://bugs.php.net/bug.php?id=49278edit=1
[PHP-BUG] Req #52453 [NEW]: Connection charset seems arbitrary
From: Operating system: Linux PHP version: 5.3.3 Package: MySQLi related Bug Type: Feature/Change Request Bug description:Connection charset seems arbitrary Description: The connection_charset used by a mysql/mysqli connection seems arbitrary - at least I cannot figure out how it is determined. The documentation provides no clues as to which charset is used by default. I've tried connecting to different mysql servers from different shell servers and can't figure out how the default charset is determined. As to find out which one is used, open a mysql/mysqli (procedural or object-oriented doesn't matter) connection and use mysql_client_encoding() / mysqli_get_charset() or SHOW VARIABLES LIKE 'character_set%'; to find out. This probably is just a documentation problem, but maybe the default could be chosen more sensibly: for example, the mysql server database's charset seems the most sensible default. For example, connecting from a shell that has en_US.UTF-8 as locale, I get: character_set_client: utf8 character_set_connection: utf8 character_set_database: utf8 character_set_filesystem: binary character_set_results: utf8 character_set_server: utf8 character_set_system: utf8 character_sets_dir: /usr/share/mysql/charsets/ Switching to en_US.iso88591 doesn't change anything. So it would seem some server setting determines the charset, right? However, connecting to the same mysql server from another system (though from intranet instead of internet), I get: character_set_client: latin1 character_set_connection: latin1 character_set_database: utf8 character_set_filesystem: binary character_set_results: latin1 character_set_server: utf8 character_set_system: utf8 character_sets_dir: /usr/share/mysql/charsets/ Again, the client locale doesn't influence this. -- Edit bug report at http://bugs.php.net/bug.php?id=52453edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52453r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52453r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52453r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52453r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52453r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52453r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52453r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52453r=needscript Try newer version: http://bugs.php.net/fix.php?id=52453r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52453r=support Expected behavior: http://bugs.php.net/fix.php?id=52453r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52453r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52453r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52453r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52453r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52453r=dst IIS Stability: http://bugs.php.net/fix.php?id=52453r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52453r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52453r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52453r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52453r=mysqlcfg
Req #52453 [Com]: Connection charset seems arbitrary
Edit report at http://bugs.php.net/bug.php?id=52453edit=1 ID: 52453 Comment by: jeroen at asystance dot nl Reported by:jeroen at asystance dot nl Summary:Connection charset seems arbitrary Status: Open Type: Feature/Change Request Package:MySQLi related Operating System: Linux PHP Version:5.3.3 Block user comment: N New Comment: BTW: when I make the same connection as in the first example, but use the mysql CLI client instead of php, I get mysql SHOW VARIABLES LIKE 'character_set%'; +--++ | Variable_name| Value | +--++ | character_set_client | latin1 | | character_set_connection | latin1 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results| latin1 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--++ So PHP's mysql_connect() behaves differently from mysql cli! Previous Comments: [2010-07-27 11:00:11] jeroen at asystance dot nl Description: The connection_charset used by a mysql/mysqli connection seems arbitrary - at least I cannot figure out how it is determined. The documentation provides no clues as to which charset is used by default. I've tried connecting to different mysql servers from different shell servers and can't figure out how the default charset is determined. As to find out which one is used, open a mysql/mysqli (procedural or object-oriented doesn't matter) connection and use mysql_client_encoding() / mysqli_get_charset() or SHOW VARIABLES LIKE 'character_set%'; to find out. This probably is just a documentation problem, but maybe the default could be chosen more sensibly: for example, the mysql server database's charset seems the most sensible default. For example, connecting from a shell that has en_US.UTF-8 as locale, I get: character_set_client: utf8 character_set_connection: utf8 character_set_database: utf8 character_set_filesystem: binary character_set_results: utf8 character_set_server: utf8 character_set_system: utf8 character_sets_dir: /usr/share/mysql/charsets/ Switching to en_US.iso88591 doesn't change anything. So it would seem some server setting determines the charset, right? However, connecting to the same mysql server from another system (though from intranet instead of internet), I get: character_set_client: latin1 character_set_connection: latin1 character_set_database: utf8 character_set_filesystem: binary character_set_results: latin1 character_set_server: utf8 character_set_system: utf8 character_sets_dir: /usr/share/mysql/charsets/ Again, the client locale doesn't influence this. -- Edit this bug report at http://bugs.php.net/bug.php?id=52453edit=1
[PHP-BUG] Bug #52081 [NEW]: SOAPClient makes calls, throws weird Exception anyway
From: Operating system: Linux (Debian/Ubuntu) PHP version: 5.3.2 Package: SOAP related Bug Type: Bug Bug description:SOAPClient makes calls, throws weird Exception anyway Description: I'm trying to get a SOAPClient call to work which HAS worked (about half a year ago), but which now throws weird Exceptions, even though the call is made. Unzip http://jayvee.nl/soaptest.zip and open soaptest.php. (Note that the WSDL specifies a URL for the service which is on our development environment. You can use this URL if you want.) The script tries to call the same operation four times. The different scenarios are: a) WSDL specifies output, SOAPClient uses SOAP_WAIT_ONE_WAY_CALLS feature b) WSDL specifies output, SOAPClient does NOT use SOAP_WAIT_ONE_WAY_CALLS feature c) WSDL specifies NO output, SOAPClient uses SOAP_WAIT_ONE_WAY_CALLS feature d) WSDL specifies NO output, SOAPClient does NOT use SOAP_WAIT_ONE_WAY_CALLS feature In each case, a call IS MADE. However, in cases a-c, I get an Exception: SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'implementations/nsure/interface/WizBizzInterface.wsdl' : failed to load external entity implementations/nsure/interface/WizBizzInterface.wsdl I have no idea where this path comes from. I _have_ used this in the past, but the test case does not use it. It seems this fault description has gotten stuck somewhere. I have disabled APC, checked for cached WSDLs in /tmp and rebooted the (virtual) machine, to no avail. Case d returns NULL, which is correct (WSDL operation specifies NO output). Note that although the SOAPClient uses the same WSDL as in case c, now it is not complaining about an unfindable path. I have tested this on PHP 5.2.13 (Ubuntu) and 5.3.2 (Debian), both using Suhosin patch, on Apache 2.2.x. -- I really hope this gets fixed soon, because I need to take this into production in a month or two. However, since three other SOAP bug reports (49155, 49169, 49278) haven't been addressed for almost a year, I'm left wondering whether I should have spent time creating a fourth bug report instead of looking for an alternative (nuSOAP or something). Test script: --- Download http://jayvee.nl/soaptest.zip and run the php script. Expected result: Web service return parameter Actual result: -- SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'implementations/nsure/interface/WizBizzInterface.wsdl' : failed to load external entity implementations/nsure/interface/WizBizzInterface.wsdl -- Edit bug report at http://bugs.php.net/bug.php?id=52081edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52081r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52081r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52081r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52081r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52081r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52081r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52081r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52081r=needscript Try newer version: http://bugs.php.net/fix.php?id=52081r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52081r=support Expected behavior: http://bugs.php.net/fix.php?id=52081r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52081r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52081r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52081r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52081r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52081r=dst IIS Stability: http://bugs.php.net/fix.php?id=52081r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52081r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52081r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52081r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52081r=mysqlcfg
Bug #52081 [Opn-Csd]: SOAPClient makes calls, throws weird Exception anyway
Edit report at http://bugs.php.net/bug.php?id=52081edit=1 ID: 52081 User updated by: jeroen at asystance dot nl Reported by: jeroen at asystance dot nl Summary: SOAPClient makes calls, throws weird Exception anyway -Status: Open +Status: Closed Type: Bug Package: SOAP related Operating System: Linux (Debian/Ubuntu) PHP Version: 5.3.2 New Comment: sorry, bogus bug report! Previous Comments: [2010-06-14 14:38:24] jeroen at asystance dot nl Description: I'm trying to get a SOAPClient call to work which HAS worked (about half a year ago), but which now throws weird Exceptions, even though the call is made. Unzip http://jayvee.nl/soaptest.zip and open soaptest.php. (Note that the WSDL specifies a URL for the service which is on our development environment. You can use this URL if you want.) The script tries to call the same operation four times. The different scenarios are: a) WSDL specifies output, SOAPClient uses SOAP_WAIT_ONE_WAY_CALLS feature b) WSDL specifies output, SOAPClient does NOT use SOAP_WAIT_ONE_WAY_CALLS feature c) WSDL specifies NO output, SOAPClient uses SOAP_WAIT_ONE_WAY_CALLS feature d) WSDL specifies NO output, SOAPClient does NOT use SOAP_WAIT_ONE_WAY_CALLS feature In each case, a call IS MADE. However, in cases a-c, I get an Exception: SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'implementations/nsure/interface/WizBizzInterface.wsdl' : failed to load external entity implementations/nsure/interface/WizBizzInterface.wsdl I have no idea where this path comes from. I _have_ used this in the past, but the test case does not use it. It seems this fault description has gotten stuck somewhere. I have disabled APC, checked for cached WSDLs in /tmp and rebooted the (virtual) machine, to no avail. Case d returns NULL, which is correct (WSDL operation specifies NO output). Note that although the SOAPClient uses the same WSDL as in case c, now it is not complaining about an unfindable path. I have tested this on PHP 5.2.13 (Ubuntu) and 5.3.2 (Debian), both using Suhosin patch, on Apache 2.2.x. -- I really hope this gets fixed soon, because I need to take this into production in a month or two. However, since three other SOAP bug reports (49155, 49169, 49278) haven't been addressed for almost a year, I'm left wondering whether I should have spent time creating a fourth bug report instead of looking for an alternative (nuSOAP or something). Test script: --- Download http://jayvee.nl/soaptest.zip and run the php script. Expected result: Web service return parameter Actual result: -- SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'implementations/nsure/interface/WizBizzInterface.wsdl' : failed to load external entity implementations/nsure/interface/WizBizzInterface.wsdl -- Edit this bug report at http://bugs.php.net/bug.php?id=52081edit=1
#51141 [NEW]: Add a deleteMin() method to SplMaxHeap
From: jeroen at jeroen-vandeven dot nl
Operating system:
PHP version: 5.3.1
PHP Bug Type: Feature/Change Request
Bug description: Add a deleteMin() method to SplMaxHeap
Description:
Add a deleteMin() method to SplMaxHeap (and/or a deleteMax() to
SplMinHeap) to limit the size of the heap without taking off the top
element.
Reproduce code:
---
$heap = new SplMaxHeap();
for ($i = 0; $i 1; $i++) {
$heap.insert($arr[$i])
if ($heap.count() 100) {
$heap.deleteMin();
}
}
Expected result:
The example is pretty useless, it will add 100 elements to the heap and
then add 9900 more, immediately removing each one.
This is useful in other situations where you may only be interested in
the top 100 sorted elements of 1 unsorted elements and don't want
the heap to grow excessively large.
Actual result:
--
There is no deleteMin() method in SplMaxHeap
--
Edit bug report at http://bugs.php.net/?id=51141edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51141r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51141r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51141r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51141r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51141r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51141r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51141r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51141r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51141r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51141r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51141r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51141r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51141r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51141r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51141r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51141r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51141r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51141r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51141r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51141r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51141r=mysqlcfg
#48339 [Com]: DOMElement::setIdAttribute() throws 'Not Found Error' exception
ID: 48339
Comment by: jeroen at tietema dot net
Reported By: greatwhitepine at bigfoot dot com
Status: No Feedback
Bug Type: DOM XML related
Operating System: opensuse 11.1
PHP Version: 5.2.9
Assigned To: rrichards
New Comment:
I can confirm this issue on Archlinux running PHP 5.3.0 and on Ubuntu
9.04 with PHP 5.2.6-3ubuntu4.2
Previous Comments:
[2009-06-04 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.
[2009-05-27 14:53:51] rricha...@php.net
Did you upgrade libxml2 while upgrading PHP? The has been no change in
the setIdAttribute() method.
[2009-05-19 23:17:23] greatwhitepine at bigfoot dot com
Description:
DOMElement::setIdAttribute() is broken in 5.2.9. It works properly in
5.2.6.
Reproduce code:
---
?php
// php_dom_setidattribute_bug.php
$obj_domDocument = new DOMDocument( );
$obj_domElement = $obj_domDocument-createElement( 'test', 'This is
the root element!' );
$obj_domElement = $obj_domDocument-appendChild( $obj_domElement
);
$obj_domElement-setAttribute( 'xml:id', 1 );
$obj_domElement-setIdAttribute( 'xml:id', TRUE );
print $obj_domDocument-saveXML( );
?
Expected result:
This should not throw any exception.
Actual result:
--
PHP Fatal error: Uncaught exception 'DOMException' with message 'Not
Found Error' in /home/gwp/bin/php_dom_setidattribute_bug.php:13
Stack trace:
#0 /home/gwp/bin/php_dom_setidattribute_bug.php(13):
DOMElement-setIdAttribute('xml:id', true)
#1 {main}
thrown in /home/gwp/bin/php_dom_setidattribute_bug.php on line 13
Fatal error: Uncaught exception 'DOMException' with message 'Not Found
Error' in /home/gwp/bin/php_dom_setidattribute_bug.php:13
--
Edit this bug report at http://bugs.php.net/?id=48339edit=1
#49169 [Com]: SoapServer calls wrong function, although SOAP action header is correct
ID: 49169 Comment by: jeroen at asystance dot nl Reported By: jeroen at asystance dot nl Status: Verified Bug Type: SOAP related Operating System: linux PHP Version: 5.2SVN-2009-08-05 (snap) New Comment: bigdan, I think you left out one option: this _is_ a bug. Using RPC style _is_ a workaround, but one that doesn't always work. The real problem is that SOAP should use the SOAPAction header to determine which operation to call, not guess based on parameters (which is what it looks to be doing now). While the comment you refer to does point out this very issue and predates this bug, that doesn't mean it's not a bug. Rather the commenter could (and should?) have filed this as a bug more than a year ago. Previous Comments: [2009-09-18 13:51:18] bigdan at gmail dot com Nevermind on the workaround - either this is not a bug, this issue was noticed well before this bug, or the comments here are entirely unrelated though they correct the issue for me: http://us3.php.net/manual/en/soapserver.handle.php#81750 TLDR: Instead of soap:binding style=document you need to use soap:binding style=rpc [2009-09-18 13:45:30] bigdan at gmail dot com? Is anyone aware of a workaround? I am having this issue on Ubuntu Hardy. Thanks [2009-09-09 19:27:50] sjo...@php.net Could reproduce. Even though the soap action looked as follows: SOAPAction: operation2 Operation 1 was called. [2009-08-20 15:18:33] robin dot harvey at chaptereight dot com Hi, This bug is affecting me too, and I've noticed that it's only the input parameters which trigger the bug - 2 functions can have the same output and they are treated individually. Also, it seems that it's the order of the wsdl:binding/wsdl:operation declarations which makes a difference, swapping the wsdl:portType/wsdl:operation or wsdl:message ordering does not trigger the bug. HTH --Robin [2009-08-05 11:13:06] jeroen at asystance dot nl The correct link to the test case is http://jayvee.nl/soaptest2.tar (without the comma) 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/49169 -- Edit this bug report at http://bugs.php.net/?id=49169edit=1
#49278 [NEW]: SoapClient::__getLastResponseHeaders returns NULL if wsdl operation !has output
From: jeroen at asystance dot nl Operating system: linux PHP version: 5.3SVN-2009-08-17 (snap) PHP Bug Type: SOAP related Bug description: SoapClient::__getLastResponseHeaders returns NULL if wsdl operation !has output Description: For wsdl:operations that do not have output, SoapClient does not return last response headers. Reproduce code: --- download http://jayvee.nl/soaptest3.tar change URL in interface.wsdl to point to SOAPtest.php SOAPtest.php contains both client and server code, so just run php SOAPtest.php Expected result: SoapClient::getLastResponseHeaders should return string Actual result: -- SoapClient::getLastResponseHeaders returns NULL -- Edit bug report at http://bugs.php.net/?id=49278edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49278r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49278r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49278r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49278r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49278r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49278r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49278r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49278r=needscript Try newer version: http://bugs.php.net/fix.php?id=49278r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49278r=support Expected behavior: http://bugs.php.net/fix.php?id=49278r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49278r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49278r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49278r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49278r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49278r=dst IIS Stability: http://bugs.php.net/fix.php?id=49278r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49278r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49278r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49278r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49278r=mysqlcfg
#49169 [NEW]: SoapServer calls wrong function, although SOAP action header is correct
From: jeroen at asystance dot nl Operating system: linux PHP version: 5.2SVN-2009-08-05 (snap) PHP Bug Type: SOAP related Bug description: SoapServer calls wrong function, although SOAP action header is correct Description: When two wsdl:operations have the same API (that is, have the same wsdl:messages), the SoapServer calls the function corresponding to the _first_ wsdl:operation specified in the wsdl:binding, even although the SoapClient sends the correct SOAP action header, which is correctly received on the server. Reproduce code: --- Download http://jayvee.nl/soaptest2.tar, untar and change the URL in interface.wsdl call SAOPTest.php, which is both a client and server. The server will produce a log that the client outputs, so you can see what the server is doing. Expected result: Independent of the order in which the wsdl:operations are listed in the wsdl:binding element, the SoapServer should call the function corresponding to the SOAP action header specified in the request. Actual result: -- The SoapServer always calls the function corresponding to the _first_ wsdl:operation specified. In the test case, the server will call function operation1() twice, even though the second call is to operation2, and the SOAP action header's value is operation2 To verify, switch the wsdl:operation elements in the wsdl:binding element and run SOAPTest.php. You will see that the server will call function operation2() twice, even though the SOAP action headers are different. -- Edit bug report at http://bugs.php.net/?id=49169edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49169r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49169r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49169r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49169r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49169r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49169r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49169r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49169r=needscript Try newer version: http://bugs.php.net/fix.php?id=49169r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49169r=support Expected behavior: http://bugs.php.net/fix.php?id=49169r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49169r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49169r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49169r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49169r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49169r=dst IIS Stability: http://bugs.php.net/fix.php?id=49169r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49169r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49169r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49169r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49169r=mysqlcfg
#49169 [Opn]: SoapServer calls wrong function, although SOAP action header is correct
ID: 49169 User updated by: jeroen at asystance dot nl Reported By: jeroen at asystance dot nl Status: Open Bug Type: SOAP related Operating System: linux PHP Version: 5.2SVN-2009-08-05 (snap) New Comment: The correct link to the test case is http://jayvee.nl/soaptest2.tar (without the comma) Previous Comments: [2009-08-05 11:11:00] jeroen at asystance dot nl Description: When two wsdl:operations have the same API (that is, have the same wsdl:messages), the SoapServer calls the function corresponding to the _first_ wsdl:operation specified in the wsdl:binding, even although the SoapClient sends the correct SOAP action header, which is correctly received on the server. Reproduce code: --- Download http://jayvee.nl/soaptest2.tar, untar and change the URL in interface.wsdl call SAOPTest.php, which is both a client and server. The server will produce a log that the client outputs, so you can see what the server is doing. Expected result: Independent of the order in which the wsdl:operations are listed in the wsdl:binding element, the SoapServer should call the function corresponding to the SOAP action header specified in the request. Actual result: -- The SoapServer always calls the function corresponding to the _first_ wsdl:operation specified. In the test case, the server will call function operation1() twice, even though the second call is to operation2, and the SOAP action header's value is operation2 To verify, switch the wsdl:operation elements in the wsdl:binding element and run SOAPTest.php. You will see that the server will call function operation2() twice, even though the SOAP action headers are different. -- Edit this bug report at http://bugs.php.net/?id=49169edit=1
#49155 [Opn]: SoapServer passes parameters as null if one has special wsdl definition
ID: 49155 User updated by: jeroen at asystance dot nl -Summary: SoapServer sometimes passes parameters as null Reported By: jeroen at asystance dot nl Status: Open Bug Type: SOAP related Operating System: linux PHP Version: 5.2SVN-2009-08-04 (snap) New Comment: I have been able to further pin down the bug. The 2nd parameter is passed as null if, in the wsdl:message definition, the 1st wsdl:part element's name attribute is the same as the element attribute! wsdl:message name=someRequest wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=fail element=tns:customerId/wsdl:part /wsdl:message Here the 1st parameter works, but the second is always null! wsdl:message name=someRequest wsdl:part name=cid element=tns:customerId/wsdl:part wsdl:part name=win element=tns:customerId/wsdl:part /wsdl:message Now both parameters work. More generally, if one wsdl:part is specified in this way (name and element are the same), _every other parameter_ is passed as null: wsdl:message name=someRequest wsdl:part name=p1 element=tns:customerId/wsdl:part wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=p3 element=tns:customerId/wsdl:part /wsdl:message Here, p1 and p2 will be null, and customerId will work. Happy bugfixing! :) Previous Comments: [2009-08-04 14:47:58] jeroen at asystance dot nl Description: I have a WSDL with three types: customerId, customer and order. Calling a function with just a customer works, but a calling a function with parameters (customerId, customer) does not - the customer parameter is always null. Another function, specified as (customerId, order), always works, so the problem is not using more than one parameter (which could be a problem since I'm using document/literal, and having more than one message part does not conform to WS-I). I have also tried switching the parameters and lots of other things but I cannot find the underlying problem. Reproduce code: --- http://jayvee.nl/soaptest.tar This includes a php file that runs a client as well as a server - so be sure to change the service URL in interface.wsdl before you run this. Expected result: When SoapServer calls function addCustomer ( $p1, $p2 ), $p2 should be a stdClass object (or array) Actual result: -- $p2 is null -- Edit this bug report at http://bugs.php.net/?id=49155edit=1
#49155 [Opn]: SoapServer passes parameters as null if one has special wsdl definition
ID: 49155 User updated by: jeroen at asystance dot nl Reported By: jeroen at asystance dot nl Status: Open Bug Type: SOAP related Operating System: linux PHP Version: 5.2SVN-2009-08-04 (snap) New Comment: Sorry for posting yet another comment, but it gets even weirder: wsdl:message name=someRequest wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=customerDetails element=tns:customer/wsdl:part /wsdl:message This will not work, because in the first part, the name==element However, wsdl:message name=someRequest wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=customer element=tns:customer/wsdl:part /wsdl:message _will_ work! Notice that now both parts are specified with name==element! My conclusion so far is that either _all_ of the parts need to be specified with the name==element pattern, or _none_. If one of the parts uses the pattern, the rest needs to conform, or else the SoapServer passes them as null. I sure hope this helps! I've been struggling with this for a while now. Previous Comments: [2009-08-05 11:53:25] jeroen at asystance dot nl I have been able to further pin down the bug. The 2nd parameter is passed as null if, in the wsdl:message definition, the 1st wsdl:part element's name attribute is the same as the element attribute! wsdl:message name=someRequest wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=fail element=tns:customerId/wsdl:part /wsdl:message Here the 1st parameter works, but the second is always null! wsdl:message name=someRequest wsdl:part name=cid element=tns:customerId/wsdl:part wsdl:part name=win element=tns:customerId/wsdl:part /wsdl:message Now both parameters work. More generally, if one wsdl:part is specified in this way (name and element are the same), _every other parameter_ is passed as null: wsdl:message name=someRequest wsdl:part name=p1 element=tns:customerId/wsdl:part wsdl:part name=customerId element=tns:customerId/wsdl:part wsdl:part name=p3 element=tns:customerId/wsdl:part /wsdl:message Here, p1 and p2 will be null, and customerId will work. Happy bugfixing! :) [2009-08-04 14:47:58] jeroen at asystance dot nl Description: I have a WSDL with three types: customerId, customer and order. Calling a function with just a customer works, but a calling a function with parameters (customerId, customer) does not - the customer parameter is always null. Another function, specified as (customerId, order), always works, so the problem is not using more than one parameter (which could be a problem since I'm using document/literal, and having more than one message part does not conform to WS-I). I have also tried switching the parameters and lots of other things but I cannot find the underlying problem. Reproduce code: --- http://jayvee.nl/soaptest.tar This includes a php file that runs a client as well as a server - so be sure to change the service URL in interface.wsdl before you run this. Expected result: When SoapServer calls function addCustomer ( $p1, $p2 ), $p2 should be a stdClass object (or array) Actual result: -- $p2 is null -- Edit this bug report at http://bugs.php.net/?id=49155edit=1
#49155 [NEW]: SoapServer sometimes passes parameters as null
From: jeroen at asystance dot nl Operating system: linux PHP version: 5.2SVN-2009-08-04 (snap) PHP Bug Type: SOAP related Bug description: SoapServer sometimes passes parameters as null Description: I have a WSDL with three types: customerId, customer and order. Calling a function with just a customer works, but a calling a function with parameters (customerId, customer) does not - the customer parameter is always null. Another function, specified as (customerId, order), always works, so the problem is not using more than one parameter (which could be a problem since I'm using document/literal, and having more than one message part does not conform to WS-I). I have also tried switching the parameters and lots of other things but I cannot find the underlying problem. Reproduce code: --- http://jayvee.nl/soaptest.tar This includes a php file that runs a client as well as a server - so be sure to change the service URL in interface.wsdl before you run this. Expected result: When SoapServer calls function addCustomer ( $p1, $p2 ), $p2 should be a stdClass object (or array) Actual result: -- $p2 is null -- Edit bug report at http://bugs.php.net/?id=49155edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49155r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49155r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49155r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49155r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49155r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49155r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49155r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49155r=needscript Try newer version: http://bugs.php.net/fix.php?id=49155r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49155r=support Expected behavior: http://bugs.php.net/fix.php?id=49155r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49155r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49155r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49155r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49155r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49155r=dst IIS Stability: http://bugs.php.net/fix.php?id=49155r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49155r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49155r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49155r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49155r=mysqlcfg
#48945 [NEW]: 5.3 VC6 x86 Thread Safe Windows Installer claims to contain version 5.2.9.9
From: jeroen dot hennekes at zonnet dot nl Operating system: Windows 2000 Professional PHP version: 5.3.0 PHP Bug Type: Windows Installer Bug description: 5.3 VC6 x86 Thread Safe Windows Installer claims to contain version 5.2.9.9 Description: After installing PHP 5.3.0 VC6 x86 Thread Safe MSI on 15-7-2009 11:00 the php.exe Version tab of the Properties window tell me it concernes: File version 5.2.9.9, Copyright © 1997-2007 The PHP Group (and Secunia PSI tells me to update the insecure version;-). What is the truth here? (php.exe Created/Modified columns show 25-2-2009 16:54) -- Edit bug report at http://bugs.php.net/?id=48945edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48945r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48945r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48945r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48945r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48945r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48945r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48945r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48945r=needscript Try newer version: http://bugs.php.net/fix.php?id=48945r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48945r=support Expected behavior: http://bugs.php.net/fix.php?id=48945r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48945r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48945r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48945r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48945r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48945r=dst IIS Stability: http://bugs.php.net/fix.php?id=48945r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48945r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48945r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48945r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48945r=mysqlcfg
#48945 [Bgs]: 5.3 VC6 x86 Thread Safe Windows Installer claims to contain version 5.2.9.9
ID: 48945 User updated by: jeroen dot hennekes at zonnet dot nl Reported By: jeroen dot hennekes at zonnet dot nl Status: Bogus Bug Type: Windows Installer Operating System: Windows 2000 Professional PHP Version: 5.3.0 New Comment: I did doublecheck: I used php-5.3.0-Win32-VC6-x86.msi from http://windows.php.net/download/ It is installed in xampp version 1.7.1. What else should I doublecheck? Previous Comments: [2009-07-16 14:01:14] paj...@php.net You are doing something wrong, double check your install. [2009-07-16 13:52:25] jeroen dot hennekes at zonnet dot nl Description: After installing PHP 5.3.0 VC6 x86 Thread Safe MSI on 15-7-2009 11:00 the php.exe Version tab of the Properties window tell me it concernes: File version 5.2.9.9, Copyright © 1997-2007 The PHP Group (and Secunia PSI tells me to update the insecure version;-). What is the truth here? (php.exe Created/Modified columns show 25-2-2009 16:54) -- Edit this bug report at http://bugs.php.net/?id=48945edit=1
#48945 [Bgs]: 5.3 VC6 x86 Thread Safe Windows Installer claims to contain version 5.2.9.9
ID: 48945 User updated by: jeroen dot hennekes at zonnet dot nl Reported By: jeroen dot hennekes at zonnet dot nl Status: Bogus Bug Type: Windows Installer Operating System: Windows 2000 Professional PHP Version: 5.3.0 New Comment: Sorry, you must be correct: I must have skipped installing the 5.3. xampp still has to update php to 5.3 (xampp 1.7.1 contains php 5.2.9). Previous Comments: [2009-07-16 14:18:38] jeroen dot hennekes at zonnet dot nl I did doublecheck: I used php-5.3.0-Win32-VC6-x86.msi from http://windows.php.net/download/ It is installed in xampp version 1.7.1. What else should I doublecheck? [2009-07-16 14:01:14] paj...@php.net You are doing something wrong, double check your install. [2009-07-16 13:52:25] jeroen dot hennekes at zonnet dot nl Description: After installing PHP 5.3.0 VC6 x86 Thread Safe MSI on 15-7-2009 11:00 the php.exe Version tab of the Properties window tell me it concernes: File version 5.2.9.9, Copyright © 1997-2007 The PHP Group (and Secunia PSI tells me to update the insecure version;-). What is the truth here? (php.exe Created/Modified columns show 25-2-2009 16:54) -- Edit this bug report at http://bugs.php.net/?id=48945edit=1
#22513 [Com]: imagettfbbox() returning bogus array values
ID: 22513
Comment by: jeroen at unfix dot org
Reported By: jeremy at nirvani dot net
Status: No Feedback
Bug Type: GD related
Operating System: linux 2.4.19
PHP Version: 5CVS-2003-03-03 (dev)
New Comment:
Clearly this is a multithreading kind of issue which still happens, it
apparently is really difficult to use mutexes or simply write re-entrant
code. Nevertheless for people getting this, just use, as a very dirty
hack:
$size = ImageTTFBbox($fontsize, 0, $fontfile, $txt);
$try = 1;
while ($size[2] 0 $try 10) $size = ImageTTFBbox($fontsize, 0,
$fontfile, $txt);
et voila, $size should mostly be okay ;)
Previous Comments:
[2004-11-16 18:45:04] Jason at amp-design dot net
I have had the same problems with PHP 5.0.2.
I have found fiddling with the ./configure parameters for ttf rendering
when compiling PHP will help resolve some of the problems. However I
still find that text looks distorted under Linux when compared to Mac
[2003-08-10 21:35:34] nick at itomic dot com
as you will notice if you look at the example URL, it works fine. I
compiled with the system library of GD, instead of the internal GD
library. It now works fine.
[2003-08-08 06:33:08] nick at itomic dot com
ok I am getting these strange values, on php4.3.2 with apache 1.3.28.
on redhat 7.2, with imagettfbbox
here is some example dump:
width -1073758320 : height -5379645430array(8) {
[0]=
int(60)
[1]=
int(-1073758256)
[2]=
int(-1073758264)
[3]=
int(1077688217)
[4]=
int(48)
[5]=
int(0)
[6]=
int(11288)
[7]=
int(1078099916)
}
here is a url that will reproduce:
http://test.earth.itomic.com/build_text_image.php?imgStr=PRODUCT%20SPOTLIGHTfontSize=14font=v5loxicar
the source is here:
http://test.earth.itomic.com/build_text_image.php.txt
If this has been fixed in CVS, is there a version that works? or is
there one that will be coming soon?
[2003-06-26 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over 2 weeks, 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.
[2003-06-10 19:15:11] [EMAIL PROTECTED]
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
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/22513
--
Edit this bug report at http://bugs.php.net/?id=22513edit=1
#45981 [NEW]: function escapeshellarg excessively quotes single quotes
From: jeroen at asystance dot nl
Operating system: debian linux
PHP version: 5.2CVS-2008-09-03 (snap)
PHP Bug Type: Unknown/Other Function
Bug description: function escapeshellarg excessively quotes single quotes
Description:
escapeshellarg inserts single quotes (') before and after an escaped
single quote
I observed the bug in 5.2.6-3 and the php5.3-200809031030 CVS snapshot
Reproduce code:
---
?php
echo escapeshellarg(single ' quote) . \n;
echo escapeshellarg('single \' quote') . \n;
?
Expected result:
'single \' quote'
'single \' quote'
Actual result:
--
'single '\'' quote'
'single '\'' quote'
--
Edit bug report at http://bugs.php.net/?id=45981edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45981r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45981r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45981r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45981r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45981r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45981r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45981r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45981r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45981r=support
Expected behavior:http://bugs.php.net/fix.php?id=45981r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45981r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45981r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45981r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45981r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45981r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45981r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45981r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45981r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45981r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45981r=mysqlcfg
#44869 [Opn]: MSSQL Connect = Access Violation
ID: 44869 User updated by: vds dot jeroen at gmail dot com Reported By: vds dot jeroen at gmail dot com Status: Open Bug Type: MSSQL related Operating System: Windows XP SP2 -PHP Version: 5.2.6RC5 +PHP Version: 5.2.6 New Comment: It's working when I use FreeTDS. Previous Comments: [2008-05-07 17:16:53] vds dot jeroen at gmail dot com I still have the same problem with 5.2.6 final [2008-04-30 12:52:15] vds dot jeroen at gmail dot com Description: When trying to connect to a local MSSQL 2005 Express server using mssql_connect() in combination with IIS 5.1 on Windows XP SP2, I get this error: PHP has encountered an Access Violation at 7333F15A When I run the script some more, I get this error. PHP has encountered an Access Violation at 7333F179 When I run the script some more, I don't have a problem. When I connect to another MSSQL server than my local one, I don't have a problem at all. I tried it with PHP 5.2.5 and 5.2.6RC5 I'm not the only one with this problem: http://www.php.ru/forum/viewtopic.php?p=43508sid=f670026df23ed66bcbed99e77344bc52 http://bugs.php.net/bug.php?id=44718 When I use Apache 2.2.2, Apache crashes with PHP 5.2.5 when trying to connect. BTW: I'm using the newer ntwdblib.dll (2000.80.194.0) Reproduce code: --- $username = sa; $password = *; $database = plrapport; $conn = mssql_connect(LAPTOPHP\SQLEXPRESS,$username,$password); Expected result: Nothing should happen, but the connection should be made. I check if the connection is made by running a query. Actual result: -- When I just try to connect, with or without issueing a query, I get PHP has encountered an Access Violation at 7333F15A I tried to make a backtrace, but I ended up with a very long mht file. Download it here: http://maybeme.be/Downloads/CrashHang_Report__PID_3208(2_dumps)__PID_668(2_dumps)__04302008142359968.mht -- Edit this bug report at http://bugs.php.net/?id=44869edit=1
#44869 [Opn]: MSSQL Connect = Access Violation
ID: 44869 User updated by: vds dot jeroen at gmail dot com Reported By: vds dot jeroen at gmail dot com Status: Open Bug Type: MSSQL related Operating System: Windows XP SP2 PHP Version: 5.2.6RC5 New Comment: I still have the same problem with 5.2.6 final Previous Comments: [2008-04-30 12:52:15] vds dot jeroen at gmail dot com Description: When trying to connect to a local MSSQL 2005 Express server using mssql_connect() in combination with IIS 5.1 on Windows XP SP2, I get this error: PHP has encountered an Access Violation at 7333F15A When I run the script some more, I get this error. PHP has encountered an Access Violation at 7333F179 When I run the script some more, I don't have a problem. When I connect to another MSSQL server than my local one, I don't have a problem at all. I tried it with PHP 5.2.5 and 5.2.6RC5 I'm not the only one with this problem: http://www.php.ru/forum/viewtopic.php?p=43508sid=f670026df23ed66bcbed99e77344bc52 http://bugs.php.net/bug.php?id=44718 When I use Apache 2.2.2, Apache crashes with PHP 5.2.5 when trying to connect. BTW: I'm using the newer ntwdblib.dll (2000.80.194.0) Reproduce code: --- $username = sa; $password = *; $database = plrapport; $conn = mssql_connect(LAPTOPHP\SQLEXPRESS,$username,$password); Expected result: Nothing should happen, but the connection should be made. I check if the connection is made by running a query. Actual result: -- When I just try to connect, with or without issueing a query, I get PHP has encountered an Access Violation at 7333F15A I tried to make a backtrace, but I ended up with a very long mht file. Download it here: http://maybeme.be/Downloads/CrashHang_Report__PID_3208(2_dumps)__PID_668(2_dumps)__04302008142359968.mht -- Edit this bug report at http://bugs.php.net/?id=44869edit=1
#44869 [NEW]: MSSQL Connect = Access Violation
From: vds dot jeroen at gmail dot com Operating system: Windows XP SP2 PHP version: 5.2.6RC5 PHP Bug Type: MSSQL related Bug description: MSSQL Connect = Access Violation Description: When trying to connect to a local MSSQL 2005 Express server using mssql_connect() in combination with IIS 5.1 on Windows XP SP2, I get this error: PHP has encountered an Access Violation at 7333F15A When I run the script some more, I get this error. PHP has encountered an Access Violation at 7333F179 When I run the script some more, I don't have a problem. When I connect to another MSSQL server than my local one, I don't have a problem at all. I tried it with PHP 5.2.5 and 5.2.6RC5 I'm not the only one with this problem: http://www.php.ru/forum/viewtopic.php?p=43508sid=f670026df23ed66bcbed99e77344bc52 http://bugs.php.net/bug.php?id=44718 When I use Apache 2.2.2, Apache crashes with PHP 5.2.5 when trying to connect. BTW: I'm using the newer ntwdblib.dll (2000.80.194.0) Reproduce code: --- $username = sa; $password = *; $database = plrapport; $conn = mssql_connect(LAPTOPHP\SQLEXPRESS,$username,$password); Expected result: Nothing should happen, but the connection should be made. I check if the connection is made by running a query. Actual result: -- When I just try to connect, with or without issueing a query, I get PHP has encountered an Access Violation at 7333F15A I tried to make a backtrace, but I ended up with a very long mht file. Download it here: http://maybeme.be/Downloads/CrashHang_Report__PID_3208(2_dumps)__PID_668(2_dumps)__04302008142359968.mht -- Edit bug report at http://bugs.php.net/?id=44869edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44869r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44869r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44869r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44869r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44869r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44869r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44869r=needscript Try newer version:http://bugs.php.net/fix.php?id=44869r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44869r=support Expected behavior:http://bugs.php.net/fix.php?id=44869r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44869r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44869r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44869r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44869r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44869r=dst IIS Stability:http://bugs.php.net/fix.php?id=44869r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44869r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44869r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44869r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44869r=mysqlcfg
#16263 [Com]: session.start() create new empty session file and not resume existing session
ID: 16263 Comment by: jeroen at haan dot net Reported By: kur at natur dot cuni dot cz Status: No Feedback Bug Type: Session related Operating System: ANY PHP Version: 4.3.0-dev New Comment: Changing the character set from utf-8 to the old iso-8859-1 helped. Now a session cookie is succesfully stored on the client and thereby the sessid and thus one file on the server maintained. However I do not understand this behavior. Previous Comments: [2006-04-26 07:00:18] sunmt at usa dot com I expereinced the same problem in PHP 5.0.5 Reading\Writing to session works in the same page but the server loses the session when going between different pages or reloading the page. Please help me.. [2006-02-16 21:16:24] optikey at gmail dot com Same problem with 5.0.5 running on Debian x86_64... Only I.E. does this 2 cookies thing and scroolled my code... Digging the net, i found that those bugs started only in the browsers that executes windows update automatically... So i find that the day that the problems started matches the day of the release of one Microsoft Bugfix that affects I.E. 14/feb/2006 Only the updated browsers behave incorrectly Might we need to blame M$ Any workarounds??? Am i right??? MS did not return the bug report... [2006-02-15 17:05:12] bohn at netbuild dot net got same problem under using php 4.3.10 :( on heavy load, php creates a new session... fc3, apache2, php4.3.10, lvs [2006-01-30 22:21:11] geso at inmail dot sk I've got same problem with 5.1.2 (and previously with 4.3.8). Both clean install, Win2k, IIS 5.0. Everytime I enter (reload) a page, it creates a new file in my sessions directory. [2005-11-15 16:25:07] f dot schiappelli at enpam dot it Same problem with PHP 5.0.2, Apache 2.0.52, Windows XP. Did anybody solved the problem? Thanks in advance, Faith 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/16263 -- Edit this bug report at http://bugs.php.net/?id=16263edit=1
#34249 [Fbk-Csd]: apache crash / error on php error document
ID: 34249 User updated by: jeroen at terena dot nl Reported By: jeroen at terena dot nl -Status: Feedback +Status: Closed Bug Type: Reproducible crash Operating System: Debian Linux PHP Version: 5.1.0RC1 New Comment: Yep, it works fine with the CVS version. Previous Comments: [2005-08-25 17:04:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-08-25 16:23:41] jeroen at terena dot nl Description: Please see http://bugs.php.net/bug.php?id=33987 I'm still experiencing the same bug in 5.1RC1 Any custom error document other than a PHP document works. If I use a PHP document no code gets executed it just seems to ignore the error document. Occaisionally I get an even weirder response like Apache trying to send the original file (jpeg in my case) anyway. This ofcourse doesn't work. I'm using PHP5.1RC1, Apache2 on Debian Linux. Reproduce code: --- .htaccess ErrorDocument 404 /404.php 404.php can leave it empty Expected result: empty page or whatever code was put in 404.php Actual result: -- nothing. displays referring page in mozilla. IE shows its page could not be displayed document. -- Edit this bug report at http://bugs.php.net/?id=34249edit=1
#34249 [NEW]: apache crash / error on php error document
From: jeroen at terena dot nl Operating system: Debian Linux PHP version: 5.1.0RC1 PHP Bug Type: Reproducible crash Bug description: apache crash / error on php error document Description: Please see http://bugs.php.net/bug.php?id=33987 I'm still experiencing the same bug in 5.1RC1 Any custom error document other than a PHP document works. If I use a PHP document no code gets executed it just seems to ignore the error document. Occaisionally I get an even weirder response like Apache trying to send the original file (jpeg in my case) anyway. This ofcourse doesn't work. I'm using PHP5.1RC1, Apache2 on Debian Linux. Reproduce code: --- .htaccess ErrorDocument 404 /404.php 404.php can leave it empty Expected result: empty page or whatever code was put in 404.php Actual result: -- nothing. displays referring page in mozilla. IE shows its page could not be displayed document. -- Edit bug report at http://bugs.php.net/?id=34249edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34249r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34249r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34249r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34249r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34249r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34249r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34249r=needscript Try newer version: http://bugs.php.net/fix.php?id=34249r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34249r=support Expected behavior: http://bugs.php.net/fix.php?id=34249r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34249r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34249r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34249r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34249r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34249r=dst IIS Stability: http://bugs.php.net/fix.php?id=34249r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34249r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34249r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34249r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34249r=mysqlcfg
#27552 [Fbk-Csd]: fwrite fails after writing 8k bytes
ID: 27552
User updated by: jeroen dot pulles at redslider dot net
Reported By: jeroen dot pulles at redslider dot net
-Status: Feedback
+Status: Closed
Bug Type: Sockets related
Operating System: win32
PHP Version: 5CVS-2004-03-10 (dev)
Assigned To: wez
New Comment:
The problem seems to have disappeared; Just tested
the reproduce code using 5.1.0-dev ('latest'),
and it ran fine.
Hoera!
-- jeroen
Previous Comments:
[2004-08-17 08:08:09] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2004-08-17 00:29:38] ulf at haueisen dot net
I think this is a duplicate of 29256 and fixed in PHP 5.0.1
Thanks,
Ulf.
[2004-07-21 13:48:56] ulf at haueisen dot net
btw: It does work correctly with PHP 4.3.8.
[2004-07-21 12:57:25] ulf at haueisen dot net
I experience the same with PHP 5.0.0 final on Windows Server 2003 using
PEAR HTTP_Request while sending more than 8k POST-Data.
[2004-04-13 17:47:08] jeroen dot pulles at redslider dot net
I am still experiencing the problem with 5.0.0.0 RC2-dev (April 12th
windows snapshot).
I tried the code on two networks. One network has a transparent
firewall as far as HTTP traffic is concerned. The other is my home
network, behind a simple router/nat solution. I have no reason to
believe anything is tampering the data; Especially since a smaller
message body _does_ work.
I put up a simple test case on my website:
http://www.redslider.net/test01/
I have no problem running fwrite_test.php with a small message size.
However, the code still breaks when writing more than 8192 bytes.
What I find weird is that the code runs fine, in any case, on a
localhost webserver/website, but breaks on any remote host,
irrespective of webserver software etcetera etcetera. I'm puzzled.
Help is appreciated,
jeroen
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/27552
--
Edit this bug report at http://bugs.php.net/?id=27552edit=1
#29345 [Fbk-Opn]: Working directory has changed
ID: 29345 User updated by: jeroen at kessels dot com Reported By: jeroen at kessels dot com -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Windows 2000 PHP Version: 5.0.0 New Comment: Ah! Yes, changing to php-cgi.exe solves the problem. I followed the manual installation instructions (the install.txt file in the ZIP download), which clearly say to use php.exe. I guess it needs to be rewritten. I can't find any information about the php-cgi.exe program, not there and not on this website. Previous Comments: [2004-07-30 00:38:58] [EMAIL PROTECTED] Which sapi are you using? If its cgi please make sure to use php-cgi.exe [2004-07-23 01:24:24] jeroen at kessels dot com Description: In PHP4 the working directory is the directory where the script lives. In PHP5 it's the root of the website. This has a huge impact on scripts that use the filesystem functions to access local files. For example, the getcwd() function in a script called c:/inetpub/wwwroot/work/test.php will report c:\inetpub\wwwroot\work on PHP4, and c:\inetpub\wwwroot on PHP5. I have only Windows 2000 with IIS at my disposal, I've not tested on Linux and Apache. Reproduce code: --- echo getcwd(); Expected result: The directory where the script lives. Actual result: -- The home directory of the website. -- Edit this bug report at http://bugs.php.net/?id=29345edit=1
#29232 [Fbk-Opn]: imagefilltoborder not filling downwards
ID: 29232 User updated by: jeroen dot clarysse at easynet dot be Reported By: jeroen dot clarysse at easynet dot be -Status: Feedback +Status: Open Bug Type: GD related Operating System: MacOS 10.3.4 PHP Version: 4.3.8 New Comment: okay. It works now. Thanks. The problem must be in the compiled entropy installer. Previous Comments: [2004-07-23 01:10:48] [EMAIL PROTECTED] 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 [2004-07-17 22:10:56] jeroen dot clarysse at easynet dot be Description: the imagefilltoborder call will flood fill upwards only. it's pretty easy to see : http:// ldab.arts.kuleuven.ac.be/gdtest.php I ran it on 3 other macs, clean installs with the PHP module from www.entropy.ch, which has very good fame among OSX people. the weird part is that linux code works fine... I downloaded sources from 4.3.6 up to 4.3.9, and compared the gdImageFillToBorder calls. They are identical (even the original GD from Boutell has the same code) so I really don't know what could be wrong. cheers Reproduce code: --- header(Content-type: image/png); // create a blank image $image = imagecreate(400, 300); // fill the background color $bg = imagecolorallocate($image, 0, 0, 0); // choose a color for the ellipse $col_ellipse = imagecolorallocate($image, 255, 255, 255); // draw the ellipse imageellipse($image, 200, 150, 300, 200, $col_ellipse); imagefilltoborder($image, 200, 150, $col_ellipse,$col_ellipse); // output the picture header(Content-type: image/png); imagejpeg($image); Expected result: a fully white ellipse on a black square Actual result: -- on a black square, an ellipse with white border, upper half filled white -- Edit this bug report at http://bugs.php.net/?id=29232edit=1
#29345 [NEW]: Working directory has changed
From: jeroen at kessels dot com Operating system: Windows 2000 PHP version: 5.0.0 PHP Bug Type: Filesystem function related Bug description: Working directory has changed Description: In PHP4 the working directory is the directory where the script lives. In PHP5 it's the root of the website. This has a huge impact on scripts that use the filesystem functions to access local files. For example, the getcwd() function in a script called c:/inetpub/wwwroot/work/test.php will report c:\inetpub\wwwroot\work on PHP4, and c:\inetpub\wwwroot on PHP5. I have only Windows 2000 with IIS at my disposal, I've not tested on Linux and Apache. Reproduce code: --- echo getcwd(); Expected result: The directory where the script lives. Actual result: -- The home directory of the website. -- Edit bug report at http://bugs.php.net/?id=29345edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29345r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29345r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29345r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29345r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29345r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29345r=needscript Try newer version: http://bugs.php.net/fix.php?id=29345r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29345r=support Expected behavior: http://bugs.php.net/fix.php?id=29345r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29345r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29345r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29345r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29345r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29345r=dst IIS Stability: http://bugs.php.net/fix.php?id=29345r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29345r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29345r=float
#29232 [NEW]: imagefilltoborder not filling downwards
From: jeroen dot clarysse at easynet dot be Operating system: MacOS 10.3.4 PHP version: 4.3.8 PHP Bug Type: GD related Bug description: imagefilltoborder not filling downwards Description: the imagefilltoborder call will flood fill upwards only. it's pretty easy to see : http:// ldab.arts.kuleuven.ac.be/gdtest.php I ran it on 3 other macs, clean installs with the PHP module from www.entropy.ch, which has very good fame among OSX people. the weird part is that linux code works fine... I downloaded sources from 4.3.6 up to 4.3.9, and compared the gdImageFillToBorder calls. They are identical (even the original GD from Boutell has the same code) so I really don't know what could be wrong. cheers Reproduce code: --- header(Content-type: image/png); // create a blank image $image = imagecreate(400, 300); // fill the background color $bg = imagecolorallocate($image, 0, 0, 0); // choose a color for the ellipse $col_ellipse = imagecolorallocate($image, 255, 255, 255); // draw the ellipse imageellipse($image, 200, 150, 300, 200, $col_ellipse); imagefilltoborder($image, 200, 150, $col_ellipse,$col_ellipse); // output the picture header(Content-type: image/png); imagejpeg($image); Expected result: a fully white ellipse on a black square Actual result: -- on a black square, an ellipse with white border, upper half filled white -- Edit bug report at http://bugs.php.net/?id=29232edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29232r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29232r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29232r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29232r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29232r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29232r=needscript Try newer version: http://bugs.php.net/fix.php?id=29232r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29232r=support Expected behavior: http://bugs.php.net/fix.php?id=29232r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29232r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29232r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29232r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29232r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29232r=dst IIS Stability: http://bugs.php.net/fix.php?id=29232r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29232r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29232r=float
#27552 [NoF-Opn]: fwrite fails after writing 8k bytes
ID: 27552
User updated by: jeroen dot pulles at redslider dot net
Reported By: jeroen dot pulles at redslider dot net
-Status: No Feedback
+Status: Open
Bug Type: Sockets related
Operating System: win32
PHP Version: 5CVS-2004-03-10 (dev)
New Comment:
I am still experiencing the problem with 5.0.0.0 RC2-dev (April 12th
windows snapshot).
I tried the code on two networks. One network has a transparent
firewall as far as HTTP traffic is concerned. The other is my home
network, behind a simple router/nat solution. I have no reason to
believe anything is tampering the data; Especially since a smaller
message body _does_ work.
I put up a simple test case on my website:
http://www.redslider.net/test01/
I have no problem running fwrite_test.php with a small message size.
However, the code still breaks when writing more than 8192 bytes.
What I find weird is that the code runs fine, in any case, on a
localhost webserver/website, but breaks on any remote host,
irrespective of webserver software etcetera etcetera. I'm puzzled.
Help is appreciated,
jeroen
Previous Comments:
[2004-04-12 17:56:56] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2004-04-07 06:03:29] [EMAIL PROTECTED]
I can't reproduce this either. Are you sure there isn't some firewall
or something in between that might somehow break this..?
[2004-03-11 02:53:07] jeroen dot pulles at redslider dot net
I am using the latest windows binary snapshot.
(It's just that I'm not using the regular cmd.exe for command line
work, but cygwin's bash.exe shell; Which is probably irrelevant anyway.
For the record: I get the same result when running the reproduce code
from cmd.exe.)
[2004-03-10 12:06:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try a real windows binary, not a cygwin emulation and see if the
problem persists.
[2004-03-10 11:39:19] jeroen dot pulles at redslider dot net
Description:
When writing data to a socket, the program fails when writing more than
8192 bytes, irrespective of a given buffersize.
Specifics:
- Windows 2000
- 5.0.0.0 RC1-dev (-200403101130)
- Command line interface (using cygwin)
- Almost no modules, just php_sockets.dll
- Default php.ini(-dist), apart from
E_ALL for the error logging
Note:
The socket shouldn't be blocking, I didn't ask for it, and
set_stream_blocking(true) doesn't change it; I'm guessing this is some
irrelevant (for me) implementation detail for PHP.
Note:
Writing to localhost does work.
Note:
Writing less than 8192 bytes does work (well, didn't check the exact
size where failure starts to happen).
Note:
No problems on my Linux box and PHP 5.*.
Reproduce code:
---
?php
$socket = fsockopen('some-other-host', 80, $errno, $errmessage);
$message_body = '';
for ($i = 0; $i 4000; $i++) $message_body .= 'yadda ';
$contentlength = strlen($message_body);
$message = POST / HTTP/1.0\r\n;
$message .= Host: some-other-host\r\n;
$message .= Content-Type: text/plain\r\n;
$message .= Content-Length: $contentlength\r\n;
$message .= \r\n;
$message .= $message_body;
fwrite($socket, $message);
fclose($socket);
print($errmessage);
print(Done\n);
?
Expected result:
Expecting to just see Done
Actual result:
--
[EMAIL PROTECTED] bin/php fwrite-bug.php
Notice: fwrite(): send of 8192 bytes failed with errno=0 A non-blocking
socket o
peration could not be completed immediately.
in C:\home\wwwroot\aria\fwrite-bug.php on line 12
Done
--
Edit this bug report at http://bugs.php.net/?id=27552edit=1
#27552 [Fbk-Opn]: fwrite fails after writing 8k bytes
ID: 27552
User updated by: jeroen dot pulles at redslider dot net
Reported By: jeroen dot pulles at redslider dot net
-Status: Feedback
+Status: Open
Bug Type: Sockets related
Operating System: Windows 2000
PHP Version: 5CVS-2004-03-10 (dev)
New Comment:
I am using the latest windows binary snapshot.
(It's just that I'm not using the regular cmd.exe for command line
work, but cygwin's bash.exe shell; Which is probably irrelevant anyway.
For the record: I get the same result when running the reproduce code
from cmd.exe.)
Previous Comments:
[2004-03-10 12:06:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try a real windows binary, not a cygwin emulation and see if the
problem persists.
[2004-03-10 11:39:19] jeroen dot pulles at redslider dot net
Description:
When writing data to a socket, the program fails when writing more than
8192 bytes, irrespective of a given buffersize.
Specifics:
- Windows 2000
- 5.0.0.0 RC1-dev (-200403101130)
- Command line interface (using cygwin)
- Almost no modules, just php_sockets.dll
- Default php.ini(-dist), apart from
E_ALL for the error logging
Note:
The socket shouldn't be blocking, I didn't ask for it, and
set_stream_blocking(true) doesn't change it; I'm guessing this is some
irrelevant (for me) implementation detail for PHP.
Note:
Writing to localhost does work.
Note:
Writing less than 8192 bytes does work (well, didn't check the exact
size where failure starts to happen).
Note:
No problems on my Linux box and PHP 5.*.
Reproduce code:
---
?php
$socket = fsockopen('some-other-host', 80, $errno, $errmessage);
$message_body = '';
for ($i = 0; $i 4000; $i++) $message_body .= 'yadda ';
$contentlength = strlen($message_body);
$message = POST / HTTP/1.0\r\n;
$message .= Host: some-other-host\r\n;
$message .= Content-Type: text/plain\r\n;
$message .= Content-Length: $contentlength\r\n;
$message .= \r\n;
$message .= $message_body;
fwrite($socket, $message);
fclose($socket);
print($errmessage);
print(Done\n);
?
Expected result:
Expecting to just see Done
Actual result:
--
[EMAIL PROTECTED] bin/php fwrite-bug.php
Notice: fwrite(): send of 8192 bytes failed with errno=0 A non-blocking
socket o
peration could not be completed immediately.
in C:\home\wwwroot\aria\fwrite-bug.php on line 12
Done
--
Edit this bug report at http://bugs.php.net/?id=27552edit=1
#27552 [Opn-Bgs]: fwrite fails after writing 8k bytes
ID: 27552
User updated by: jeroen dot pulles at redslider dot net
Reported By: jeroen dot pulles at redslider dot net
-Status: Open
+Status: Bogus
Bug Type: Sockets related
Operating System: Windows 2000
PHP Version: 5CVS-2004-03-10 (dev)
New Comment:
The reproduce code runs fine on other computers running Windows XP and
2000. So I'll have to take a good look at my computer :-(
Previous Comments:
[2004-03-11 02:53:07] jeroen dot pulles at redslider dot net
I am using the latest windows binary snapshot.
(It's just that I'm not using the regular cmd.exe for command line
work, but cygwin's bash.exe shell; Which is probably irrelevant anyway.
For the record: I get the same result when running the reproduce code
from cmd.exe.)
[2004-03-10 12:06:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try a real windows binary, not a cygwin emulation and see if the
problem persists.
[2004-03-10 11:39:19] jeroen dot pulles at redslider dot net
Description:
When writing data to a socket, the program fails when writing more than
8192 bytes, irrespective of a given buffersize.
Specifics:
- Windows 2000
- 5.0.0.0 RC1-dev (-200403101130)
- Command line interface (using cygwin)
- Almost no modules, just php_sockets.dll
- Default php.ini(-dist), apart from
E_ALL for the error logging
Note:
The socket shouldn't be blocking, I didn't ask for it, and
set_stream_blocking(true) doesn't change it; I'm guessing this is some
irrelevant (for me) implementation detail for PHP.
Note:
Writing to localhost does work.
Note:
Writing less than 8192 bytes does work (well, didn't check the exact
size where failure starts to happen).
Note:
No problems on my Linux box and PHP 5.*.
Reproduce code:
---
?php
$socket = fsockopen('some-other-host', 80, $errno, $errmessage);
$message_body = '';
for ($i = 0; $i 4000; $i++) $message_body .= 'yadda ';
$contentlength = strlen($message_body);
$message = POST / HTTP/1.0\r\n;
$message .= Host: some-other-host\r\n;
$message .= Content-Type: text/plain\r\n;
$message .= Content-Length: $contentlength\r\n;
$message .= \r\n;
$message .= $message_body;
fwrite($socket, $message);
fclose($socket);
print($errmessage);
print(Done\n);
?
Expected result:
Expecting to just see Done
Actual result:
--
[EMAIL PROTECTED] bin/php fwrite-bug.php
Notice: fwrite(): send of 8192 bytes failed with errno=0 A non-blocking
socket o
peration could not be completed immediately.
in C:\home\wwwroot\aria\fwrite-bug.php on line 12
Done
--
Edit this bug report at http://bugs.php.net/?id=27552edit=1
#27552 [Bgs-Opn]: fwrite fails after writing 8k bytes
ID: 27552
User updated by: jeroen dot pulles at redslider dot net
Reported By: jeroen dot pulles at redslider dot net
-Status: Bogus
+Status: Open
Bug Type: Sockets related
Operating System: Windows 2000
PHP Version: 5CVS-2004-03-10 (dev)
New Comment:
Oops, forgot to add a php.ini with E_ALL on the other computers. 'turns
out they all have the same error.
Previous Comments:
[2004-03-11 03:13:46] jeroen dot pulles at redslider dot net
The reproduce code runs fine on other computers running Windows XP and
2000. So I'll have to take a good look at my computer :-(
[2004-03-11 02:53:07] jeroen dot pulles at redslider dot net
I am using the latest windows binary snapshot.
(It's just that I'm not using the regular cmd.exe for command line
work, but cygwin's bash.exe shell; Which is probably irrelevant anyway.
For the record: I get the same result when running the reproduce code
from cmd.exe.)
[2004-03-10 12:06:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try a real windows binary, not a cygwin emulation and see if the
problem persists.
[2004-03-10 11:39:19] jeroen dot pulles at redslider dot net
Description:
When writing data to a socket, the program fails when writing more than
8192 bytes, irrespective of a given buffersize.
Specifics:
- Windows 2000
- 5.0.0.0 RC1-dev (-200403101130)
- Command line interface (using cygwin)
- Almost no modules, just php_sockets.dll
- Default php.ini(-dist), apart from
E_ALL for the error logging
Note:
The socket shouldn't be blocking, I didn't ask for it, and
set_stream_blocking(true) doesn't change it; I'm guessing this is some
irrelevant (for me) implementation detail for PHP.
Note:
Writing to localhost does work.
Note:
Writing less than 8192 bytes does work (well, didn't check the exact
size where failure starts to happen).
Note:
No problems on my Linux box and PHP 5.*.
Reproduce code:
---
?php
$socket = fsockopen('some-other-host', 80, $errno, $errmessage);
$message_body = '';
for ($i = 0; $i 4000; $i++) $message_body .= 'yadda ';
$contentlength = strlen($message_body);
$message = POST / HTTP/1.0\r\n;
$message .= Host: some-other-host\r\n;
$message .= Content-Type: text/plain\r\n;
$message .= Content-Length: $contentlength\r\n;
$message .= \r\n;
$message .= $message_body;
fwrite($socket, $message);
fclose($socket);
print($errmessage);
print(Done\n);
?
Expected result:
Expecting to just see Done
Actual result:
--
[EMAIL PROTECTED] bin/php fwrite-bug.php
Notice: fwrite(): send of 8192 bytes failed with errno=0 A non-blocking
socket o
peration could not be completed immediately.
in C:\home\wwwroot\aria\fwrite-bug.php on line 12
Done
--
Edit this bug report at http://bugs.php.net/?id=27552edit=1
#27552 [NEW]: fwrite fails after writing 8k bytes
From: jeroen dot pulles at redslider dot net
Operating system: Windows 2000
PHP version: 5CVS-2004-03-10 (dev)
PHP Bug Type: Sockets related
Bug description: fwrite fails after writing 8k bytes
Description:
When writing data to a socket, the program fails when writing more than
8192 bytes, irrespective of a given buffersize.
Specifics:
- Windows 2000
- 5.0.0.0 RC1-dev (-200403101130)
- Command line interface (using cygwin)
- Almost no modules, just php_sockets.dll
- Default php.ini(-dist), apart from
E_ALL for the error logging
Note:
The socket shouldn't be blocking, I didn't ask for it, and
set_stream_blocking(true) doesn't change it; I'm guessing this is some
irrelevant (for me) implementation detail for PHP.
Note:
Writing to localhost does work.
Note:
Writing less than 8192 bytes does work (well, didn't check the exact size
where failure starts to happen).
Note:
No problems on my Linux box and PHP 5.*.
Reproduce code:
---
?php
$socket = fsockopen('some-other-host', 80, $errno, $errmessage);
$message_body = '';
for ($i = 0; $i 4000; $i++) $message_body .= 'yadda ';
$contentlength = strlen($message_body);
$message = POST / HTTP/1.0\r\n;
$message .= Host: some-other-host\r\n;
$message .= Content-Type: text/plain\r\n;
$message .= Content-Length: $contentlength\r\n;
$message .= \r\n;
$message .= $message_body;
fwrite($socket, $message);
fclose($socket);
print($errmessage);
print(Done\n);
?
Expected result:
Expecting to just see Done
Actual result:
--
[EMAIL PROTECTED] bin/php fwrite-bug.php
Notice: fwrite(): send of 8192 bytes failed with errno=0 A non-blocking
socket o
peration could not be completed immediately.
in C:\home\wwwroot\aria\fwrite-bug.php on line 12
Done
--
Edit bug report at http://bugs.php.net/?id=27552edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27552r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27552r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27552r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27552r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27552r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27552r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27552r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27552r=support
Expected behavior: http://bugs.php.net/fix.php?id=27552r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27552r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27552r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27552r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27552r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27552r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27552r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27552r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27552r=float
#26752 [NEW]: fgets can't take variable as buffer length argument
From: jeroen dot pulles at redslider dot net
Operating system: Windows 2000
PHP version: 5.0.0b3 (beta3)
PHP Bug Type: Filesystem function related
Bug description: fgets can't take variable as buffer length argument
Description:
fgets expects a literal for the buffer size argument. It hangs until the
max_execution_time timeouts, when you give it a variable.
Reproduce code:
---
$url = 'http://www.google.com/';
if (($handle = fopen($url, 'r')) === false) {
die('Couldnt open url '.$url.'.');
}
while (feof($handle) === false) {
$text = fgets($handle, $kBufferSize); // doesn't work
//$text = fgets($handle, 512); // works
echo($text);
}
fclose($handle);
Expected result:
The google homepage (i.e. the given url)
Actual result:
--
Timeout on max_execution_time.
--
Edit bug report at http://bugs.php.net/?id=26752edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26752r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26752r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26752r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26752r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26752r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26752r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26752r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26752r=support
Expected behavior: http://bugs.php.net/fix.php?id=26752r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26752r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26752r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26752r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26752r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26752r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26752r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26752r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26752r=float
#26752 [Opn]: fgets can't take variable as buffer length argument
ID: 26752
User updated by: jeroen dot pulles at redslider dot net
Reported By: jeroen dot pulles at redslider dot net
Status: Open
Bug Type: Filesystem function related
Operating System: Windows 2000
PHP Version: 5.0.0b3 (beta3)
New Comment:
The reproduce code (obviously) lacks the $kBufferSize declaration.
$kBufferSize = 512;
or something similar
Previous Comments:
[2003-12-31 06:32:16] jeroen dot pulles at redslider dot net
Description:
fgets expects a literal for the buffer size argument. It hangs until
the max_execution_time timeouts, when you give it a variable.
Reproduce code:
---
$url = 'http://www.google.com/';
if (($handle = fopen($url, 'r')) === false) {
die('Couldnt open url '.$url.'.');
}
while (feof($handle) === false) {
$text = fgets($handle, $kBufferSize); // doesn't work
//$text = fgets($handle, 512); // works
echo($text);
}
fclose($handle);
Expected result:
The google homepage (i.e. the given url)
Actual result:
--
Timeout on max_execution_time.
--
Edit this bug report at http://bugs.php.net/?id=26752edit=1
#25922 [NEW]: In error handler, modifying 5th arg (errcontext) may result in seg fault
From: jeroen at derks dot it
Operating system: Linux 2.4.20 Debian 3.0
PHP version: 4.3.3
PHP Bug Type: Reproducible crash
Bug description: In error handler, modifying 5th arg (errcontext) may result in seg
fault
Description:
Modifying 5th parameter of error handler will make PHP crash when leaving
the error handler.
NB: This seems to happen only when the error was generated in a function
(possibly also in a member function). Please see the code.
NB2: When changing function test()'s parameter name into $args, PHP
exitted normally.
Reproduce code:
---
function my_error_handler( $error, $errmsg = '', $errfile = '',
$errline = 0, $errcontext = '' )
{
$errcontext = '';
}
set_error_handler( 'my_error_handler' );
function test( $headers = '' )
{
echo Undefined index here: '{$data['HTTP_HEADER']}'\n;
}
test();
Expected result:
Undefined index here: ''
Actual result:
--
Undefined index here: ''
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=25922edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25922r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25922r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25922r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25922r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25922r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25922r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25922r=support
Expected behavior: http://bugs.php.net/fix.php?id=25922r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25922r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25922r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25922r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25922r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25922r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25922r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25922r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25922r=float
#25247 [NEW]: Shuffle() method doesn't work properly
From: jeroen at kesh dot nl
Operating system: Windows 2000 Server
PHP version: 4.3.3
PHP Bug Type: Arrays related
Bug description: Shuffle() method doesn't work properly
Description:
I pick the first two products out of the shuffled array for random
productviews on a page. I use 3 or more products.
With PHP 4.3.2 it works nice (every refresh another two products). With
PHP 4.3.3 it doesn't seem to work. Every time the same products.
Same PHP.INI file as 4.3.2 (which worked fine).
Reproduce code:
---
$ads = array();
while($product = mysql_fetch_array($arts)) {
$ads[] = $product;
}
shuffle($ads);
$prod = $ads[0];
echo ($prod[name]);
$prod = $ads[1];
echo ($prod[name]);
Expected result:
The first two array-records are other products every time at refresh.
Actual result:
--
The first two array-records are the same products each refresh.
--
Edit bug report at http://bugs.php.net/?id=25247edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25247r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25247r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25247r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25247r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25247r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25247r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25247r=support
Expected behavior: http://bugs.php.net/fix.php?id=25247r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25247r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25247r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25247r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25247r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25247r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25247r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25247r=gnused
#20936 [NEW]: Patch for use of public keys
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4CVS-2002-12-11 (dev) PHP Bug Type: Feature/Change Request Bug description: Patch for use of public keys I required the use of public keys (not certificates) for a current project, so I patched ext/openssl/openssl.c to support public keys. The patch can be found at http://www.jeroenderks.com/php-4.4.0-dev-openssl.c.diff I tries to read a public key if reading a certificate failed in php_openssl_evp_from_zval(). Also a check was added to check whether a private key was requested and only a public key is available. -- Edit bug report at http://bugs.php.net/?id=20936edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20936r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20936r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20936r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20936r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20936r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20936r=support Expected behavior: http://bugs.php.net/fix.php?id=20936r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20936r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20936r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20936r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20936r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20936r=dst IIS Stability: http://bugs.php.net/fix.php?id=20936r=isapi
#20261 [NEW]: str_rot13() changes too much
From: [EMAIL PROTECTED] Operating system: Linux (at least) PHP version: 4.2.3 PHP Bug Type: Strings related Bug description: str_rot13() changes too much a) str_rot13() changes it's given variable. b) str_rot13() changes OTHER variables. 8 $ cat test.php ?php $first = boo; $second = $first; $rot = ; echo 1: .$first.\n; echo 2: .$second.\n; echo 3: .$rot.\n; $rot = str_rot13($second); echo 1: .$first.\n; echo 2: .$second.\n; echo 3: .$rot.\n; ? ---8 8--- $ php4 -q test.php 1: boo 2: boo 3: 1: obb 2: obb 3: obb ---8 The changing of 1 is quite odd (subbug B) and very annoying. The changing of 2 is probably because it happens in place. Either way $first shouldn't be touched at all. This is on Debian Linux/unstable, but others are probably affected too. -- Edit bug report at http://bugs.php.net/?id=20261edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20261r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20261r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20261r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20261r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20261r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20261r=support Expected behavior: http://bugs.php.net/fix.php?id=20261r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20261r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20261r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20261r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20261r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20261r=dst IIS Stability: http://bugs.php.net/fix.php?id=20261r=isapi
#20108 [NEW]: $a = boo; printf(%580.58s\n, $a); Segfaults
From: [EMAIL PROTECTED] Operating system: Linux and NetBSD PHP version: 4.2.3 PHP Bug Type: Reproducible crash Bug description: $a = boo; printf(%580.58s\n, $a); Segfaults The oops: 8- jeroen@noc:~$ ulimit -c unlimited jeroen@noc:~$ php4 ?php $a = boo; printf(%580.58s\n, $a); ? Segmentation fault (core dumped) -8 The system: 8- jeroen@noc:~$ uname -a Linux noc 2.4.18 #1 Wed May 29 22:19:46 CEST 2002 i686 Intel(R) Celeron(TM) CPU 1200MHz GenuineIntel GNU/Linux -8 It's Debian unstable, current as of 26-Oct-2002 Relevant Debian packages: ii libc6 2.3.1-3 ii php4-cgi 4.2.3-3 Backtrace: 8-- (gdb) bt #0 0x402711af in mallopt () from /lib/libc.so.6 #1 0x4027001f in realloc () from /lib/libc.so.6 #2 0x080dd7a3 in _erealloc () #3 0x080a6b6a in php_if_stat () #4 0x080a8804 in zif_user_printf () #5 0x0810c060 in execute () #6 0x080ea428 in zend_execute_scripts () #7 0x080664cd in php_execute_script () #8 0x08064363 in main () #9 0x4021b9d3 in __libc_start_main () from /lib/libc.so.6 (gdb) q --8 I've also tested it on NetBSD, which also segfaulted apache and gave back a whole lot of wrong things (buffer from previous sessions). OpenBSD 3.1 + FreeBSD 4.6-RELEASE didn't have this problem so this could quite well be glibc related, see the traceback above. -- Edit bug report at http://bugs.php.net/?id=20108edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20108r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20108r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20108r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20108r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20108r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20108r=support Expected behavior: http://bugs.php.net/fix.php?id=20108r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20108r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20108r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20108r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20108r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20108r=dst IIS Stability: http://bugs.php.net/fix.php?id=20108r=isapi
#20108 [Asn]: $a = boo; printf(%580.58s\n, $a); Segfaults
ID: 20108 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Reproducible crash Operating System: Linux and NetBSD PHP Version: 4.0CVS-2002-10-20 Assigned To: iliaa New Comment: I just re-tested this on a FreeBSD 4.6-RELEASE again and: -8 jeroen@hog:~$ uname -a ?php $a = boo; printf(%580.58s\n, $a); ? X-Powered-By: PHP/4.1.1 Content-type: text/html -8 Notice the many \n's, this could be an empty buffer... Which is the same I got on OpenBSD 3.1... Previous Comments: [2002-10-26 15:13:38] [EMAIL PROTECTED] Somewhat reproduced with BSDi 4.2. Not a segfault, but garbage output. added testcase to CVS. Updated version. [2002-10-26 13:13:00] [EMAIL PROTECTED] The oops: 8- jeroen@noc:~$ ulimit -c unlimited jeroen@noc:~$ php4 ?php $a = boo; printf(%580.58s\n, $a); ? Segmentation fault (core dumped) -8 The system: 8- jeroen@noc:~$ uname -a Linux noc 2.4.18 #1 Wed May 29 22:19:46 CEST 2002 i686 Intel(R) Celeron(TM) CPU 1200MHz GenuineIntel GNU/Linux -8 It's Debian unstable, current as of 26-Oct-2002 Relevant Debian packages: ii libc6 2.3.1-3 ii php4-cgi 4.2.3-3 Backtrace: 8-- (gdb) bt #0 0x402711af in mallopt () from /lib/libc.so.6 #1 0x4027001f in realloc () from /lib/libc.so.6 #2 0x080dd7a3 in _erealloc () #3 0x080a6b6a in php_if_stat () #4 0x080a8804 in zif_user_printf () #5 0x0810c060 in execute () #6 0x080ea428 in zend_execute_scripts () #7 0x080664cd in php_execute_script () #8 0x08064363 in main () #9 0x4021b9d3 in __libc_start_main () from /lib/libc.so.6 (gdb) q --8 I've also tested it on NetBSD, which also segfaulted apache and gave back a whole lot of wrong things (buffer from previous sessions). OpenBSD 3.1 + FreeBSD 4.6-RELEASE didn't have this problem so this could quite well be glibc related, see the traceback above. -- Edit this bug report at http://bugs.php.net/?id=20108edit=1
Bug #17262 Updated: PHP 4.2.1 fails to install when compiled as a CGI
ID: 17262 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: *Compile Issues Operating System: RedHat linux 7.3 PHP Version: 4.2.1 New Comment: I'm experiencing the same bug on my Mandrake 8.1 system, except I'm trying to compile it as a Apache2 Shared Module. I added an empty dir called libs in the dir where I unpacked PHP 4.2.1 and it suddenly worked, thanks to Daniel. :) Previous Comments: [2002-05-16 17:00:00] [EMAIL PROTECTED] I think it´s my Bug ID 17203, so manually creating the directory libs may be the solution. Daniel [2002-05-16 09:00:54] [EMAIL PROTECTED] This is the full error, I can paste the entire contents of the make install when I get to work if you like. [2002-05-16 06:41:20] [EMAIL PROTECTED] Can you please copy and paste the FULL error? [2002-05-15 18:20:04] [EMAIL PROTECTED] When compiling php with the following options on a stock RedHat 7.3 system: ./configure \ --without-mysql \ --with-config-file-path=/etc \ --with-zlib \ --with-gd \ --with-pgsql \ --with-system-regex \ --with-pdflib I recieve this error when performing the make install: Making install in . make[1]: Entering directory `/sources/php-4.2.1' make[1]: *** [install-sapi] Error 1 make[1]: Leaving directory `/sources/php-4.2.1' make: *** [install-recursive] Error 1 The php binary is not installed when I get this message. I can copy the file into the /usr/local/lib directory and it *appears* to work ok. This problem was not present in php version 4.1.2. -- Edit this bug report at http://bugs.php.net/?id=17262edit=1
