[PHP-BUG] Bug #52922 [NEW]: fastcgi SoapClient set_error_handler cause core
From:
Operating system: Linux 2.6.18.8-xenU
PHP version: 5.3.3
Package: SOAP related
Bug Type: Bug
Bug description:fastcgi SoapClient set_error_handler cause core
Description:
I use apache2.0 fastcgi, and the Network for me is unreachable.
When I try to new the SoapClient the first time.
I get this:
[soapclient.soapclient]: failed to open stream: Network is unreachable
It seems ok.
But then I try the second(or third) time, I get a core.
The way I started the fastcgi:
PHP_FCGI_CHILDREN=1
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS
exec php/bin/php-cgi -b 127.0.0.1:7654 -c php/etc/php.ini
Test script:
---
?php
function err_handler(){
$error = func_get_args();
echo $error[0]..$error[1]. .$error[2].
.$error[3].\n;
exit;
//If I change exit to return ,there is no core.
//return true;
}
set_error_handler('err_handler');
//nomatter which the wsdl file is.
$client = new SoapClient(http://www.google.com:8080/hello.WSDL;);
?
Expected result:
[soapclient.soapclient]: failed to open stream: Network is unreachable
Actual result:
--
#0 0x00302af6ff20 in strlen () from /lib64/tls/libc.so.6
#1 0x006ff8f6 in php_stream_display_wrapper_errors
(wrapper=0xdcb3e0, path=Variable path is not available.
) at /home/mall/src/php-5.3.3/main/streams/streams.c:151
#2 0x00702c72 in _php_stream_open_wrapper_ex (path=0xfc4c50
http://www.google.com:8080/hello.WSDL;, mode=0x822303 rb, options=8,
opened_path=0x0, context=0x2b8fd8d23b18) at
/home/mall/src/php-5.3.3/main/streams/streams.c:1941
#3 0x0048c74b in php_libxml_streams_IO_open_wrapper
(filename=Variable filename is not available.
) at /home/mall/src/php-5.3.3/ext/libxml/libxml.c:317
#4 0x0048c8be in php_libxml_input_buffer_create_filename
(URI=Variable URI is not available.
) at /home/mall/src/php-5.3.3/ext/libxml/libxml.c:326
#5 0x00302d72aff4 in xmlNewInputFromFile () from
/usr/lib64/libxml2.so.2
#6 0x00302d735348 in xmlLoadExternalEntity () from
/usr/lib64/libxml2.so.2
#7 0x00302d7352bd in xmlLoadExternalEntity () from
/usr/lib64/libxml2.so.2
#8 0x00302d74425c in xmlCreateURLParserCtxt () from
/usr/lib64/libxml2.so.2
#9 0x00616509 in soap_xmlParseFile (filename=Variable filename
is not available.
) at /home/mall/src/php-5.3.3/ext/soap/php_xml.c:91
#10 0x006083a7 in load_wsdl_ex (this_ptr=0x2b8fd8d23110,
struri=0x2b8fd8d25f18 http://www.google.com:8080/hello.WSDL;,
ctx=0x7fffd2215bd0,
include=0) at /home/mall/src/php-5.3.3/ext/soap/php_sdl.c:299
#11 0x0061438b in get_sdl (this_ptr=0x2b8fd8d23110,
uri=0x2b8fd8d25f18 http://www.google.com:8080/hello.WSDL;,
cache_wsdl=Variable cache_wsdl is not available.
)
at /home/mall/src/php-5.3.3/ext/soap/php_sdl.c:714
#12 0x005ded29 in zim_SoapClient_SoapClient (ht=1,
return_value=Variable return_value is not available.
) at /home/mall/src/php-5.3.3/ext/soap/soap.c:2674
#13 0x00760340 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2b8fdbcfc050) at
/home/mall/src/php-5.3.3/Zend/zend_vm_execute.h:316
#14 0x0075f839 in execute (op_array=0x2b8fd8d23140) at
/home/mall/src/php-5.3.3/Zend/zend_vm_execute.h:107
#15 0x0073e985 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/mall/src/php-5.3.3/Zend/zend.c:1194
#16 0x006eea58 in php_execute_script (primary_file=0x7fffd221b9d0)
at /home/mall/src/php-5.3.3/main/main.c:2260
#17 0x007c3a80 in main (argc=5, argv=0x7fffd221bb58) at
/home/mall/src/php-5.3.3/sapi/cgi/cgi_main.c:2109
--
Edit bug report at http://bugs.php.net/bug.php?id=52922edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52922r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52922r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52922r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52922r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52922r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52922r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52922r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52922r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52922r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52922r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52922r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52922r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52922r=submittedtwice
register_globals:
[PHP-BUG] Bug #52923 [NEW]: parse_url corrupts some UTF-8 strings
From:
Operating system: MS Windows XP
PHP version: 5.3.3
Package: *URL Functions
Bug Type: Bug
Bug description:parse_url corrupts some UTF-8 strings
Description:
I have tested this with PHP 5.2.9 and 5.3.3.
Some UTF-8 strings are not being processed correctly by parse_url.
In the given example, the result of the evaluation of strings which
contains the chars '×' or '×' is corrupt, whereas the string
'××ש××'(which does not contain the above chars) is being processed
correctly.
The affected characters (in UTF-8) are comprised of the following bytes:
× - d7|9d
× - d7|90
Those are converted to a char which contains the following bytes: d7|5f.
In addition to ruining the url, this char is not safe with preg_replace.
Therefore, if we merge the result of parse_url back into a string, and then
attempting to replace, say, spaces with underscores using preg_replace, we
will get an empty string.
I believe that this is similar to bug #26391.
Test script:
---
$url = 'http://www.mysite.org/he/פר××ק×××/ByYear.html';
$url = parse_url($url); //$url['path'] is now corrupt
$url = preg_replace('/\s+/u','_',$url['path']); //$url is now undefined
Expected result:
The correct portion of the url.
Actual result:
--
Corrupt string (or blank after using preg_replace).
--
Edit bug report at http://bugs.php.net/bug.php?id=52923edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52923r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52923r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52923r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52923r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52923r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52923r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52923r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52923r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52923r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52923r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52923r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52923r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52923r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52923r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52923r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52923r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52923r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52923r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52923r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52923r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52923r=mysqlcfg
Bug-Req #52923 [Opn]: parse_url corrupts some UTF-8 strings
Edit report at http://bugs.php.net/bug.php?id=52923edit=1
ID: 52923
Updated by: ras...@php.net
Reported by:masteram at gmail dot com
Summary:parse_url corrupts some UTF-8 strings
Status: Open
-Type: Bug
+Type: Feature/Change Request
Package:*URL Functions
Operating System: MS Windows XP
PHP Version:5.3.3
Block user comment: N
New Comment:
Reclassifying as a feature request. parse_url has never been
multibyte-aware.
Previous Comments:
[2010-09-25 11:09:39] masteram at gmail dot com
Description:
I have tested this with PHP 5.2.9 and 5.3.3.
Some UTF-8 strings are not being processed correctly by parse_url.
In the given example, the result of the evaluation of strings which
contains the chars '×' or '×' is corrupt, whereas the string
'××ש××'(which does not contain the above chars) is being processed
correctly.
The affected characters (in UTF-8) are comprised of the following
bytes:
× - d7|9d
× - d7|90
Those are converted to a char which contains the following bytes:
d7|5f.
In addition to ruining the url, this char is not safe with
preg_replace.
Therefore, if we merge the result of parse_url back into a string, and
then attempting to replace, say, spaces with underscores using
preg_replace, we will get an empty string.
I believe that this is similar to bug #26391.
Test script:
---
$url = 'http://www.mysite.org/he/פר××ק×××/ByYear.html';
$url = parse_url($url); //$url['path'] is now corrupt
$url = preg_replace('/\s+/u','_',$url['path']); //$url is now undefined
Expected result:
The correct portion of the url.
Actual result:
--
Corrupt string (or blank after using preg_replace).
--
Edit this bug report at http://bugs.php.net/bug.php?id=52923edit=1
Req #52923 [Opn]: parse_url corrupts some UTF-8 strings
Edit report at http://bugs.php.net/bug.php?id=52923edit=1
ID: 52923
Updated by: paj...@php.net
Reported by:masteram at gmail dot com
Summary:parse_url corrupts some UTF-8 strings
Status: Open
Type: Feature/Change Request
Package:*URL Functions
Operating System: MS Windows XP
PHP Version:5.3.3
Block user comment: N
New Comment:
What's about a parse_url_utf8, like what we have for IDN? It could be
easy to implement it using either native OS APIs (when available) or
using external libraries (there is a couple of good one out there).
Previous Comments:
[2010-09-25 11:42:29] ras...@php.net
Reclassifying as a feature request. parse_url has never been
multibyte-aware.
[2010-09-25 11:09:39] masteram at gmail dot com
Description:
I have tested this with PHP 5.2.9 and 5.3.3.
Some UTF-8 strings are not being processed correctly by parse_url.
In the given example, the result of the evaluation of strings which
contains the chars '×' or '×' is corrupt, whereas the string
'××ש××'(which does not contain the above chars) is being processed
correctly.
The affected characters (in UTF-8) are comprised of the following
bytes:
× - d7|9d
× - d7|90
Those are converted to a char which contains the following bytes:
d7|5f.
In addition to ruining the url, this char is not safe with
preg_replace.
Therefore, if we merge the result of parse_url back into a string, and
then attempting to replace, say, spaces with underscores using
preg_replace, we will get an empty string.
I believe that this is similar to bug #26391.
Test script:
---
$url = 'http://www.mysite.org/he/פר××ק×××/ByYear.html';
$url = parse_url($url); //$url['path'] is now corrupt
$url = preg_replace('/\s+/u','_',$url['path']); //$url is now undefined
Expected result:
The correct portion of the url.
Actual result:
--
Corrupt string (or blank after using preg_replace).
--
Edit this bug report at http://bugs.php.net/bug.php?id=52923edit=1
Req #52923 [Opn]: parse_url corrupts some UTF-8 strings
Edit report at http://bugs.php.net/bug.php?id=52923edit=1
ID: 52923
Updated by: cataphr...@php.net
Reported by:masteram at gmail dot com
Summary:parse_url corrupts some UTF-8 strings
Status: Open
Type: Feature/Change Request
Package:*URL Functions
Operating System: MS Windows XP
PHP Version:5.3.3
Block user comment: N
New Comment:
I'd say this request/bug is bogus because such URL is not valid
according to RFC 3986. He should first percent-encode all the characters
that are unreserved (perhaps after doing some unicode normalization) and
only then parse the URL.
Previous Comments:
[2010-09-25 12:15:15] paj...@php.net
What's about a parse_url_utf8, like what we have for IDN? It could be
easy to implement it using either native OS APIs (when available) or
using external libraries (there is a couple of good one out there).
[2010-09-25 11:42:29] ras...@php.net
Reclassifying as a feature request. parse_url has never been
multibyte-aware.
[2010-09-25 11:09:39] masteram at gmail dot com
Description:
I have tested this with PHP 5.2.9 and 5.3.3.
Some UTF-8 strings are not being processed correctly by parse_url.
In the given example, the result of the evaluation of strings which
contains the chars '×' or '×' is corrupt, whereas the string
'××ש××'(which does not contain the above chars) is being processed
correctly.
The affected characters (in UTF-8) are comprised of the following
bytes:
× - d7|9d
× - d7|90
Those are converted to a char which contains the following bytes:
d7|5f.
In addition to ruining the url, this char is not safe with
preg_replace.
Therefore, if we merge the result of parse_url back into a string, and
then attempting to replace, say, spaces with underscores using
preg_replace, we will get an empty string.
I believe that this is similar to bug #26391.
Test script:
---
$url = 'http://www.mysite.org/he/פר××ק×××/ByYear.html';
$url = parse_url($url); //$url['path'] is now corrupt
$url = preg_replace('/\s+/u','_',$url['path']); //$url is now undefined
Expected result:
The correct portion of the url.
Actual result:
--
Corrupt string (or blank after using preg_replace).
--
Edit this bug report at http://bugs.php.net/bug.php?id=52923edit=1
Req #52923 [Opn]: parse_url corrupts some UTF-8 strings
Edit report at http://bugs.php.net/bug.php?id=52923edit=1
ID: 52923
Updated by: paj...@php.net
Reported by:masteram at gmail dot com
Summary:parse_url corrupts some UTF-8 strings
Status: Open
Type: Feature/Change Request
Package:*URL Functions
Operating System: MS Windows XP
PHP Version:5.3.3
Block user comment: N
New Comment:
It is not a bogus request. The idea would also to get the decoded (to
UTF-8) URL elements as result. It is also a good complement to IDN
support
Previous Comments:
[2010-09-25 14:19:40] cataphr...@php.net
I'd say this request/bug is bogus because such URL is not valid
according to RFC 3986. He should first percent-encode all the characters
that are unreserved (perhaps after doing some unicode normalization) and
only then parse the URL.
[2010-09-25 12:15:15] paj...@php.net
What's about a parse_url_utf8, like what we have for IDN? It could be
easy to implement it using either native OS APIs (when available) or
using external libraries (there is a couple of good one out there).
[2010-09-25 11:42:29] ras...@php.net
Reclassifying as a feature request. parse_url has never been
multibyte-aware.
[2010-09-25 11:09:39] masteram at gmail dot com
Description:
I have tested this with PHP 5.2.9 and 5.3.3.
Some UTF-8 strings are not being processed correctly by parse_url.
In the given example, the result of the evaluation of strings which
contains the chars '×' or '×' is corrupt, whereas the string
'××ש××'(which does not contain the above chars) is being processed
correctly.
The affected characters (in UTF-8) are comprised of the following
bytes:
× - d7|9d
× - d7|90
Those are converted to a char which contains the following bytes:
d7|5f.
In addition to ruining the url, this char is not safe with
preg_replace.
Therefore, if we merge the result of parse_url back into a string, and
then attempting to replace, say, spaces with underscores using
preg_replace, we will get an empty string.
I believe that this is similar to bug #26391.
Test script:
---
$url = 'http://www.mysite.org/he/פר××ק×××/ByYear.html';
$url = parse_url($url); //$url['path'] is now corrupt
$url = preg_replace('/\s+/u','_',$url['path']); //$url is now undefined
Expected result:
The correct portion of the url.
Actual result:
--
Corrupt string (or blank after using preg_replace).
--
Edit this bug report at http://bugs.php.net/bug.php?id=52923edit=1
Req #52923 [Opn]: parse_url corrupts some UTF-8 strings
Edit report at http://bugs.php.net/bug.php?id=52923edit=1
ID: 52923
User updated by:masteram at gmail dot com
Reported by:masteram at gmail dot com
Summary:parse_url corrupts some UTF-8 strings
Status: Open
Type: Feature/Change Request
Package:*URL Functions
Operating System: MS Windows XP
PHP Version:5.3.3
Block user comment: N
New Comment:
I tend to agree with Pajoye.
Although RFC-3986 calls for the use of percent-encoding for URLs, I
believe that it also mentions the IDN format (and the way things look
today, there is a host of websites that use UTF-8 encoding, which
benefits the readability of internationalized urls).
I admit not being an expert in URL encoding, but it seems to me that
corrupting a string, even if it does not meet the current standards, is
a bad habit.
In addition, utf-8 encoded URLs seem to be quite common on reality. Take
the international versions of Wikipedia as an example.
If I'm wrong about that, I would be more than happy to know it.
I am not sure that the encode-analyze-merge-decode procedure is really
the best choice. Perhaps the streamlined alternative should be
considered. It sure wouldn't hurt.
I, for one, am currently using 'ASCII-only' URLs.
Previous Comments:
[2010-09-25 14:34:34] paj...@php.net
It is not a bogus request. The idea would also to get the decoded (to
UTF-8) URL elements as result. It is also a good complement to IDN
support
[2010-09-25 14:19:40] cataphr...@php.net
I'd say this request/bug is bogus because such URL is not valid
according to RFC 3986. He should first percent-encode all the characters
that are unreserved (perhaps after doing some unicode normalization) and
only then parse the URL.
[2010-09-25 12:15:15] paj...@php.net
What's about a parse_url_utf8, like what we have for IDN? It could be
easy to implement it using either native OS APIs (when available) or
using external libraries (there is a couple of good one out there).
[2010-09-25 11:42:29] ras...@php.net
Reclassifying as a feature request. parse_url has never been
multibyte-aware.
[2010-09-25 11:09:39] masteram at gmail dot com
Description:
I have tested this with PHP 5.2.9 and 5.3.3.
Some UTF-8 strings are not being processed correctly by parse_url.
In the given example, the result of the evaluation of strings which
contains the chars '×' or '×' is corrupt, whereas the string
'××ש××'(which does not contain the above chars) is being processed
correctly.
The affected characters (in UTF-8) are comprised of the following
bytes:
× - d7|9d
× - d7|90
Those are converted to a char which contains the following bytes:
d7|5f.
In addition to ruining the url, this char is not safe with
preg_replace.
Therefore, if we merge the result of parse_url back into a string, and
then attempting to replace, say, spaces with underscores using
preg_replace, we will get an empty string.
I believe that this is similar to bug #26391.
Test script:
---
$url = 'http://www.mysite.org/he/פר××ק×××/ByYear.html';
$url = parse_url($url); //$url['path'] is now corrupt
$url = preg_replace('/\s+/u','_',$url['path']); //$url is now undefined
Expected result:
The correct portion of the url.
Actual result:
--
Corrupt string (or blank after using preg_replace).
--
Edit this bug report at http://bugs.php.net/bug.php?id=52923edit=1
Req #52569 [Com]: Implement ondemand process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569edit=1
ID: 52569
Comment by: mplomer at gmx dot de
Reported by:mplomer at gmx dot de
Summary:Implement ondemand process-manager (to allow zero
children)
Status: Analyzed
Type: Feature/Change Request
Package:FPM related
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
Released patch v6 - Updated patch to be compatible with current PHP_5_3
branch (rev 303365)
There are no functional changes against v5
Merged (removed) parts which have already been committed:
- rev 301886: only one process (for all pools) could be killed by the
'dynamic' process manager
- rev 301912: Changed listen.backlog in the FPM configuration file to
default to 128 instead of -1
- rev 301913: Add libevent version to the startup debug log in FPM
- rev 301925: add 'max children reached' to the FPM status page
Changes:
- Undo change in config.m4 which has IMHO nothing to do with this patch
- Merged listen.backlog part in php-fpm.conf.in from trunk (trunk and
5.3-branch is currently out of sync here!)
- (small code beautify)
Previous Comments:
[2010-09-13 06:27:20] f...@php.net
You should make clean before recompiling with v5 patch.
The v5 patch does not apply on 5.3.3, it applies on the svn PHP5_3_3
branch.
++ Jerome
[2010-09-13 03:30:56] dennisml at conversis dot de
Is v5 of the patch known not to work with fpm in php 5.3.3? When
applying the patch I get the following segfault:
Program received signal SIGSEGV, Segmentation fault.
0x005cf319 in fpm_env_conf_wp (wp=value optimized out)
at /home/dennis/php-5.3.3/sapi/fpm/fpm/fpm_env.c:141
141 if (*kv-value == '$') {
[2010-09-05 20:42:56] f...@php.net
@dennisml at conversis dot de
It's complex to do and security risky. Don't want to mess with that.
[2010-09-04 16:26:06] dennisml at conversis dot de
Since this patch causes the master process to dynamically fork children
on demand I'm wondering if it would be feasible to introduce the
possibility to do setuid()/setgid() calls after the fork to run the
child process with different user id's?
What I'm thinking about is the mass-hosting case that was previously
talked about on the mailinglist. Back then this would have been quite a
bit of work to do but with this patch this should be much easier to
accomplish.
[2010-08-30 10:21:37] mplomer at gmx dot de
Some test results of the ondemand-pm:
General
- Pool has to start with 0 children - OK
- Handling and checking of new config options - OK
Concurrent requests
- Children has to be forked immediately on new requests without delay -
OK
- Idle children has to be killed after pm.process_idle_timeout + 0-1s -
OK
- When there are more than one idle children, kill only one per second
PER POOL - OK
Reaching pm.max_children limit
- No more processes has to be created - OK
- Requests have to wait until one child becomes idle and then get
handled immediately without further delay - OK
- When limit is reached, issue a warning and increase status counter
(and do this only once) - OK:
Aug 28 13:39:41.537174 [WARNING] pid 27540,
fpm_pctl_on_socket_accept(), line 507: [pool www] server reached
max_children setting (10), consider raising it
- Warning is re-issued after children count decreases and hit the limit
again - OK
CPU burns
- When reaching max_children limit, pause libevent callback and reenable
it in the maintenance routine, to avoid CPU burns - OK
- When children takes too long to accept() the request, avoid CPU burn -
NOTOK
- happens sometimes (in praxis only sometimes after forking) - to
reproduce add an usleep(5) in children's code after fork(), or
apachebench with ~200 concurrent requests :-)
- You get a lot of: fpm_pctl_on_socket_accept(), line 502: [pool www]
fpm_pctl_on_socket_accept() called
- It's not a big problem, because this doesn't take much time (in one
rare case it took ~90ms on my machine), but it's not nice, especially
when the server is flooded with requests
- one idea:
- do not re-enable event-callback in fpm_pctl_on_socket_accept
- send an event from children just after accept() to parent process
- re-enable event-callback in parent process, when it receives this
event from children
- in case of an error it is re-enabled in the maintainance routine
after max 1s, which is IMHO not bad to throttle requests in case of
error
Stress tests
- Test-machine: Intel Core i7 930 (4 x 2.8 GHz) (VMware with
Bug #41980 [Com]: encoding problem
Edit report at http://bugs.php.net/bug.php?id=41980edit=1 ID: 41980 Comment by: roger21 at free dot fr Reported by:borys dot forytarz at gmail dot com Summary:encoding problem Status: Bogus Type: Bug Package:DOM XML related Operating System: Linux PHP Version:5.2CVS-2007-07-13 Assigned To:rrichards Block user comment: N New Comment: i have a problem with loadHTMLFile that could be related, when i load an utf-8 encoded html page (that uses a meta tag for encoding and the header is utf-8 also) the result is a doubly utf8 encoded data and i need to use utf8_decode to get the actual utf8 encoded data, this is fairly crazy how loadHTMLFile check for encoding and why does it fails? Previous Comments: [2007-07-13 15:39:21] rricha...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. The data in your input file (contents.tpl) is not UTF-8 (as you even see based on the mbstring result). You need to get it saved properly there, add an xml decl with the encoding specific to the top, or load the data into a string, convert to UTF-8 and load the document using the converted string via loadXML() or loadHTML(). [2007-07-13 13:13:39] borys dot forytarz at gmail dot com I have tried it - nothing changed. The same problem... [2007-07-13 10:48:08] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-07-12 21:20:20] borys dot forytarz at gmail dot com I've been working around this for half a day and figured out nothing what could be wrong. I have also checked many discussions and message boards and seen that there is a lot of people having the same problem and having no solution. So that's why I decided to report it as bug because I'm pretty sure that something is wrong and it is not my fault. [2007-07-12 21:09:05] tony2...@php.net Please figure out what's wrong with your file first before reporting any bugs. 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=41980 -- Edit this bug report at http://bugs.php.net/bug.php?id=41980edit=1
[PHP-BUG] Bug #52924 [NEW]: resource type set to empty after bad mcrypt_generic_init call
From: Operating system: Windows 7 PHP version: 5.3.3 Package: mcrypt related Bug Type: Bug Bug description:resource type set to empty after bad mcrypt_generic_init call Description: Calling mcrypt_generic_init() with bad values changes the resource type from mcrypt to Unknown. It seems like what should happen is that the resource type should remain the same and that mcrypt_generic_init should simply do nothing. Maybe output a warning (as it currently does) but not change the resource type. A bad call to curl_setopt(), for example, doesn't change the resource type from curl to Unknown as demonstrated thusly: ?php $curl = curl_init(); @curl_setopt($curl); var_dump($curl); ? Per that it doesn't seem like a bad call to mcrypt_generic_init() ought to change anything either. Test script: --- ?php $mcrypt = @mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_ECB, ''); @mcrypt_generic_init($mcrypt, '', ''); var_dump($mcrypt); ? Expected result: resource(4) of type (mcrypt) Actual result: -- resource(4) of type (Unknown) -- Edit bug report at http://bugs.php.net/bug.php?id=52924edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52924r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52924r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52924r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52924r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52924r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52924r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52924r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52924r=needscript Try newer version: http://bugs.php.net/fix.php?id=52924r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52924r=support Expected behavior: http://bugs.php.net/fix.php?id=52924r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52924r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52924r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52924r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52924r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52924r=dst IIS Stability: http://bugs.php.net/fix.php?id=52924r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52924r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52924r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52924r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52924r=mysqlcfg
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=52412edit=1
ID: 52412
Comment by: alex dot offshore at gmail dot com
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:
Temporary solution.
Caveats and notices:
- The class actually WILL BE DEFINED ANYWAY;
- 'eval' usage;
- __callStatic used to avoid method not found error.
?php
function __autoload($className)
{
echo Want to load $className.\n;
// assuming we can not load class
// error handling code
{
eval('class ' . $className . ' { static function __callStatic($n,
$a) { return false; } }');
throw new Exception(Unable to load $className.);
}
}
try
{
//new MissingClass(); // works as expected
MissingClass::someFunction();
}
catch (Exception $e)
{
echo 'CAUGHT: ' . $e-getMessage(), \n;
}
Previous Comments:
[2010-09-03 03:26:56] php dot net at phrozenbyte dot de
Same on Ubuntu 10.04 / Apache 2.2 and CLI mode
Test script:
---
?php
spl_autoload_register(
function($autoload) {
throw new Exception();
}
);
try {
Foo::bar();
} catch(Exception $e) {
echo Exception caught\n;
}
?
Expected result:
Exception caught
Actual result:
--
Fatal error: Class 'Foo' not found in /home/daniel/www/other/php-bug.php
on line 0
[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:
---
?php
function __autoload($class_name) {
throw new Exception($class_name);
}
try {
Application::start();
// new Application(); works fine
} catch (Exception $ex) {
var_dump($ex);
}
Expected result:
The script should var_dump() an exception with the Message 'Application'
as it does when instantiating a class.
Actual result:
--
The script dies with Fatal error: Class 'Application' not found.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52412edit=1
