Bug #52550 [Com]: integer undefined behaviors executed during "make test"
Edit report at http://bugs.php.net/bug.php?id=52550&edit=1 ID: 52550 Comment by: regehr at cs dot utah dot edu Reported by:regehr at cs dot utah dot edu Summary:integer undefined behaviors executed during "make test" Status: Analyzed Type: Bug Package:*General Issues Operating System: linux PHP Version:trunk-SVN-2010-08-06 (snap) Block user comment: N New Comment: Below are some updated results from our integer undefined behavior checker. These are from php-trunk-201009022030 on x86-64 Linux. The .log files from "make test" can be found here: http://www.cs.utah.edu/~regehr/php-trunk-201009022030.test-logs.tar.gz Basically you just want to grep for "CLANG UNDEFINED" in these files. Summary: : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int64): 9223372036854775800 right (int64): 8 : Op: -, Reason : Signed Subtraction Overflow, UNARY OPERATION: left (int64): 0 right (int64): -9223372036854775808 : Op: <<, Reason : Signed Left Shift: Right operand is negative or is greater than or equal to the width of the promoted left operand, BINARY OPERATION: left (int64): 0 right (int64): 65 : Op: >>, Reason : Signed Right Shift: Right operand is negative or is greater than or equal to the width of the promoted left operand, BINARY OPERATION: left (int64): 0 right (int64): 65 : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int64): 9223372036854775807 right (int64): 1 : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int64): -9223372036854775808 right (int64): 1 : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int64): 9223372036854775807 right (int64): 7 : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int32): 255 right (int32): 16777216 : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int64): 2147483647 right (int64): 4611686014132420609 : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int64): 110075314176 right (int64): 110075314176 Previous Comments: [2010-08-08 17:45:04] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=301991 Log: Additional fix for bug #52550 & fix test & warning from previous fixes [2010-08-06 23:53:31] regehr at cs dot utah dot edu FYI there are a few bogus errors in the list I posted earlier. Obviously (35 - 33) is well-defined in C. Sorry about that. It should be easy to recognize and ignore these. [2010-08-06 22:04:30] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=301939 Log: Another fix for issue indentified in bug #52550 [2010-08-06 21:55:12] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=301938 Log: Fixed issues inside str_pad() identified by bug #52550 [2010-08-06 21:42:55] regehr at cs dot utah dot edu The tool isn't yet available. It is a modified version of LLVM's Clang compiler and it still has some rough edges that we're working out. However, we'll contribute it to the LLVM project fairly soon, at which point it'll be really easy to run as you suggest. In the meantime I'd be happy to rerun it in a few weeks or whenever seems good to you. 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=52550 -- Edit this bug report at http://bugs.php.net/bug.php?id=52550&edit=1
Bug #52412 [Com]: __autoload fails to throw exception when calling a static method on the class
Edit report at http://bugs.php.net/bug.php?id=52412&edit=1 ID: 52412 Comment by: php dot net at phrozenbyte dot de Reported by:madboyka at yahoo dot com Summary:__autoload fails to throw exception when calling a static method on the class Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows PHP Version:5.3.3 Block user comment: N New Comment: Same on Ubuntu 10.04 / Apache 2.2 and CLI mode Test script: --- Expected result: Exception caught Actual result: -- Fatal error: Class 'Foo' not found in /home/daniel/www/other/php-bug.php on line 0 Previous Comments: [2010-07-23 09:34:02] madboyka at yahoo dot com Description: I've tried to do the following: 1. Wrote and autoload method, that throws an exception. 3. Made a static call on a non-existing class within a try block. Tried this on windows 7 / Apache 2.2 / PHP 5.3.3. Test script: --- http://bugs.php.net/bug.php?id=52412&edit=1
Bug #36419 [Com]: rpmbuild -bb php.spec fails
Edit report at http://bugs.php.net/bug.php?id=36419&edit=1 ID: 36419 Comment by: idl3mind at gmail dot com Reported by:michael at stellarent dot com Summary:rpmbuild -bb php.spec fails Status: Bogus Type: Bug Package:*Compile Issues Operating System: Fedora Core 2 PHP Version:5.1.2 Block user comment: N New Comment: thanks Michael. removing -Wno-pointer-sign worked like a champ. Previous Comments: [2006-03-08 08:27:05] tony2...@php.net Report that to Redhat, they are the authors the php.spec file and PHP developers have nothing to do with it. [2006-03-07 23:32:32] michael at stellarent dot com PS: What do you mean by "We do not support any third-party packages."? What 3rd party packages are you referring to? Thanks, Michael. [2006-03-07 23:26:46] michael at stellarent dot com You might say my gcc is borked, but that's not correct at all. Since reporting the problem I have discovered the nature of the problem, which lies with php.spec file. The CFLAGS variable in php.spec file has the flag "-Wno-pointer-sign" which does not exist in gcc < 4.x. Thus the configure error "configure: error: C compiler cannot create executables" is bogus (not to mention totally confusing). Simply removing the flag from php.spec resolves the problem nicely. By the way, on Fedora Core 4, php 5.1.2 builds without problems, since gcc is by default version 4. So my guess is that no one thought that someone would want to build/use php > 5.0.4 on Fedora 1,2 or 3. It is written for Fedora 4. And I am sure you realize that upgrading gcc on FC1,2 or 3 is impossible (unless you upgrade everything). It is disappointing you assumed so quickly my gcc is 'b0rked', instead of investigating the matter properly. And to reinforce my point, I just received this note from another php user (you should have received a cc): Timothy M. Gage [tg...@tamdesign.com] --- This problem appears to stem from an unsupported CFLAGS option which has been added to the Fedora spec file. Removing -Wno-pointer-sign from the CFLAGS line in the php.spec file will allow rpmbuild to function properly. The problem is not with the PHP distribution itself, but with the fedora supplied php.spec file. Thanks in advance! Regards, Tim - Thanks, Michael. [2006-02-16 16:08:14] tony2...@php.net We do not support any third-party packages. And yes, your gcc is b0rked, see config.log for details. [2006-02-16 15:55:13] michael at stellarent dot com Description: Downloaded the latest fedora core source rpm (php-5.1.2-4.3.src.rpm), installed using rpm -ivh, and invoked rpmbuild -bb. Build fails with message: checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. error: Bad exit status from /var/tmp/rpm-tmp.21471 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.21471 (%build) I have tried earlier versions, but same problem. The only version which builds, is 5.0.4-3. Curiously, compiling php from tar.gz distrubution works fine. Expected result: php to build all rpms in /usr/src/redhat/RPMS/i386 Actual result: -- [r...@fc2 php-5.1.2]# rpmbuild -bb /usr/src/redhat/SPECS/php-5.1.2-4.3.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.68654 + umask 022 + cd /usr/src/redhat/BUILD + LANG=C + export LANG + unset DISPLAY + cd /usr/src/redhat/BUILD + rm -rf php-5.1.2 + /usr/bin/gzip -dc /usr/src/redhat/SOURCES/php-5.1.2.tar.gz + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd php-5.1.2 ++ /usr/bin/id -u + '[' 0 = 0 ']' + /bin/chown -Rhf root . ++ /usr/bin/id -u + '[' 0 = 0 ']' + /bin/chgrp -Rhf root . + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #5 (php-4.3.3-install.patch):' Patch #5 (php-4.3.3-install.patch): + patch -p1 -b --suffix .install -s + echo 'Patch #6 (php-5.0.4-norpath.patch):' Patch #6 (php-5.0.4-norpath.patch): + patch -p1 -b --suffix .norpath -s + echo 'Patch #7 (php-4.3.2-libtool15.patch):' Patch #7 (php-4.3.2-libtool15.patch): + patch -p1 -b --suffix .libtool15 -s + echo 'Patch #13 (php-5.0.2-phpize64.patch):' Patch #13 (php-5.0.2-phpize64.patch): + patch -p1 -b --suffix .phpize64 -s + echo 'Patch #21 (php-4.3.1-odbc.patch):' Patch #21 (php-4.3.1-odbc.patch): + patch -p1 -b --suffix .odbc -s + echo 'Patch #22 (php-4.3.11-shutdown.patch):' Patch #22 (php-4.3.11-shutdown.patch
Bug #47584 [Bgs]: WSDL error in soapClient causes Fatal Error
Edit report at http://bugs.php.net/bug.php?id=47584&edit=1
ID: 47584
User updated by:gem at rellim dot com
Reported by:gem at rellim dot com
Summary:WSDL error in soapClient causes Fatal Error
Status: Bogus
Type: Bug
Package:SOAP related
Operating System: Linux
PHP Version:5.2.9
Assigned To:dmitry
Block user comment: N
New Comment:
I was a confirmed bug in earlier versions. So it should be 'Fixed' not
"Bogus'.
Previous Comments:
[2010-09-02 19:37:13] ras...@php.net
Right, so this is not a PHP bug. Perhaps a feature request to downgrade
that
particular error to a Warning instead of a catchable fatal, but that is
all I see.
[2010-09-02 19:34:19] gem at rellim dot com
I do see it catchable now without XDebug.
# php tmp.php
SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-existent.wsdl' :
failed to load
external entity "non-existent.wsdl"
ok
#
[2010-09-02 19:33:05] gem at rellim dot com
Not catchable for me with XDebug and your example:
# cat tmp.php
1));
} catch (SoapFault $E) {
echo $E->faultstring;
}
echo "ok\n";
?>
# php tmp.php
#
[2010-09-02 19:22:02] ras...@php.net
It is a catchable fatal though.
eg.
1));
} catch (SoapFault $E) {
echo $E->faultstring;
}
echo "ok\n";
[2010-09-02 19:20:22] gem at rellim dot com
Hmm, on 2nd look, it does now appear catchable w/o XDebug, but not with
XDebug.
Ideas?
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=47584
--
Edit this bug report at http://bugs.php.net/bug.php?id=47584&edit=1
Bug #47584 [Fbk->Bgs]: WSDL error in soapClient causes Fatal Error
Edit report at http://bugs.php.net/bug.php?id=47584&edit=1
ID: 47584
Updated by: ras...@php.net
Reported by:gem at rellim dot com
Summary:WSDL error in soapClient causes Fatal Error
-Status: Feedback
+Status: Bogus
Type: Bug
Package:SOAP related
Operating System: Linux
PHP Version:5.2.9
Assigned To:dmitry
Block user comment: N
New Comment:
Right, so this is not a PHP bug. Perhaps a feature request to downgrade
that
particular error to a Warning instead of a catchable fatal, but that is
all I see.
Previous Comments:
[2010-09-02 19:34:19] gem at rellim dot com
I do see it catchable now without XDebug.
# php tmp.php
SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-existent.wsdl' :
failed to load
external entity "non-existent.wsdl"
ok
#
[2010-09-02 19:33:05] gem at rellim dot com
Not catchable for me with XDebug and your example:
# cat tmp.php
1));
} catch (SoapFault $E) {
echo $E->faultstring;
}
echo "ok\n";
?>
# php tmp.php
#
[2010-09-02 19:22:02] ras...@php.net
It is a catchable fatal though.
eg.
1));
} catch (SoapFault $E) {
echo $E->faultstring;
}
echo "ok\n";
[2010-09-02 19:20:22] gem at rellim dot com
Hmm, on 2nd look, it does now appear catchable w/o XDebug, but not with
XDebug.
Ideas?
[2010-09-02 19:17:36] gem at rellim dot com
It fails similarly without XDebug:
# php -v
PHP 5.3.3 (cli) (built: Jul 26 2010 14:55:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
# php tmp.php
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent.wsdl' : failed to load external entity "non-existent.wsdl"
in /tmp/tmp.php on line 3
ok
#
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=47584
--
Edit this bug report at http://bugs.php.net/bug.php?id=47584&edit=1
Bug #47584 [Com]: WSDL error in soapClient causes Fatal Error
Edit report at http://bugs.php.net/bug.php?id=47584&edit=1
ID: 47584
Comment by: gem at rellim dot com
Reported by:gem at rellim dot com
Summary:WSDL error in soapClient causes Fatal Error
Status: Feedback
Type: Bug
Package:SOAP related
Operating System: Linux
PHP Version:5.2.9
Assigned To:dmitry
Block user comment: N
New Comment:
I do see it catchable now without XDebug.
# php tmp.php
SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-existent.wsdl' :
failed to load
external entity "non-existent.wsdl"
ok
#
Previous Comments:
[2010-09-02 19:33:05] gem at rellim dot com
Not catchable for me with XDebug and your example:
# cat tmp.php
1));
} catch (SoapFault $E) {
echo $E->faultstring;
}
echo "ok\n";
?>
# php tmp.php
#
[2010-09-02 19:22:02] ras...@php.net
It is a catchable fatal though.
eg.
1));
} catch (SoapFault $E) {
echo $E->faultstring;
}
echo "ok\n";
[2010-09-02 19:20:22] gem at rellim dot com
Hmm, on 2nd look, it does now appear catchable w/o XDebug, but not with
XDebug.
Ideas?
[2010-09-02 19:17:36] gem at rellim dot com
It fails similarly without XDebug:
# php -v
PHP 5.3.3 (cli) (built: Jul 26 2010 14:55:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
# php tmp.php
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent.wsdl' : failed to load external entity "non-existent.wsdl"
in /tmp/tmp.php on line 3
ok
#
[2010-09-02 19:15:22] gem at rellim dot com
Forgot my version details:
# php -v
PHP 5.3.3 (cli) (built: Jul 26 2010 14:55:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
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=47584
--
Edit this bug report at http://bugs.php.net/bug.php?id=47584&edit=1
Bug #47584 [Com]: WSDL error in soapClient causes Fatal Error
Edit report at http://bugs.php.net/bug.php?id=47584&edit=1
ID: 47584
Comment by: gem at rellim dot com
Reported by:gem at rellim dot com
Summary:WSDL error in soapClient causes Fatal Error
Status: Feedback
Type: Bug
Package:SOAP related
Operating System: Linux
PHP Version:5.2.9
Assigned To:dmitry
Block user comment: N
New Comment:
Not catchable for me with XDebug and your example:
# cat tmp.php
1));
} catch (SoapFault $E) {
echo $E->faultstring;
}
echo "ok\n";
?>
# php tmp.php
#
Previous Comments:
[2010-09-02 19:22:02] ras...@php.net
It is a catchable fatal though.
eg.
1));
} catch (SoapFault $E) {
echo $E->faultstring;
}
echo "ok\n";
[2010-09-02 19:20:22] gem at rellim dot com
Hmm, on 2nd look, it does now appear catchable w/o XDebug, but not with
XDebug.
Ideas?
[2010-09-02 19:17:36] gem at rellim dot com
It fails similarly without XDebug:
# php -v
PHP 5.3.3 (cli) (built: Jul 26 2010 14:55:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
# php tmp.php
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent.wsdl' : failed to load external entity "non-existent.wsdl"
in /tmp/tmp.php on line 3
ok
#
[2010-09-02 19:15:22] gem at rellim dot com
Forgot my version details:
# php -v
PHP 5.3.3 (cli) (built: Jul 26 2010 14:55:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
[2010-09-02 19:14:24] gem at rellim dot com
Your example fails for me, I can not catch the error:
# cat tmp.php
# php tmp.php
PHP Warning: SoapClient::SoapClient(): I/O warning : failed to load
external
entity "non-existent.wsdl" in /tmp/tmp.php on line 3
PHP Stack trace:
PHP 1. {main}() /tmp/tmp.php:0
PHP 2. SoapClient->SoapClient() /tmp/tmp.php:3
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent.wsdl' : failed to load external entity "non-existent.wsdl"
in /tmp/tmp.php on line 3
PHP Stack trace:
PHP 1. {main}() /tmp/tmp.php:0
PHP 2. SoapClient->SoapClient() /tmp/tmp.php:3
#
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=47584
--
Edit this bug report at http://bugs.php.net/bug.php?id=47584&edit=1
Bug #47584 [Fbk]: WSDL error in soapClient causes Fatal Error
Edit report at http://bugs.php.net/bug.php?id=47584&edit=1
ID: 47584
Updated by: ras...@php.net
Reported by:gem at rellim dot com
Summary:WSDL error in soapClient causes Fatal Error
Status: Feedback
Type: Bug
Package:SOAP related
Operating System: Linux
PHP Version:5.2.9
Assigned To:dmitry
Block user comment: N
New Comment:
It is a catchable fatal though.
eg.
1));
} catch (SoapFault $E) {
echo $E->faultstring;
}
echo "ok\n";
Previous Comments:
[2010-09-02 19:20:22] gem at rellim dot com
Hmm, on 2nd look, it does now appear catchable w/o XDebug, but not with
XDebug.
Ideas?
[2010-09-02 19:17:36] gem at rellim dot com
It fails similarly without XDebug:
# php -v
PHP 5.3.3 (cli) (built: Jul 26 2010 14:55:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
# php tmp.php
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent.wsdl' : failed to load external entity "non-existent.wsdl"
in /tmp/tmp.php on line 3
ok
#
[2010-09-02 19:15:22] gem at rellim dot com
Forgot my version details:
# php -v
PHP 5.3.3 (cli) (built: Jul 26 2010 14:55:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
[2010-09-02 19:14:24] gem at rellim dot com
Your example fails for me, I can not catch the error:
# cat tmp.php
# php tmp.php
PHP Warning: SoapClient::SoapClient(): I/O warning : failed to load
external
entity "non-existent.wsdl" in /tmp/tmp.php on line 3
PHP Stack trace:
PHP 1. {main}() /tmp/tmp.php:0
PHP 2. SoapClient->SoapClient() /tmp/tmp.php:3
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent.wsdl' : failed to load external entity "non-existent.wsdl"
in /tmp/tmp.php on line 3
PHP Stack trace:
PHP 1. {main}() /tmp/tmp.php:0
PHP 2. SoapClient->SoapClient() /tmp/tmp.php:3
#
[2010-09-02 10:40:34] dmi...@php.net
BTW despite SoapClient emits a fatal error it already throws exception
which can be caught (even in 5.2 brunch).
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=47584
--
Edit this bug report at http://bugs.php.net/bug.php?id=47584&edit=1
Bug #47584 [Com]: WSDL error in soapClient causes Fatal Error
Edit report at http://bugs.php.net/bug.php?id=47584&edit=1
ID: 47584
Comment by: gem at rellim dot com
Reported by:gem at rellim dot com
Summary:WSDL error in soapClient causes Fatal Error
Status: Feedback
Type: Bug
Package:SOAP related
Operating System: Linux
PHP Version:5.2.9
Assigned To:dmitry
Block user comment: N
New Comment:
Hmm, on 2nd look, it does now appear catchable w/o XDebug, but not with
XDebug.
Ideas?
Previous Comments:
[2010-09-02 19:17:36] gem at rellim dot com
It fails similarly without XDebug:
# php -v
PHP 5.3.3 (cli) (built: Jul 26 2010 14:55:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
# php tmp.php
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent.wsdl' : failed to load external entity "non-existent.wsdl"
in /tmp/tmp.php on line 3
ok
#
[2010-09-02 19:15:22] gem at rellim dot com
Forgot my version details:
# php -v
PHP 5.3.3 (cli) (built: Jul 26 2010 14:55:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
[2010-09-02 19:14:24] gem at rellim dot com
Your example fails for me, I can not catch the error:
# cat tmp.php
# php tmp.php
PHP Warning: SoapClient::SoapClient(): I/O warning : failed to load
external
entity "non-existent.wsdl" in /tmp/tmp.php on line 3
PHP Stack trace:
PHP 1. {main}() /tmp/tmp.php:0
PHP 2. SoapClient->SoapClient() /tmp/tmp.php:3
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent.wsdl' : failed to load external entity "non-existent.wsdl"
in /tmp/tmp.php on line 3
PHP Stack trace:
PHP 1. {main}() /tmp/tmp.php:0
PHP 2. SoapClient->SoapClient() /tmp/tmp.php:3
#
[2010-09-02 10:40:34] dmi...@php.net
BTW despite SoapClient emits a fatal error it already throws exception
which can be caught (even in 5.2 brunch).
[2010-06-24 01:55:11] gem at rellim dot com
This is a still a 100% show stopper for me. I can not make PHP pages
live
that will crash on simple network errors.
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=47584
--
Edit this bug report at http://bugs.php.net/bug.php?id=47584&edit=1
Bug #47584 [Com]: WSDL error in soapClient causes Fatal Error
Edit report at http://bugs.php.net/bug.php?id=47584&edit=1
ID: 47584
Comment by: gem at rellim dot com
Reported by:gem at rellim dot com
Summary:WSDL error in soapClient causes Fatal Error
Status: Feedback
Type: Bug
Package:SOAP related
Operating System: Linux
PHP Version:5.2.9
Assigned To:dmitry
Block user comment: N
New Comment:
It fails similarly without XDebug:
# php -v
PHP 5.3.3 (cli) (built: Jul 26 2010 14:55:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
# php tmp.php
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent.wsdl' : failed to load external entity "non-existent.wsdl"
in /tmp/tmp.php on line 3
ok
#
Previous Comments:
[2010-09-02 19:15:22] gem at rellim dot com
Forgot my version details:
# php -v
PHP 5.3.3 (cli) (built: Jul 26 2010 14:55:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
[2010-09-02 19:14:24] gem at rellim dot com
Your example fails for me, I can not catch the error:
# cat tmp.php
# php tmp.php
PHP Warning: SoapClient::SoapClient(): I/O warning : failed to load
external
entity "non-existent.wsdl" in /tmp/tmp.php on line 3
PHP Stack trace:
PHP 1. {main}() /tmp/tmp.php:0
PHP 2. SoapClient->SoapClient() /tmp/tmp.php:3
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent.wsdl' : failed to load external entity "non-existent.wsdl"
in /tmp/tmp.php on line 3
PHP Stack trace:
PHP 1. {main}() /tmp/tmp.php:0
PHP 2. SoapClient->SoapClient() /tmp/tmp.php:3
#
[2010-09-02 10:40:34] dmi...@php.net
BTW despite SoapClient emits a fatal error it already throws exception
which can be caught (even in 5.2 brunch).
[2010-06-24 01:55:11] gem at rellim dot com
This is a still a 100% show stopper for me. I can not make PHP pages
live
that will crash on simple network errors.
[2010-06-22 10:35:23] florent dot biville at insa-rouen dot fr
I can confirm I encounter the same problem.
Despite everything documented, problems with WSDL reading will trigger a
fatal error.
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=47584
--
Edit this bug report at http://bugs.php.net/bug.php?id=47584&edit=1
Bug #47584 [Com]: WSDL error in soapClient causes Fatal Error
Edit report at http://bugs.php.net/bug.php?id=47584&edit=1
ID: 47584
Comment by: gem at rellim dot com
Reported by:gem at rellim dot com
Summary:WSDL error in soapClient causes Fatal Error
Status: Feedback
Type: Bug
Package:SOAP related
Operating System: Linux
PHP Version:5.2.9
Assigned To:dmitry
Block user comment: N
New Comment:
Forgot my version details:
# php -v
PHP 5.3.3 (cli) (built: Jul 26 2010 14:55:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
Previous Comments:
[2010-09-02 19:14:24] gem at rellim dot com
Your example fails for me, I can not catch the error:
# cat tmp.php
# php tmp.php
PHP Warning: SoapClient::SoapClient(): I/O warning : failed to load
external
entity "non-existent.wsdl" in /tmp/tmp.php on line 3
PHP Stack trace:
PHP 1. {main}() /tmp/tmp.php:0
PHP 2. SoapClient->SoapClient() /tmp/tmp.php:3
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent.wsdl' : failed to load external entity "non-existent.wsdl"
in /tmp/tmp.php on line 3
PHP Stack trace:
PHP 1. {main}() /tmp/tmp.php:0
PHP 2. SoapClient->SoapClient() /tmp/tmp.php:3
#
[2010-09-02 10:40:34] dmi...@php.net
BTW despite SoapClient emits a fatal error it already throws exception
which can be caught (even in 5.2 brunch).
[2010-06-24 01:55:11] gem at rellim dot com
This is a still a 100% show stopper for me. I can not make PHP pages
live
that will crash on simple network errors.
[2010-06-22 10:35:23] florent dot biville at insa-rouen dot fr
I can confirm I encounter the same problem.
Despite everything documented, problems with WSDL reading will trigger a
fatal error.
[2010-04-09 07:41:35] pwb at evanr dot com
This is a real issue, even when the SoapClient is set to throw
exceptions and not
errors. This fatal error cannot be defeated even with the exceptions
option set
to true.
We're experiencing this in 5.2.13 on linux x64.
A fatal error is thrown not only when WSDL can't be loaded but as well
when an
internal reference in the WSDL (e.g. to a namespace) cannot be
imported/resolved.
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=47584
--
Edit this bug report at http://bugs.php.net/bug.php?id=47584&edit=1
Bug #47584 [Com]: WSDL error in soapClient causes Fatal Error
Edit report at http://bugs.php.net/bug.php?id=47584&edit=1
ID: 47584
Comment by: gem at rellim dot com
Reported by:gem at rellim dot com
Summary:WSDL error in soapClient causes Fatal Error
Status: Feedback
Type: Bug
Package:SOAP related
Operating System: Linux
PHP Version:5.2.9
Assigned To:dmitry
Block user comment: N
New Comment:
Your example fails for me, I can not catch the error:
# cat tmp.php
# php tmp.php
PHP Warning: SoapClient::SoapClient(): I/O warning : failed to load
external
entity "non-existent.wsdl" in /tmp/tmp.php on line 3
PHP Stack trace:
PHP 1. {main}() /tmp/tmp.php:0
PHP 2. SoapClient->SoapClient() /tmp/tmp.php:3
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent.wsdl' : failed to load external entity "non-existent.wsdl"
in /tmp/tmp.php on line 3
PHP Stack trace:
PHP 1. {main}() /tmp/tmp.php:0
PHP 2. SoapClient->SoapClient() /tmp/tmp.php:3
#
Previous Comments:
[2010-09-02 10:40:34] dmi...@php.net
BTW despite SoapClient emits a fatal error it already throws exception
which can be caught (even in 5.2 brunch).
[2010-06-24 01:55:11] gem at rellim dot com
This is a still a 100% show stopper for me. I can not make PHP pages
live
that will crash on simple network errors.
[2010-06-22 10:35:23] florent dot biville at insa-rouen dot fr
I can confirm I encounter the same problem.
Despite everything documented, problems with WSDL reading will trigger a
fatal error.
[2010-04-09 07:41:35] pwb at evanr dot com
This is a real issue, even when the SoapClient is set to throw
exceptions and not
errors. This fatal error cannot be defeated even with the exceptions
option set
to true.
We're experiencing this in 5.2.13 on linux x64.
A fatal error is thrown not only when WSDL can't be loaded but as well
when an
internal reference in the WSDL (e.g. to a namespace) cannot be
imported/resolved.
[2009-03-06 17:49:08] gem at rellim dot com
Why does it work OK for you and not for me? Just because it
works on one host for you does not mean it does not fail for me.
This is the entire program to reproduce:
http://google.com');
?>
PHP Fatal error: SOAP-ERROR: Parsing WSDL:
I can reproduce on several different hosts. I am not
running Xdebug, eaccelerator, or any other add in.
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=47584
--
Edit this bug report at http://bugs.php.net/bug.php?id=47584&edit=1
[PHP-BUG] Req #52766 [NEW]: FTP need the ability to read from the output buffer without issuing a command
From:
Operating system: Fedora 13
PHP version: 5.3.3
Package: FTP related
Bug Type: Feature/Change Request
Bug description:FTP need the ability to read from the output buffer without
issuing a command
Description:
Working with ftp_raw there is a need for a function that allows interaction
with
the output buffer of the connection. There are times when issuing commands
leaves messages on the buffer thereby causing future commands to be out of
sync
with the output and no way to synchronize them. Below is an example:
Using HylaFax's proprietary ftp interface I required the ability to issue a
'STOT' command.
I issued a 'PASV' command to get the appropriate port to open a second
connection to. I open a second connection, write a file, then close it.
The original connection now has a line on the output buffer similar to
this:
226 Transfer complete (FILE: /tmp/doc94274.tmp)
But there is no way to grab this.
Issuing any command will return the buffered line. Subsequent commands
will
return the output of the previous command.
For example if I now issue a 'NOOP' I will now get the:
226 Transfer complete (FILE: /tmp/doc94274.tmp).
and If I issue a second 'NOOP' I will get the response from the orginal
'NOOP':
200 NOOP command successful
With the second Noop now sitting on the out buffer of the ftp connection.
Test script:
---
2) {
$resultCode = substr($resultString, 0, strpos($resultString, '
' )
);
return $resultCode;
}
return $resultCode;
}
function getResultToString( $resultArray, $glue = "\n" )
{
if ( is_array( $resultArray ) ) {
return implode($resultArray, $glue );
}
return false;
}
function sendFile( $localFileName, $connection, $hostName )
{
//Enter PASV mode
if($results = getResultToString( ftp_raw($connection, 'PASV') )) {
//Make sure we got the appropriate 227 back
if(getResultCode( $results ) == 227) {
//Grab the ip and ports out of the response
$ports = substr($results, strpos($results, '(')+1 ) ;
//get rid of the extra ')' as the end
$ports = substr($ports, 0, strlen($ports) - 1);
//make an array of the results using the ',' as the
seporator
$ports = explode(",", $ports);
//grab the last octet
$lastOctet = array_pop($ports);
//grab the first octet
$firstOctet = array_pop($ports);
//deduce the appropriate port to connect back to
$port = $firstOctet * 256 + $lastOctet;
//create a connection to listen on
if( $passiveSocket = fsockopen( $hostName, $port) ) {
//Tell the ftp server to make a connection
if($results = getResultToString(ftp_raw( $connection,
'STOT' ) ) ) {
//make sure the connection was successful
if(getResultCode($results) == 150) {
//Write the file over the new socket
if( fwrite( $passiveSocket, $localFileName ) )
{
//Close the socket
if(fclose( $passiveSocket ) ) {
$results = getResultToString( ftp_raw(
$connection, 'STAT' ) );
echo "Results of stat:\n";
echo $results;
echo "Results of Noop:\n";
$results = getResultToString( ftp_raw(
$connection, 'noop' ) );
echo $results;
} // socket closure
} //file writing
} //result of STOT command to first socket
} else { //issue the STOT Command to first socket
echo 'Unexpected result from STOR: ';
var_dump( $results )."\n";
}
} //Attempt to open second socket on local machine
} else { //Unexpected resultcode from pasv command
echo 'Unexpected result code from passive mode:
'.getResultCode ($results );
} // review result code from PASV command
return true;
} //Attempt to sen
Bug #46723 [Asn]: FastCGI is incredibly slow due to TCP ack delay
Edit report at http://bugs.php.net/bug.php?id=46723&edit=1 ID: 46723 Updated by: dmi...@php.net Reported by:jost_boekemeier at users dot sf dot net Summary:FastCGI is incredibly slow due to TCP ack delay Status: Assigned Type: Bug Package:CGI related Operating System: * PHP Version:5CVS, 6CVS (2008-12-08) Assigned To:dmitry Block user comment: N New Comment: Also, which web server and fastcgi manager do you use? Previous Comments: [2010-09-02 14:35:23] dmi...@php.net Thanks a lot. Now I'm able to reproduce the issie. It occurs only in case of persistent FastCGI connections (byte number 11 in you array is 1) and large output. Unfortunately, your patch didn't fix the bug. From time to time 1/1 strace shows huge delay (up to 30 sec) on write() syscall. netstat -neo Proto Recv-Q Send-Q Local Address Foreign Address State Timer tcp90501 277632 127.0.0.1:1234 127.0.0.1:59195 ESTABLISHED probe (1.11/0/0) tcp 556640 118784 127.0.0.1:59195 127.0.0.1:1234 ESTABLISHED probe (0.88/0/0) I'll think about it. [2010-08-28 18:37:09] jost_boekemeier at users dot sf dot net Test script below: - ack_delay.php --- 0); } fclose($fp); ---end of ack_delay.php REDIRECT_STATUS="200" PHP_FCGI_CHILDR="5" PHP_FCGI_MAX_REQUESTS="5" ~/php-cgi533.patched -b 127.0.0.1:9667 #unpatched time ~/php ack_delay.php real0m4.135s user0m0.020s sys 0m0.023s #patched real0m0.140s user0m0.022s sys 0m0.028s Which means php fastcgi > 5.1.4 is more 30 times slower than 5.1.4. To reproduce: http://sourceforge.net/projects/php-java-bridge/files/RHEL_FC%20SecurityEnhancedLinux/php-java-bridge_6.2.1rc2/ PHP test script created from: http://php-java-bridge.cvs.sourceforge.net/viewvc/php-java-bridge/php-java-bridge/server/php/java/bridge/http/FCGIConnectionOutputStream.java?revision=1.2&view=markup&sortby=date and http://php-java-bridge.cvs.sourceforge.net/viewvc/php-java-bridge/php-java-bridge/server/php/java/bridge/http/FCGIConnectionInputStream.java?revision=1.2&view=markup&sortby=date Test system: Fedora 10, Linux kernel Linux version 2.6.27.5-117.fc10.i686 (mockbu...@x86-7.fedora.phx.redhat.com) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #1 SMP Tue Nov 18 12:19:59 EST 2008 > I don't know what is the "ack delay". As I know TCP_NODELAY just disables the > Nagle algorithm and this makes packets to be always sent ASAP. As result it > may produce more packets. Probably it may affect FastCGI only in some > specific scenarios. Please see http://en.wikipedia.org/wiki/Nagle%27s_algorithm "With both algorithms enabled, applications which do two successive writes to a TCP connection, followed by a read which will not be fulfilled until after the data from the second write has reached the destination, experience a constant delay of up to 500 milliseconds, the "ACK delay"." Regards, Jost Bökemeier 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=46723 -- Edit this bug report at http://bugs.php.net/bug.php?id=46723&edit=1
Bug #46723 [Asn]: FastCGI is incredibly slow due to TCP ack delay
Edit report at http://bugs.php.net/bug.php?id=46723&edit=1 ID: 46723 Updated by: dmi...@php.net Reported by:jost_boekemeier at users dot sf dot net Summary:FastCGI is incredibly slow due to TCP ack delay Status: Assigned Type: Bug Package:CGI related Operating System: * PHP Version:5CVS, 6CVS (2008-12-08) Assigned To:dmitry Block user comment: N New Comment: Thanks a lot. Now I'm able to reproduce the issie. It occurs only in case of persistent FastCGI connections (byte number 11 in you array is 1) and large output. Unfortunately, your patch didn't fix the bug. From time to time 1/1 strace shows huge delay (up to 30 sec) on write() syscall. netstat -neo Proto Recv-Q Send-Q Local Address Foreign Address State Timer tcp90501 277632 127.0.0.1:1234 127.0.0.1:59195 ESTABLISHED probe (1.11/0/0) tcp 556640 118784 127.0.0.1:59195 127.0.0.1:1234 ESTABLISHED probe (0.88/0/0) I'll think about it. Previous Comments: [2010-08-28 18:37:09] jost_boekemeier at users dot sf dot net Test script below: - ack_delay.php --- 0); } fclose($fp); ---end of ack_delay.php REDIRECT_STATUS="200" PHP_FCGI_CHILDR="5" PHP_FCGI_MAX_REQUESTS="5" ~/php-cgi533.patched -b 127.0.0.1:9667 #unpatched time ~/php ack_delay.php real0m4.135s user0m0.020s sys 0m0.023s #patched real0m0.140s user0m0.022s sys 0m0.028s Which means php fastcgi > 5.1.4 is more 30 times slower than 5.1.4. To reproduce: http://sourceforge.net/projects/php-java-bridge/files/RHEL_FC%20SecurityEnhancedLinux/php-java-bridge_6.2.1rc2/ PHP test script created from: http://php-java-bridge.cvs.sourceforge.net/viewvc/php-java-bridge/php-java-bridge/server/php/java/bridge/http/FCGIConnectionOutputStream.java?revision=1.2&view=markup&sortby=date and http://php-java-bridge.cvs.sourceforge.net/viewvc/php-java-bridge/php-java-bridge/server/php/java/bridge/http/FCGIConnectionInputStream.java?revision=1.2&view=markup&sortby=date Test system: Fedora 10, Linux kernel Linux version 2.6.27.5-117.fc10.i686 (mockbu...@x86-7.fedora.phx.redhat.com) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #1 SMP Tue Nov 18 12:19:59 EST 2008 > I don't know what is the "ack delay". As I know TCP_NODELAY just disables the > Nagle algorithm and this makes packets to be always sent ASAP. As result it > may produce more packets. Probably it may affect FastCGI only in some > specific scenarios. Please see http://en.wikipedia.org/wiki/Nagle%27s_algorithm "With both algorithms enabled, applications which do two successive writes to a TCP connection, followed by a read which will not be fulfilled until after the data from the second write has reached the destination, experience a constant delay of up to 500 milliseconds, the "ACK delay"." Regards, Jost Bökemeier 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=46723 -- Edit this bug report at http://bugs.php.net/bug.php?id=46723&edit=1
Bug #52765 [Opn->Bgs]: openssl_csr_get_subject returns a single element array when subjectName starts
Edit report at http://bugs.php.net/bug.php?id=52765&edit=1 ID: 52765 Updated by: paj...@php.net Reported by:Willy dot Weisz at univie dot ac dot at Summary:openssl_csr_get_subject returns a single element array when subjectName starts -Status: Open +Status: Bogus Type: Bug Package:OpenSSL related Operating System: Linux PHP Version:5.3.3 Block user comment: N New Comment: . Previous Comments: [2010-09-02 14:01:40] Willy dot Weisz at univie dot ac dot at Doing further tests I discovered that the CSR is ill-formed as can be seen (but I overlooked it) from the content of the single element array which I pasted from an array listing output. openssl_csr_get_subject applied to a correct CSR gives the expected result. I'm sorry for the premature bug submission. Please clause this bug report. [2010-09-02 10:23:42] Willy dot Weisz at univie dot ac dot at Description: openssl_csr_get_subject returns a single element array when the subjectName starts with DC, e.g.: for subjectName = /DC=at/DC=austriangridca/O=UniVie/OU=VCPC/CN=Willy Weisz openssl_csr_get_subject returns an array Array ( [DC] => at/DC=austriangridca/O=UniVie/OU=VCPCWilly Weisz ) instead of Array ( [DC] => at [DC] => austriangridca [O] => UniVie [OU] => VCPC [CN] => Willy Weisz ) -- Edit this bug report at http://bugs.php.net/bug.php?id=52765&edit=1
Bug #52765 [Opn]: openssl_csr_get_subject returns a single element array when subjectName starts
Edit report at http://bugs.php.net/bug.php?id=52765&edit=1 ID: 52765 User updated by:Willy dot Weisz at univie dot ac dot at Reported by:Willy dot Weisz at univie dot ac dot at Summary:openssl_csr_get_subject returns a single element array when subjectName starts Status: Open Type: Bug Package:OpenSSL related Operating System: Linux PHP Version:5.3.3 Block user comment: N New Comment: Doing further tests I discovered that the CSR is ill-formed as can be seen (but I overlooked it) from the content of the single element array which I pasted from an array listing output. openssl_csr_get_subject applied to a correct CSR gives the expected result. I'm sorry for the premature bug submission. Please clause this bug report. Previous Comments: [2010-09-02 10:23:42] Willy dot Weisz at univie dot ac dot at Description: openssl_csr_get_subject returns a single element array when the subjectName starts with DC, e.g.: for subjectName = /DC=at/DC=austriangridca/O=UniVie/OU=VCPC/CN=Willy Weisz openssl_csr_get_subject returns an array Array ( [DC] => at/DC=austriangridca/O=UniVie/OU=VCPCWilly Weisz ) instead of Array ( [DC] => at [DC] => austriangridca [O] => UniVie [OU] => VCPC [CN] => Willy Weisz ) -- Edit this bug report at http://bugs.php.net/bug.php?id=52765&edit=1
Bug #52419 [Opn]: Unable to compile PHP with both Apache2 and FPM support
Edit report at http://bugs.php.net/bug.php?id=52419&edit=1 ID: 52419 Updated by: paj...@php.net Reported by:php-bugs at majkl578 dot cz Summary:Unable to compile PHP with both Apache2 and FPM support Status: Open Type: Bug Package:Compile Failure Operating System: Linux Debian PHP Version:5.3.3 Block user comment: N New Comment: @f...@php.net Yes, as long as they are all zts (x)or non thread safe. Previous Comments: [2010-09-02 12:22:18] james dot butler at sandfox dot co dot uk I can confirm this is an issue on Centos 5.5 64bit get exactly the same error when trying to compile with apxs AND fpm both enabled. Removing either one from the config line results in successful compilation. [2010-09-01 17:42:25] f...@php.net the problem is the same if compiling SAPI apache2handler with litespeed. The same with fpm and litespeed. Is it possible to compile PHP with multiple SAPI ? [2010-09-01 14:29:49] f...@php.net The problem is: in the general Makefile there is: BUILD_FPM = $(LIBTOOL) --mode=link $(CC) -export-dynamic $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(EXTRA_LDFLAGS_PROGRAM) $(LDFLAGS) $(PHP_RPATHS) $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(EXTRA_LIBS) $(SAPI_EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $(SAPI_FPM_PATH) and PHP_SAPI_OBJS = sapi/apache2handler/mod_php5.lo sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo sapi/apache2handler/php_functions.lo sapi/fpm/fpm/fastcgi.lo sapi/fpm/fpm/fpm.lo sapi/fpm/fpm/fpm_children.lo sapi/fpm/fpm/fpm_cleanup.lo sapi/fpm/fpm/fpm_clock.lo sapi/fpm/fpm/fpm_conf.lo sapi/fpm/fpm/fpm_env.lo sapi/fpm/fpm/fpm_events.lo sapi/fpm/fpm/fpm_main.lo sapi/fpm/fpm/fpm_php.lo sapi/fpm/fpm/fpm_php_trace.lo sapi/fpm/fpm/fpm_process_ctl.lo sapi/fpm/fpm/fpm_request.lo sapi/fpm/fpm/fpm_shm.lo sapi/fpm/fpm/fpm_shm_slots.lo sapi/fpm/fpm/fpm_signals.lo sapi/fpm/fpm/fpm_sockets.lo sapi/fpm/fpm/fpm_status.lo sapi/fpm/fpm/fpm_stdio.lo sapi/fpm/fpm/fpm_unix.lo sapi/fpm/fpm/fpm_worker_pool.lo sapi/fpm/fpm/zlog.lo sapi/fpm/fpm/fpm_trace.lo sapi/fpm/fpm/fpm_trace_ptrace.lo main/internal_functions.lo FPM is linked with apache but the apr lib is not known at compile time. There is the same problem when compiling libphp5.so which is linked agains FPM object files and libevent is not known at compile time: # make libs/libphp5.bundle sapi/fpm/fpm/fpm_children.o: In function `fpm_children_make': /LIBRE/dev/php-src/branches/PHP_5_3/sapi/fpm/fpm/fpm_children.c:381: undefined reference to `event_reinit' [2010-09-01 12:05:43] f...@php.net I have a similar issue with the current PHP_5_3. When the php-fpm is built, it's linked against : sapi/apache2handler/mod_php5.lo sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo sapi/apache2handler/php_functions.lo I think it's somehow related to http://bugs.php.net/52498. [2010-08-04 10:35:24] ali at aliziad dot clom fyi: I am also getting the same error with php 5.3.3 (/w apxs and fpm) on CentOS -ali 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=52419 -- Edit this bug report at http://bugs.php.net/bug.php?id=52419&edit=1
Bug #52419 [Com]: Unable to compile PHP with both Apache2 and FPM support
Edit report at http://bugs.php.net/bug.php?id=52419&edit=1 ID: 52419 Comment by: james dot butler at sandfox dot co dot uk Reported by:php-bugs at majkl578 dot cz Summary:Unable to compile PHP with both Apache2 and FPM support Status: Open Type: Bug Package:Compile Failure Operating System: Linux Debian PHP Version:5.3.3 Block user comment: N New Comment: I can confirm this is an issue on Centos 5.5 64bit get exactly the same error when trying to compile with apxs AND fpm both enabled. Removing either one from the config line results in successful compilation. Previous Comments: [2010-09-01 17:42:25] f...@php.net the problem is the same if compiling SAPI apache2handler with litespeed. The same with fpm and litespeed. Is it possible to compile PHP with multiple SAPI ? [2010-09-01 14:29:49] f...@php.net The problem is: in the general Makefile there is: BUILD_FPM = $(LIBTOOL) --mode=link $(CC) -export-dynamic $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(EXTRA_LDFLAGS_PROGRAM) $(LDFLAGS) $(PHP_RPATHS) $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(EXTRA_LIBS) $(SAPI_EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $(SAPI_FPM_PATH) and PHP_SAPI_OBJS = sapi/apache2handler/mod_php5.lo sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo sapi/apache2handler/php_functions.lo sapi/fpm/fpm/fastcgi.lo sapi/fpm/fpm/fpm.lo sapi/fpm/fpm/fpm_children.lo sapi/fpm/fpm/fpm_cleanup.lo sapi/fpm/fpm/fpm_clock.lo sapi/fpm/fpm/fpm_conf.lo sapi/fpm/fpm/fpm_env.lo sapi/fpm/fpm/fpm_events.lo sapi/fpm/fpm/fpm_main.lo sapi/fpm/fpm/fpm_php.lo sapi/fpm/fpm/fpm_php_trace.lo sapi/fpm/fpm/fpm_process_ctl.lo sapi/fpm/fpm/fpm_request.lo sapi/fpm/fpm/fpm_shm.lo sapi/fpm/fpm/fpm_shm_slots.lo sapi/fpm/fpm/fpm_signals.lo sapi/fpm/fpm/fpm_sockets.lo sapi/fpm/fpm/fpm_status.lo sapi/fpm/fpm/fpm_stdio.lo sapi/fpm/fpm/fpm_unix.lo sapi/fpm/fpm/fpm_worker_pool.lo sapi/fpm/fpm/zlog.lo sapi/fpm/fpm/fpm_trace.lo sapi/fpm/fpm/fpm_trace_ptrace.lo main/internal_functions.lo FPM is linked with apache but the apr lib is not known at compile time. There is the same problem when compiling libphp5.so which is linked agains FPM object files and libevent is not known at compile time: # make libs/libphp5.bundle sapi/fpm/fpm/fpm_children.o: In function `fpm_children_make': /LIBRE/dev/php-src/branches/PHP_5_3/sapi/fpm/fpm/fpm_children.c:381: undefined reference to `event_reinit' [2010-09-01 12:05:43] f...@php.net I have a similar issue with the current PHP_5_3. When the php-fpm is built, it's linked against : sapi/apache2handler/mod_php5.lo sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo sapi/apache2handler/php_functions.lo I think it's somehow related to http://bugs.php.net/52498. [2010-08-04 10:35:24] ali at aliziad dot clom fyi: I am also getting the same error with php 5.3.3 (/w apxs and fpm) on CentOS -ali [2010-07-23 20:44:23] ras...@php.net You could try it in a clean Debian image using the free vmware player and the images from http://www.thoughtpolice.co.uk/vmware/ Just so you have a clean environment to compare yours against. 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=52419 -- Edit this bug report at http://bugs.php.net/bug.php?id=52419&edit=1
Bug #52753 [Asn->Opn]: With proposed fix: use of '/' in httpd.conf causes apache crash
Edit report at http://bugs.php.net/bug.php?id=52753&edit=1
ID: 52753
Updated by: ka...@php.net
Reported by:jrompre at gmail dot com
Summary:With proposed fix: use of '/' in httpd.conf causes
apache crash
-Status: Assigned
+Status: Open
Type: Bug
Package:Windows Installer
Operating System: Win/XP
PHP Version:5.3.3
-Assigned To:pajoye
+Assigned To:
Block user comment: N
Previous Comments:
[2010-09-02 11:09:55] ka...@php.net
Seems like its intended in the win-installer, see:
PHPInstallerScripts{XXX}.vbs
strPHPPath = Replace(strInstallDir,"\","/")
Guess that should be reverted, but I don't have karma for that part.
Pierre? :)
[2010-08-31 21:05:50] jrompre at gmail dot com
Description:
This is easy, and I fixed it myself. I installed the V6 thread-safe
version (Windows) with the Apache2.2x module config option, and
restarted Apache, which caused an Apache crash. The problem was caused
by the httpd.conf added fragment which wrongly uses the Unix path
element separator - changing the '/' to a '\' fixed the problem, and I
could also see the test hello.php output as expected.
#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
PHPIniDir "C:/Program Files/PHP/"
LoadModule php5_module "C:/Program Files/PHP/php5apache2_2.dll"
#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
(change all '/' to '\' to prevent crashes in Windows)
Test script:
---
N/A
Expected result:
See description
Actual result:
--
See description
--
Edit this bug report at http://bugs.php.net/bug.php?id=52753&edit=1
Bug #52753 [Opn->Asn]: With proposed fix: use of '/' in httpd.conf causes apache crash
Edit report at http://bugs.php.net/bug.php?id=52753&edit=1
ID: 52753
Updated by: ka...@php.net
Reported by:jrompre at gmail dot com
Summary:With proposed fix: use of '/' in httpd.conf causes
apache crash
-Status: Open
+Status: Assigned
Type: Bug
Package:Apache2 related
Operating System: Win/XP
PHP Version:5.3.3
-Assigned To:
+Assigned To:pajoye
Block user comment: N
New Comment:
Seems like its intended in the win-installer, see:
PHPInstallerScripts{XXX}.vbs
strPHPPath = Replace(strInstallDir,"\","/")
Guess that should be reverted, but I don't have karma for that part.
Pierre? :)
Previous Comments:
[2010-08-31 21:05:50] jrompre at gmail dot com
Description:
This is easy, and I fixed it myself. I installed the V6 thread-safe
version (Windows) with the Apache2.2x module config option, and
restarted Apache, which caused an Apache crash. The problem was caused
by the httpd.conf added fragment which wrongly uses the Unix path
element separator - changing the '/' to a '\' fixed the problem, and I
could also see the test hello.php output as expected.
#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
PHPIniDir "C:/Program Files/PHP/"
LoadModule php5_module "C:/Program Files/PHP/php5apache2_2.dll"
#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
(change all '/' to '\' to prevent crashes in Windows)
Test script:
---
N/A
Expected result:
See description
Actual result:
--
See description
--
Edit this bug report at http://bugs.php.net/bug.php?id=52753&edit=1
Bug #47584 [Asn->Fbk]: WSDL error in soapClient causes Fatal Error
Edit report at http://bugs.php.net/bug.php?id=47584&edit=1 ID: 47584 Updated by: dmi...@php.net Reported by:gem at rellim dot com Summary:WSDL error in soapClient causes Fatal Error -Status: Assigned +Status: Feedback Type: Bug Package:SOAP related Operating System: Linux PHP Version:5.2.9 Assigned To:dmitry Block user comment: N New Comment: BTW despite SoapClient emits a fatal error it already throws exception which can be caught (even in 5.2 brunch). Previous Comments: [2010-06-24 01:55:11] gem at rellim dot com This is a still a 100% show stopper for me. I can not make PHP pages live that will crash on simple network errors. [2010-06-22 10:35:23] florent dot biville at insa-rouen dot fr I can confirm I encounter the same problem. Despite everything documented, problems with WSDL reading will trigger a fatal error. [2010-04-09 07:41:35] pwb at evanr dot com This is a real issue, even when the SoapClient is set to throw exceptions and not errors. This fatal error cannot be defeated even with the exceptions option set to true. We're experiencing this in 5.2.13 on linux x64. A fatal error is thrown not only when WSDL can't be loaded but as well when an internal reference in the WSDL (e.g. to a namespace) cannot be imported/resolved. [2009-03-06 17:49:08] gem at rellim dot com Why does it work OK for you and not for me? Just because it works on one host for you does not mean it does not fail for me. This is the entire program to reproduce: http://google.com'); ?> PHP Fatal error: SOAP-ERROR: Parsing WSDL: I can reproduce on several different hosts. I am not running Xdebug, eaccelerator, or any other add in. [2009-03-06 15:32:18] il...@php.net It already works that way. 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=47584 -- Edit this bug report at http://bugs.php.net/bug.php?id=47584&edit=1
[PHP-BUG] Bug #52765 [NEW]: openssl_csr_get_subject returns a single element array when subjectName starts
From: Operating system: Linux PHP version: 5.3.3 Package: OpenSSL related Bug Type: Bug Bug description:openssl_csr_get_subject returns a single element array when subjectName starts Description: openssl_csr_get_subject returns a single element array when the subjectName starts with DC, e.g.: for subjectName = /DC=at/DC=austriangridca/O=UniVie/OU=VCPC/CN=Willy Weisz openssl_csr_get_subject returns an array Array ( [DC] => at/DC=austriangridca/O=UniVie/OU=VCPCWilly Weisz ) instead of Array ( [DC] => at [DC] => austriangridca [O] => UniVie [OU] => VCPC [CN] => Willy Weisz ) -- Edit bug report at http://bugs.php.net/bug.php?id=52765&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52765&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52765&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52765&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52765&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52765&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52765&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52765&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52765&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52765&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52765&r=support Expected behavior: http://bugs.php.net/fix.php?id=52765&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52765&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52765&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52765&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52765&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52765&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52765&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52765&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52765&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52765&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52765&r=mysqlcfg
