Bug #52847 [Opn->Dup]: Files to include are always searched for in current directory
Edit report at http://bugs.php.net/bug.php?id=52847&edit=1
ID: 52847
Updated by: ahar...@php.net
Reported by:mail_ben_schmidt at yahoo dot com dot au
Summary:Files to include are always searched for in current
directory
-Status: Open
+Status: Duplicate
Type: Bug
Package:Scripting Engine problem
Operating System: Mac OS X 10.6.2
PHP Version:5.3.2
Block user comment: N
New Comment:
This is intended behaviour: php_resolve_path() includes a fallback case
at the end to search the directory the currently executing file lives in
if all else fails.
I'll update the documentation. Duping to doc bug #51569.
Previous Comments:
[2010-09-15 03:32:15] mail_ben_schmidt at yahoo dot com dot au
Actually, this may be a behaviour problem, not a documentation problem.
[2010-09-15 03:26:04] mail_ben_schmidt at yahoo dot com dot au
Description:
The documentation at include and include_path suggests that the current
directory will not be searched if a '.' is not in include path. Even
though I can see no reason (e.g. in the source code referred to by bug
#51569) that the current directory should be searched, it can be
demonstrated that it is.
See also bug #51569 and bug #52845 for further include_path
documentation deficiencies.
Test script:
---
1. Place in a file 'test/test.php':
set_include_path('/bin'); // won't find any php files here!
include('another.php');
2. touch another.php
3. php test/test.php
Expected result:
Warning that another.php cannot be found.
Actual result:
--
No warning.
N.B. In line with the undocumented feature mentioned in bug #51569, if
another.php is moved to test/another.php, it is still found also,
because it is in the directory of the running script.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52847&edit=1
Req #52832 [Opn->Asn]: unserialize() performance
Edit report at http://bugs.php.net/bug.php?id=52832&edit=1 ID: 52832 Updated by: ka...@php.net Reported by:galaxy dot mipt at gmail dot com Summary:unserialize() performance -Status: Open +Status: Assigned Type: Feature/Change Request Package:Performance problem Operating System: Linux PHP Version:5.3.3 -Assigned To: +Assigned To:kalle Block user comment: N New Comment: Hi we cannot merge this into 5.3, as it changes a structure (php_unserialize_data) thats exported to extensions in a type, breaking the ABI. But without a doubt it should go in trunk atleast. Previous Comments: [2010-09-14 18:36:53] galaxy dot mipt at gmail dot com Added a patch against latest SVN version, did things in a way that required least code modification. Here goes the test script: It's a bit memory consuming, so array sizes might need to be reduced depending on available hardware. My test results: Original PHP: Size: 10Serialize: 483msUnserialize: 470ms Size: 20Serialize: 1047ms Unserialize: 1308ms Size: 50Serialize: 2638ms Unserialize: 14360ms Size: 100 Serialize: 6319ms Unserialize: 72744ms Patched PHP: Size: 10Serialize: 500msUnserialize: 357ms Size: 20Serialize: 870msUnserialize: 703ms Size: 50Serialize: 2212ms Unserialize: 1315ms Size: 100 Serialize: 4898ms Unserialize: 2823ms [2010-09-14 02:58:37] cataphr...@php.net > In my tests doing so reduced the unserialize time from 7 secs to ~0.3 sec on 100-size array and size dependency apparently changed to something more like O(n*log(n)) Could you submit a patch with that modification and a test script that exemplifies the speedup? [2010-09-14 02:46:32] galaxy dot mipt at gmail dot com Description: Performance of built-in unserializer degrades at unexpectedly high rate with the increase of unserialized data size (rather, with number of serialized items). Say, unserializing a plain array of ~100 integers might take somewhat 10 secs on average P4 machine, and the worst part is that the time raises quadratically (O(n^2)) with the array size, i.e. ~200-ish array would take 40 secs or so. The main performance killer is var_hash linked list where every extracted variable is pushed. It is looked up sequentally from the very beginning up to, in fact, the very end during every push operation (var_push() in ext/standard/var_unserializer.c). It appears that looking from the end (or just storing last used element elsewhere) would save a lot of cycles. In my tests doing so reduced the unserialize time from 7 secs to ~0.3 sec on 100-size array and size dependency apparently changed to something more like O(n*log(n)) -- Edit this bug report at http://bugs.php.net/bug.php?id=52832&edit=1
Bug #52843 [Opn->Csd]: Segfault when optional parameters are not passed in to mssql_connect
Edit report at http://bugs.php.net/bug.php?id=52843&edit=1
ID: 52843
Updated by: fel...@php.net
Reported by:clint at ubuntu dot com
Summary:Segfault when optional parameters are not passed in
to mssql_connect
-Status: Open
+Status: Closed
Type: Bug
Package:MSSQL related
Operating System: Linux
PHP Version:5.3.3
-Assigned To:
+Assigned To:Felipe
Block user comment: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
I've committed a slighty modified patch into 5.3 branch and trunk.
Thanks for the patch!
Previous Comments:
[2010-09-15 04:12:48] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=303375
Log: - Fixed bug #52843 (Segfault when optional parameters are not
passed in to mssql_connect)
[2010-09-14 22:56:33] clint at ubuntu dot com
Description:
This was originally reported in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/611316
Calling mssql_connect() without all of its string arguments will cause
php to
segfault.
This happens on Ubuntu 10.10 beta, and Ubuntu 10.04. I also compiled php
5.3.3
vanilla with ./configure --with-mssql=/usr, and the script below caused
the
segfault.
The error is in this code around line 575 of ext/mssql/php_mssql.c:
char *host = NULL, *user = NULL, *passwd = NULL;
int host_len, user_len, passwd_len;
zend_bool new_link = 0;
char *hashed_details;
int hashed_details_length;
mssql_link mssql, *mssql_ptr;
char buffer[40];
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|sssb",
&host,
&host_len, &user, &user_len, &passwd, &passwd_len, &new_link) ==
FAILURE) {
return;
}
/* Limit strings to 255 chars to prevent overflow issues in
underlying
libraries */
if(host_len>255) {
host[255] = '\0';
}
if(user_len>255) {
user[255] = '\0';
}
if(passwd_len>255) {
passwd[255] = '\0';
}
If the optional args are not passed in, the len and host parameters will
be
unchanged, and so a null pointer dereference may occur (depending on the
arbitrary value of the _len variables).
Test script:
---
php -r 'mssql_connect();'
Expected result:
I would expect the program to exit without crashing.
Actual result:
--
ubu...@domu-12-31-39-03-0d-c3:~/src/php5-5.3.3$ gdb php
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
[PHP-BUG] Bug #52848 [NEW]: Processing out-of-band data doesn't work
From: Operating system: Ubuntu 10.04 Lucid Lynx PHP version: 5.3.3 Package: Streams related Bug Type: Bug Bug description:Processing out-of-band data doesn't work Description: I'm not sure what's going wrong (stream_socket_sendto() or stream_socket_recvfrom()) but proccessing out-of-band data doesn't work correctly. Only the last byte is send as out-of-band data, all other data is send as usally. Test script: --- Server: Client: Expected result: OOB-Data 1/2: '123456789' OOB-Data 2/2: '' Data 1/2: '' Data 2/2: '' Actual result: -- OOB-Data 1/2: '9' OOB-Data 2/2: '' Data 1/2: '12345678' Data 2/2: '' -- Edit bug report at http://bugs.php.net/bug.php?id=52848&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52848&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52848&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52848&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52848&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52848&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52848&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52848&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52848&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52848&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52848&r=support Expected behavior: http://bugs.php.net/fix.php?id=52848&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52848&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52848&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52848&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52848&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52848&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52848&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52848&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52848&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52848&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52848&r=mysqlcfg
Bug #52847 [Opn]: Files to include are always searched for in current directory
Edit report at http://bugs.php.net/bug.php?id=52847&edit=1
ID: 52847
User updated by:mail_ben_schmidt at yahoo dot com dot au
Reported by:mail_ben_schmidt at yahoo dot com dot au
Summary:Files to include are always searched for in current
directory
Status: Open
Type: Bug
-Package:Documentation problem
+Package:Scripting Engine problem
-Operating System:
+Operating System: Mac OS X 10.6.2
-PHP Version:Irrelevant
+PHP Version:5.3.2
Block user comment: N
New Comment:
Actually, this may be a behaviour problem, not a documentation problem.
Previous Comments:
[2010-09-15 03:26:04] mail_ben_schmidt at yahoo dot com dot au
Description:
The documentation at include and include_path suggests that the current
directory will not be searched if a '.' is not in include path. Even
though I can see no reason (e.g. in the source code referred to by bug
#51569) that the current directory should be searched, it can be
demonstrated that it is.
See also bug #51569 and bug #52845 for further include_path
documentation deficiencies.
Test script:
---
1. Place in a file 'test/test.php':
set_include_path('/bin'); // won't find any php files here!
include('another.php');
2. touch another.php
3. php test/test.php
Expected result:
Warning that another.php cannot be found.
Actual result:
--
No warning.
N.B. In line with the undocumented feature mentioned in bug #51569, if
another.php is moved to test/another.php, it is still found also,
because it is in the directory of the running script.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52847&edit=1
Bug #50394 [Csd]: Reference argument converted to value in __call
Edit report at http://bugs.php.net/bug.php?id=50394&edit=1
ID: 50394
User updated by:tstarling at wikimedia dot org
Reported by:tstarling at wikimedia dot org
Summary:Reference argument converted to value in __call
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.1
Assigned To:pajoye
Block user comment: N
New Comment:
Commenters please note: you're receiving an error "parameter expected to
be a reference, value given", that does not mean that you are seeing
this bug. In fact, if you're using PHP 5.3.2 or later, it is pretty much
impossible for it to be this bug.
Most cases of "parameter expected to be a reference, value given" are
due to bugs in the user code, not due to any problem with PHP. The
message indicates a mismatch between the reference/value status of
arguments to call_user_func_array() and the function declaration, as
in:
function foo( &$x ) {}
$x = '';
call_user_func_array( 'foo', array( $x ) );
The correct way to call the function foo() in this case is:
call_user_func_array( 'foo', array( &$x ) );
That is to say, the reference must be explicit in the array on the
calling side.
Previous Comments:
[2010-09-15 01:16:45] jeremy at tuxmachine dot com
See bug 51174.
[2010-09-04 01:16:50] david at tuxteam dot com
This seems to be an issue for Drupal modules as well. This is a
significant problem for running Drupal on PHP 5.3.
[2010-08-10 09:14:45] parktrip at gmail dot com
I have the same problem with mediawiki 1.15.5 and PHP 5.3.2 (lastest
version from Zend Server)
So is this a MW problem or PHP ?
[2010-07-23 01:09:33] heis dot turtlemad at gmail dot com
> Mediawiki is wrong in their comments.
Not quite true.
> There is a regression which was fixed in 5.3.2,
> so upgrade to 5.3.2 is the right way to do it.
Upgrading to 5.3.2 doesn't solve the issue, running the following
softwares:
FreeBSD 8/Nginx/MediaWiki 1.15.4
Any call to a Mediawiki extension fails on the following error:
Downgrading to 5.2 is actually the only way to get rid of this.
[2010-06-06 19:04:27] paj...@php.net
Mediawiki is wrong in their comments. There is a regression which was
fixed in 5.3.2, so upgrade to 5.3.2 is the right way to do it.
No need of further comments tho', the issue is fixed.
Thanks for your feedbacks.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=50394
--
Edit this bug report at http://bugs.php.net/bug.php?id=50394&edit=1
Bug #23902 [Com]: header("HTTP/1.0 401 Authorization Required"); failed
Edit report at http://bugs.php.net/bug.php?id=23902&edit=1
ID: 23902
Comment by: enzinho_vrb at hotmail dot com
Reported by:noxter at web dot de
Summary:header("HTTP/1.0 401 Authorization Required");
failed
Status: Closed
Type: Bug
Package:CGI related
Operating System: Windows 2000
PHP Version:4.3.2
Assigned To:edink
Block user comment: N
New Comment:
sasa
Previous Comments:
[2010-08-27 22:48:11] mmoohh00 at yahoo dot com
i wanna make apassword for my wireless lan
[2010-04-20 08:55:20] taverna_ambelos at windowslive dot com
i forget my adress for ip
[2010-04-20 08:49:08] dim_logaras at windowslive dot com
i forgot my username for ip addres
[2003-06-05 04:05:14] jan at kneschke dot de
Doesn't IIS parse CGI headers ?
If it does:
CGI-script are not allowed to send HTTP-response headers at
all. If a CGI script wants to pass a status-code to the Server by
stetting the Status-header.
http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html
Section 7.2
removing the HTTP-response header is a good thing for
Parser-Header environments.
[2003-06-04 18:17:10] ptchristendom at yahoo dot com
On windows 2003, PHP 4.3.2, any location header at all causes this. You
can also verify it from the command line:
script.php contains this line only:
http://localhost.com/page.html'); ?>
Output:
d:\php-4.3.2\php script.php
(null)
Content-type: text/html; charset=iso-8859-1
X-Powered-By: PHP/4.3.2
Location: http://localhost.com/page.html
Setting cgi.rfc2616_headers = 0 is a workaround for this, at least until
the bug is fixed.
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=23902
--
Edit this bug report at http://bugs.php.net/bug.php?id=23902&edit=1
Bug #50394 [Com]: Reference argument converted to value in __call
Edit report at http://bugs.php.net/bug.php?id=50394&edit=1
ID: 50394
Comment by: jeremy at tuxmachine dot com
Reported by:tstarling at wikimedia dot org
Summary:Reference argument converted to value in __call
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.1
Assigned To:pajoye
Block user comment: N
New Comment:
See bug 51174.
Previous Comments:
[2010-09-04 01:16:50] david at tuxteam dot com
This seems to be an issue for Drupal modules as well. This is a
significant problem for running Drupal on PHP 5.3.
[2010-08-10 09:14:45] parktrip at gmail dot com
I have the same problem with mediawiki 1.15.5 and PHP 5.3.2 (lastest
version from Zend Server)
So is this a MW problem or PHP ?
[2010-07-23 01:09:33] heis dot turtlemad at gmail dot com
> Mediawiki is wrong in their comments.
Not quite true.
> There is a regression which was fixed in 5.3.2,
> so upgrade to 5.3.2 is the right way to do it.
Upgrading to 5.3.2 doesn't solve the issue, running the following
softwares:
FreeBSD 8/Nginx/MediaWiki 1.15.4
Any call to a Mediawiki extension fails on the following error:
Downgrading to 5.2 is actually the only way to get rid of this.
[2010-06-06 19:04:27] paj...@php.net
Mediawiki is wrong in their comments. There is a regression which was
fixed in 5.3.2, so upgrade to 5.3.2 is the right way to do it.
No need of further comments tho', the issue is fixed.
Thanks for your feedbacks.
[2010-06-06 18:55:37] PandoraBox2007 at gmail dot com
install-utils.inc
set comments
/*
$test = new PhpRefCallBugTester;
$test->execute();
if ( !$test->ok ) {
echo "PHP 5.3.1 is not compatible with MediaWiki due to a bug
involving\n" .
"reference parameters to __call. Upgrade to PHP 5.3.2
or higher, or
\n" .
"downgrade to PHP 5.3.0 to fix this.\n" .
"ABORTING (see http://bugs.php.net/bug.php?id=50394 for
details)\n";
die( -1 );
}
*/
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=50394
--
Edit this bug report at http://bugs.php.net/bug.php?id=50394&edit=1
Bug #51174 [Com]: error "expected to be a reference" when $this referenced in an array property
Edit report at http://bugs.php.net/bug.php?id=51174&edit=1
ID: 51174
Comment by: jeremy at tuxmachine dot com
Reported by:skrol29forum at gmail dot com
Summary:error "expected to be a reference" when $this
referenced in an array property
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Win7
PHP Version:5.3
Block user comment: N
New Comment:
See also bug 50394.
Previous Comments:
[2010-07-23 01:43:42] heis dot turtlemad at gmail dot com
Same failure running Php5.3.2 on FreeBSD8
david:~>php test.php
arg_array[0] is the
same instance than $this
prop=1
arg_array[0] is the
same instance than $this
Warning: Parameter 1 to f_test() expected to be a reference, value given
in /usr/home/david/test.php on line 15
[2010-06-21 00:03:55] fel...@php.net
I can reproduce it.
array(1) {
[0]=>
&object(clsTest)#1 (2) {
["prop"]=>
int(0)
["arg_array"]=>
*RECURSION*
}
}
prop=1
array(1) {
[0]=>
object(clsTest)#1 (2) {
["prop"]=>
int(1)
["arg_array"]=>
*RECURSION*
}
}
PHP Warning: Parameter 1 to f_test() expected to be a reference, value
given
[2010-03-01 08:24:57] skrol29forum at gmail dot com
I've inverted "Expected result" and "Actual result".
[2010-03-01 00:08:16] skrol29forum at gmail dot com
Description:
When $this is stored by reference in a PHP array, itself stored in a
property, then function call_user_func_array() is able to recognize the
reference only if called in the same local context where $this is
referenced. In other words, the reference seems to be lost for
call_user_func_array().
The bug does not occur with PHP 5.2,
It does occur with both PHP 5.3.0 and PHP 5.3.1. Not yet tested with PHP
5.3.2
Note that if we use a global variable instead of a property, then the
bug does not occur.
Reproduce code:
---
prop++;
echo "prop=".$obj->prop." \r\n";
}
class clsTest {
public $prop = 0;
public $arg_array = false;
function meth() {
if ($this->arg_array===false) $this->arg_array = array(&$this);
echo 'arg_array[0] '.(($this->arg_array[0]===$this) ? ' is the
same
instance' : ' is not the same instance').' than $this'." \r\n";
call_user_func_array('f_test', $this->arg_array);
}
}
$oTest = new clsTest;
$oTest->meth(); // OK
$oTest->meth(); // ERR
?>
Expected result:
arg_array[0] is the same instance than $this
prop=1
arg_array[0] is the same instance than $this
Warning: Parameter 1 to f_test() expected to be a reference, value given
in D:\www\bug.php on line 14
Actual result:
--
arg_array[0] is the same instance than $this
prop=1
arg_array[0] is the same instance than $this
prop=2
--
Edit this bug report at http://bugs.php.net/bug.php?id=51174&edit=1
Bug #52841 [Fbk->Asn]: php crash on phpinfo(); using php_enchant
Edit report at http://bugs.php.net/bug.php?id=52841&edit=1 ID: 52841 Updated by: paj...@php.net Reported by:raulsalitrero at gmail dot com Summary:php crash on phpinfo(); using php_enchant -Status: Feedback +Status: Assigned Type: Bug Package:Reproducible crash Operating System: Windows XP PHP Version:5.3SVN-2010-09-14 (SVN) -Assigned To: +Assigned To:pajoye Block user comment: N Previous Comments: [2010-09-14 22:44:03] paj...@php.net It was attempting to load DLLs that were not enchant backends. [2010-09-14 21:31:35] raulsalitrero at gmail dot com yes, its working now with that version of enchant. both CLI and WEB... what caused the problem? [2010-09-14 21:24:00] paj...@php.net Sorry :) http://windows.php.net/downloads/qa/test/libenchant_52841.zip Also please try using the CLI as well. [2010-09-14 21:11:23] raulsalitrero at gmail dot com sorry. but. where can i download libenchant_52841.zip? [2010-09-14 19:39:52] paj...@php.net Can you replace the libenchant.dll with libenchant_52841.zip, restart apache and try again please? 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=52841 -- Edit this bug report at http://bugs.php.net/bug.php?id=52841&edit=1
[PHP-BUG] Bug #52843 [NEW]: Segfault when optional parameters are not passed in to mssql_connect
From:
Operating system: Linux
PHP version: 5.3.3
Package: MSSQL related
Bug Type: Bug
Bug description:Segfault when optional parameters are not passed in to
mssql_connect
Description:
This was originally reported in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/611316
Calling mssql_connect() without all of its string arguments will cause php
to
segfault.
This happens on Ubuntu 10.10 beta, and Ubuntu 10.04. I also compiled php
5.3.3
vanilla with ./configure --with-mssql=/usr, and the script below caused the
segfault.
The error is in this code around line 575 of ext/mssql/php_mssql.c:
char *host = NULL, *user = NULL, *passwd = NULL;
int host_len, user_len, passwd_len;
zend_bool new_link = 0;
char *hashed_details;
int hashed_details_length;
mssql_link mssql, *mssql_ptr;
char buffer[40];
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|sssb",
&host,
&host_len, &user, &user_len, &passwd, &passwd_len, &new_link) == FAILURE)
{
return;
}
/* Limit strings to 255 chars to prevent overflow issues in
underlying
libraries */
if(host_len>255) {
host[255] = '\0';
}
if(user_len>255) {
user[255] = '\0';
}
if(passwd_len>255) {
passwd[255] = '\0';
}
If the optional args are not passed in, the len and host parameters will be
unchanged, and so a null pointer dereference may occur (depending on the
arbitrary value of the _len variables).
Test script:
---
php -r 'mssql_connect();'
Expected result:
I would expect the program to exit without crashing.
Actual result:
--
ubu...@domu-12-31-39-03-0d-c3:~/src/php5-5.3.3$ gdb php
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
Bug #52841 [Fbk]: php crash on phpinfo(); using php_enchant
Edit report at http://bugs.php.net/bug.php?id=52841&edit=1 ID: 52841 Updated by: paj...@php.net Reported by:raulsalitrero at gmail dot com Summary:php crash on phpinfo(); using php_enchant Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows XP PHP Version:5.3SVN-2010-09-14 (SVN) Block user comment: N New Comment: It was attempting to load DLLs that were not enchant backends. Previous Comments: [2010-09-14 21:31:35] raulsalitrero at gmail dot com yes, its working now with that version of enchant. both CLI and WEB... what caused the problem? [2010-09-14 21:24:00] paj...@php.net Sorry :) http://windows.php.net/downloads/qa/test/libenchant_52841.zip Also please try using the CLI as well. [2010-09-14 21:11:23] raulsalitrero at gmail dot com sorry. but. where can i download libenchant_52841.zip? [2010-09-14 19:39:52] paj...@php.net Can you replace the libenchant.dll with libenchant_52841.zip, restart apache and try again please? [2010-09-14 19:00:17] ahar...@php.net It is too. Sorry about that. I'll file a doc bug to remind myself to change the manual, then, because the manual still lists it as a PECL extension. 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=52841 -- Edit this bug report at http://bugs.php.net/bug.php?id=52841&edit=1
Bug #52841 [Com]: php crash on phpinfo(); using php_enchant
Edit report at http://bugs.php.net/bug.php?id=52841&edit=1 ID: 52841 Comment by: raulsalitrero at gmail dot com Reported by:raulsalitrero at gmail dot com Summary:php crash on phpinfo(); using php_enchant Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows XP PHP Version:5.3SVN-2010-09-14 (SVN) Block user comment: N New Comment: yes, its working now with that version of enchant. both CLI and WEB... what caused the problem? Previous Comments: [2010-09-14 21:24:00] paj...@php.net Sorry :) http://windows.php.net/downloads/qa/test/libenchant_52841.zip Also please try using the CLI as well. [2010-09-14 21:11:23] raulsalitrero at gmail dot com sorry. but. where can i download libenchant_52841.zip? [2010-09-14 19:39:52] paj...@php.net Can you replace the libenchant.dll with libenchant_52841.zip, restart apache and try again please? [2010-09-14 19:00:17] ahar...@php.net It is too. Sorry about that. I'll file a doc bug to remind myself to change the manual, then, because the manual still lists it as a PECL extension. [2010-09-14 18:56:54] paj...@php.net it is part of php 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=52841 -- Edit this bug report at http://bugs.php.net/bug.php?id=52841&edit=1
Bug #52841 [Fbk]: php crash on phpinfo(); using php_enchant
Edit report at http://bugs.php.net/bug.php?id=52841&edit=1 ID: 52841 Updated by: paj...@php.net Reported by:raulsalitrero at gmail dot com Summary:php crash on phpinfo(); using php_enchant Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows XP PHP Version:5.3SVN-2010-09-14 (SVN) Block user comment: N New Comment: Sorry :) http://windows.php.net/downloads/qa/test/libenchant_52841.zip Also please try using the CLI as well. Previous Comments: [2010-09-14 21:11:23] raulsalitrero at gmail dot com sorry. but. where can i download libenchant_52841.zip? [2010-09-14 19:39:52] paj...@php.net Can you replace the libenchant.dll with libenchant_52841.zip, restart apache and try again please? [2010-09-14 19:00:17] ahar...@php.net It is too. Sorry about that. I'll file a doc bug to remind myself to change the manual, then, because the manual still lists it as a PECL extension. [2010-09-14 18:56:54] paj...@php.net it is part of php [2010-09-14 18:48:59] ahar...@php.net Bugs for PECL packages should be reported on the PECL bug tracker. Please report it using the "report new bug" link at http://pecl.php.net/package/enchant. 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=52841 -- Edit this bug report at http://bugs.php.net/bug.php?id=52841&edit=1
Bug #52841 [Com]: php crash on phpinfo(); using php_enchant
Edit report at http://bugs.php.net/bug.php?id=52841&edit=1 ID: 52841 Comment by: raulsalitrero at gmail dot com Reported by:raulsalitrero at gmail dot com Summary:php crash on phpinfo(); using php_enchant Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows XP PHP Version:5.3SVN-2010-09-14 (SVN) Block user comment: N New Comment: sorry. but. where can i download libenchant_52841.zip? Previous Comments: [2010-09-14 19:39:52] paj...@php.net Can you replace the libenchant.dll with libenchant_52841.zip, restart apache and try again please? [2010-09-14 19:00:17] ahar...@php.net It is too. Sorry about that. I'll file a doc bug to remind myself to change the manual, then, because the manual still lists it as a PECL extension. [2010-09-14 18:56:54] paj...@php.net it is part of php [2010-09-14 18:48:59] ahar...@php.net Bugs for PECL packages should be reported on the PECL bug tracker. Please report it using the "report new bug" link at http://pecl.php.net/package/enchant. [2010-09-14 18:37:02] raulsalitrero at gmail dot com the exception i get is: 0xC005: Infracción de acceso al leer la ubicación 0x00030005. (Read Access Infracion. Address:0x00030005) 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=52841 -- Edit this bug report at http://bugs.php.net/bug.php?id=52841&edit=1
Bug #52841 [Opn->Fbk]: php crash on phpinfo(); using php_enchant
Edit report at http://bugs.php.net/bug.php?id=52841&edit=1 ID: 52841 Updated by: paj...@php.net Reported by:raulsalitrero at gmail dot com Summary:php crash on phpinfo(); using php_enchant -Status: Open +Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows XP PHP Version:5.3SVN-2010-09-14 (SVN) Block user comment: N New Comment: Can you replace the libenchant.dll with libenchant_52841.zip, restart apache and try again please? Previous Comments: [2010-09-14 19:00:17] ahar...@php.net It is too. Sorry about that. I'll file a doc bug to remind myself to change the manual, then, because the manual still lists it as a PECL extension. [2010-09-14 18:56:54] paj...@php.net it is part of php [2010-09-14 18:48:59] ahar...@php.net Bugs for PECL packages should be reported on the PECL bug tracker. Please report it using the "report new bug" link at http://pecl.php.net/package/enchant. [2010-09-14 18:37:02] raulsalitrero at gmail dot com the exception i get is: 0xC005: Infracción de acceso al leer la ubicación 0x00030005. (Read Access Infracion. Address:0x00030005) [2010-09-14 18:35:03] raulsalitrero at gmail dot com Description: php svn crashes when calling phpinfo() and having php_enchant loaded. apparently an uninitialñized pointer is passed around while invoking php_info_print_table_start(); the problem occurs only using php_enchant, any other extension, i havent seen this crash on any other extension, in fact im using php.ini-production modified only to load php_enchant and no other extension. i am using the lates sources from php 5.3 branch in svn. this bug started to happen recently, code from about one or two weeks ago doesn't crash. the following stack trace was obtained using vc2008 Test script: --- Expected result: phpinfo page shown. Actual result: -- php5ts.dll!_erealloc(void * ptr=0x, unsigned int size=79, int allow_failure=0) LÃnea 2359 + 0x4 bytes C php5ts.dll!xbuf_format_converter(smart_str * xbuf=0x037cf93c, const char * fmt=0x, char * ap=0x) LÃnea 234 + 0x3f bytes C php5ts.dll!vspprintf(char * * pbuf=0x037cf968, unsigned int max_len=0, const char * format=0x022c6fe8, char * ap=0x037cf974) LÃnea 799 C php5ts.dll!php_printf(const char * format=0x022c6fe8, ...) LÃnea 626 C php5ts.dll!php_info_print_table_start() LÃnea 1040 + 0xa bytes C php_enchant.dll!zm_info_enchant(_zend_module_entry * zend_module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 323 C php5ts.dll!php_info_print_module(_zend_module_entry * zend_module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 103 + 0x8 bytes C php5ts.dll!_display_module_info_func(_zend_module_entry * module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 123 + 0xb bytes C php5ts.dll!zend_hash_apply(_hashtable * ht=0x037cfa38, int (void *, void * * *)* apply_func=0x020b5fc0, void * * * tsrm_ls=0x025433f0) LÃnea 676 + 0x9 bytes C php5ts.dll!php_print_info(int flag=-1, void * * * tsrm_ls=0x025433f0) LÃnea 939 + 0x10 bytes C php5ts.dll!zif_phpinfo(int ht=0, _zval_struct * return_value=0x0389dfc8, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x, int return_value_used=0, void * * * tsrm_ls=0x025433f0) LÃnea 1254C php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data=0x038d0080, void * * * tsrm_ls=0x02543300) LÃnea 316 + 0x41 bytes C php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data=0x, void * * * tsrm_ls=0x) LÃnea 1606 + 0xe bytes C php5ts.dll!execute(_zend_op_array * op_array=0x0389db10, void * * * tsrm_ls=0x02543300) LÃnea 107 + 0xa bytes C php5ts.dll!zend_execute_scripts(int type=8, void * * * tsrm_ls=0x025433f0, _zval_struct * * retval=0x, int file_count=3, ...) LÃnea 1195 C php5ts.dll!php_execute_script(_zend_file_handle * primary_file=0x037cfe5c, void * * * tsrm_ls=0x025433f0) LÃnea 2260 + 0x12 bytes C php5apache2_2.dll!php_handler(request_rec * r=0x025d34e8) LÃnea 669 + 0xe bytes C libhttpd.dll!ap_run_handler(request_rec * r=0x025d34e8) LÃnea 158 + 0x28 bytes C libhttpd.dll!ap_invoke_handler(request_rec * r=0x01596640) LÃnea 376 + 0x6 bytes C
Bug #52841 [Opn]: php crash on phpinfo(); using php_enchant
Edit report at http://bugs.php.net/bug.php?id=52841&edit=1 ID: 52841 Updated by: ahar...@php.net Reported by:raulsalitrero at gmail dot com Summary:php crash on phpinfo(); using php_enchant Status: Open Type: Bug Package:Reproducible crash Operating System: Windows XP PHP Version:5.3SVN-2010-09-14 (SVN) Block user comment: N New Comment: It is too. Sorry about that. I'll file a doc bug to remind myself to change the manual, then, because the manual still lists it as a PECL extension. Previous Comments: [2010-09-14 18:56:54] paj...@php.net it is part of php [2010-09-14 18:48:59] ahar...@php.net Bugs for PECL packages should be reported on the PECL bug tracker. Please report it using the "report new bug" link at http://pecl.php.net/package/enchant. [2010-09-14 18:37:02] raulsalitrero at gmail dot com the exception i get is: 0xC005: Infracción de acceso al leer la ubicación 0x00030005. (Read Access Infracion. Address:0x00030005) [2010-09-14 18:35:03] raulsalitrero at gmail dot com Description: php svn crashes when calling phpinfo() and having php_enchant loaded. apparently an uninitialñized pointer is passed around while invoking php_info_print_table_start(); the problem occurs only using php_enchant, any other extension, i havent seen this crash on any other extension, in fact im using php.ini-production modified only to load php_enchant and no other extension. i am using the lates sources from php 5.3 branch in svn. this bug started to happen recently, code from about one or two weeks ago doesn't crash. the following stack trace was obtained using vc2008 Test script: --- Expected result: phpinfo page shown. Actual result: -- php5ts.dll!_erealloc(void * ptr=0x, unsigned int size=79, int allow_failure=0) LÃnea 2359 + 0x4 bytes C php5ts.dll!xbuf_format_converter(smart_str * xbuf=0x037cf93c, const char * fmt=0x, char * ap=0x) LÃnea 234 + 0x3f bytes C php5ts.dll!vspprintf(char * * pbuf=0x037cf968, unsigned int max_len=0, const char * format=0x022c6fe8, char * ap=0x037cf974) LÃnea 799 C php5ts.dll!php_printf(const char * format=0x022c6fe8, ...) LÃnea 626 C php5ts.dll!php_info_print_table_start() LÃnea 1040 + 0xa bytes C php_enchant.dll!zm_info_enchant(_zend_module_entry * zend_module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 323 C php5ts.dll!php_info_print_module(_zend_module_entry * zend_module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 103 + 0x8 bytes C php5ts.dll!_display_module_info_func(_zend_module_entry * module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 123 + 0xb bytes C php5ts.dll!zend_hash_apply(_hashtable * ht=0x037cfa38, int (void *, void * * *)* apply_func=0x020b5fc0, void * * * tsrm_ls=0x025433f0) LÃnea 676 + 0x9 bytes C php5ts.dll!php_print_info(int flag=-1, void * * * tsrm_ls=0x025433f0) LÃnea 939 + 0x10 bytes C php5ts.dll!zif_phpinfo(int ht=0, _zval_struct * return_value=0x0389dfc8, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x, int return_value_used=0, void * * * tsrm_ls=0x025433f0) LÃnea 1254C php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data=0x038d0080, void * * * tsrm_ls=0x02543300) LÃnea 316 + 0x41 bytes C php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data=0x, void * * * tsrm_ls=0x) LÃnea 1606 + 0xe bytes C php5ts.dll!execute(_zend_op_array * op_array=0x0389db10, void * * * tsrm_ls=0x02543300) LÃnea 107 + 0xa bytes C php5ts.dll!zend_execute_scripts(int type=8, void * * * tsrm_ls=0x025433f0, _zval_struct * * retval=0x, int file_count=3, ...) LÃnea 1195 C php5ts.dll!php_execute_script(_zend_file_handle * primary_file=0x037cfe5c, void * * * tsrm_ls=0x025433f0) LÃnea 2260 + 0x12 bytes C php5apache2_2.dll!php_handler(request_rec * r=0x025d34e8) LÃnea 669 + 0xe bytes C libhttpd.dll!ap_run_handler(request_rec * r=0x025d34e8) LÃnea 158 + 0x28 bytes C libhttpd.dll!ap_invoke_handler(request_rec * r=0x01596640) LÃnea 376 + 0x6 bytes C libhttpd.dll!ap_process_request(request_rec * r=0x025d34e8) LÃnea 286 C libhttpd.dll!ap_process_http_connection(conn_rec * c=0x025ce488) LÃnea 190 + 0x6 bytes C libhttpd.dll!ap_run_process_connection(conn_
Bug #52841 [Bgs->Opn]: php crash on phpinfo(); using php_enchant
Edit report at http://bugs.php.net/bug.php?id=52841&edit=1 ID: 52841 Updated by: paj...@php.net Reported by:raulsalitrero at gmail dot com Summary:php crash on phpinfo(); using php_enchant -Status: Bogus +Status: Open Type: Bug Package:Reproducible crash Operating System: Windows XP PHP Version:5.3SVN-2010-09-14 (SVN) Block user comment: N New Comment: it is part of php Previous Comments: [2010-09-14 18:48:59] ahar...@php.net Bugs for PECL packages should be reported on the PECL bug tracker. Please report it using the "report new bug" link at http://pecl.php.net/package/enchant. [2010-09-14 18:37:02] raulsalitrero at gmail dot com the exception i get is: 0xC005: Infracción de acceso al leer la ubicación 0x00030005. (Read Access Infracion. Address:0x00030005) [2010-09-14 18:35:03] raulsalitrero at gmail dot com Description: php svn crashes when calling phpinfo() and having php_enchant loaded. apparently an uninitialñized pointer is passed around while invoking php_info_print_table_start(); the problem occurs only using php_enchant, any other extension, i havent seen this crash on any other extension, in fact im using php.ini-production modified only to load php_enchant and no other extension. i am using the lates sources from php 5.3 branch in svn. this bug started to happen recently, code from about one or two weeks ago doesn't crash. the following stack trace was obtained using vc2008 Test script: --- Expected result: phpinfo page shown. Actual result: -- php5ts.dll!_erealloc(void * ptr=0x, unsigned int size=79, int allow_failure=0) LÃnea 2359 + 0x4 bytes C php5ts.dll!xbuf_format_converter(smart_str * xbuf=0x037cf93c, const char * fmt=0x, char * ap=0x) LÃnea 234 + 0x3f bytes C php5ts.dll!vspprintf(char * * pbuf=0x037cf968, unsigned int max_len=0, const char * format=0x022c6fe8, char * ap=0x037cf974) LÃnea 799 C php5ts.dll!php_printf(const char * format=0x022c6fe8, ...) LÃnea 626 C php5ts.dll!php_info_print_table_start() LÃnea 1040 + 0xa bytes C php_enchant.dll!zm_info_enchant(_zend_module_entry * zend_module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 323 C php5ts.dll!php_info_print_module(_zend_module_entry * zend_module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 103 + 0x8 bytes C php5ts.dll!_display_module_info_func(_zend_module_entry * module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 123 + 0xb bytes C php5ts.dll!zend_hash_apply(_hashtable * ht=0x037cfa38, int (void *, void * * *)* apply_func=0x020b5fc0, void * * * tsrm_ls=0x025433f0) LÃnea 676 + 0x9 bytes C php5ts.dll!php_print_info(int flag=-1, void * * * tsrm_ls=0x025433f0) LÃnea 939 + 0x10 bytes C php5ts.dll!zif_phpinfo(int ht=0, _zval_struct * return_value=0x0389dfc8, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x, int return_value_used=0, void * * * tsrm_ls=0x025433f0) LÃnea 1254C php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data=0x038d0080, void * * * tsrm_ls=0x02543300) LÃnea 316 + 0x41 bytes C php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data=0x, void * * * tsrm_ls=0x) LÃnea 1606 + 0xe bytes C php5ts.dll!execute(_zend_op_array * op_array=0x0389db10, void * * * tsrm_ls=0x02543300) LÃnea 107 + 0xa bytes C php5ts.dll!zend_execute_scripts(int type=8, void * * * tsrm_ls=0x025433f0, _zval_struct * * retval=0x, int file_count=3, ...) LÃnea 1195 C php5ts.dll!php_execute_script(_zend_file_handle * primary_file=0x037cfe5c, void * * * tsrm_ls=0x025433f0) LÃnea 2260 + 0x12 bytes C php5apache2_2.dll!php_handler(request_rec * r=0x025d34e8) LÃnea 669 + 0xe bytes C libhttpd.dll!ap_run_handler(request_rec * r=0x025d34e8) LÃnea 158 + 0x28 bytes C libhttpd.dll!ap_invoke_handler(request_rec * r=0x01596640) LÃnea 376 + 0x6 bytes C libhttpd.dll!ap_process_request(request_rec * r=0x025d34e8) LÃnea 286 C libhttpd.dll!ap_process_http_connection(conn_rec * c=0x025ce488) LÃnea 190 + 0x6 bytes C libhttpd.dll!ap_run_process_connection(conn_rec * c=0x025ce488) LÃnea 43 + 0x28 bytes C libhttpd.dll!ap_process_connection(conn_rec * c=0x025ce488, void * csd=0x025c7460) LÃnea 178 + 0x6 bytes C libhttpd.dll!worker_main(void * thread_num_val=0x025ce480) L
Bug #52841 [Opn->Bgs]: php crash on phpinfo(); using php_enchant
Edit report at http://bugs.php.net/bug.php?id=52841&edit=1 ID: 52841 Updated by: ahar...@php.net Reported by:raulsalitrero at gmail dot com Summary:php crash on phpinfo(); using php_enchant -Status: Open +Status: Bogus Type: Bug Package:Reproducible crash Operating System: Windows XP PHP Version:5.3SVN-2010-09-14 (SVN) Block user comment: N New Comment: Bugs for PECL packages should be reported on the PECL bug tracker. Please report it using the "report new bug" link at http://pecl.php.net/package/enchant. Previous Comments: [2010-09-14 18:37:02] raulsalitrero at gmail dot com the exception i get is: 0xC005: Infracción de acceso al leer la ubicación 0x00030005. (Read Access Infracion. Address:0x00030005) [2010-09-14 18:35:03] raulsalitrero at gmail dot com Description: php svn crashes when calling phpinfo() and having php_enchant loaded. apparently an uninitialñized pointer is passed around while invoking php_info_print_table_start(); the problem occurs only using php_enchant, any other extension, i havent seen this crash on any other extension, in fact im using php.ini-production modified only to load php_enchant and no other extension. i am using the lates sources from php 5.3 branch in svn. this bug started to happen recently, code from about one or two weeks ago doesn't crash. the following stack trace was obtained using vc2008 Test script: --- Expected result: phpinfo page shown. Actual result: -- php5ts.dll!_erealloc(void * ptr=0x, unsigned int size=79, int allow_failure=0) LÃnea 2359 + 0x4 bytes C php5ts.dll!xbuf_format_converter(smart_str * xbuf=0x037cf93c, const char * fmt=0x, char * ap=0x) LÃnea 234 + 0x3f bytes C php5ts.dll!vspprintf(char * * pbuf=0x037cf968, unsigned int max_len=0, const char * format=0x022c6fe8, char * ap=0x037cf974) LÃnea 799 C php5ts.dll!php_printf(const char * format=0x022c6fe8, ...) LÃnea 626 C php5ts.dll!php_info_print_table_start() LÃnea 1040 + 0xa bytes C php_enchant.dll!zm_info_enchant(_zend_module_entry * zend_module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 323 C php5ts.dll!php_info_print_module(_zend_module_entry * zend_module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 103 + 0x8 bytes C php5ts.dll!_display_module_info_func(_zend_module_entry * module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 123 + 0xb bytes C php5ts.dll!zend_hash_apply(_hashtable * ht=0x037cfa38, int (void *, void * * *)* apply_func=0x020b5fc0, void * * * tsrm_ls=0x025433f0) LÃnea 676 + 0x9 bytes C php5ts.dll!php_print_info(int flag=-1, void * * * tsrm_ls=0x025433f0) LÃnea 939 + 0x10 bytes C php5ts.dll!zif_phpinfo(int ht=0, _zval_struct * return_value=0x0389dfc8, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x, int return_value_used=0, void * * * tsrm_ls=0x025433f0) LÃnea 1254C php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data=0x038d0080, void * * * tsrm_ls=0x02543300) LÃnea 316 + 0x41 bytes C php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data=0x, void * * * tsrm_ls=0x) LÃnea 1606 + 0xe bytes C php5ts.dll!execute(_zend_op_array * op_array=0x0389db10, void * * * tsrm_ls=0x02543300) LÃnea 107 + 0xa bytes C php5ts.dll!zend_execute_scripts(int type=8, void * * * tsrm_ls=0x025433f0, _zval_struct * * retval=0x, int file_count=3, ...) LÃnea 1195 C php5ts.dll!php_execute_script(_zend_file_handle * primary_file=0x037cfe5c, void * * * tsrm_ls=0x025433f0) LÃnea 2260 + 0x12 bytes C php5apache2_2.dll!php_handler(request_rec * r=0x025d34e8) LÃnea 669 + 0xe bytes C libhttpd.dll!ap_run_handler(request_rec * r=0x025d34e8) LÃnea 158 + 0x28 bytes C libhttpd.dll!ap_invoke_handler(request_rec * r=0x01596640) LÃnea 376 + 0x6 bytes C libhttpd.dll!ap_process_request(request_rec * r=0x025d34e8) LÃnea 286 C libhttpd.dll!ap_process_http_connection(conn_rec * c=0x025ce488) LÃnea 190 + 0x6 bytes C libhttpd.dll!ap_run_process_connection(conn_rec * c=0x025ce488) LÃnea 43 + 0x28 bytes C libhttpd.dll!ap_process_connection(conn_rec * c=0x025ce488, void * csd=0x025c7460) LÃnea 178 + 0x6 bytes C libhttpd.dll!worker_main(void * thread_num_val=0x025ce480) LÃnea 778 C -- Edit this bug report at http://bugs.
Bug #52841 [Opn]: php crash on phpinfo(); using php_enchant
Edit report at http://bugs.php.net/bug.php?id=52841&edit=1 ID: 52841 User updated by:raulsalitrero at gmail dot com Reported by:raulsalitrero at gmail dot com Summary:php crash on phpinfo(); using php_enchant Status: Open Type: Bug Package:Reproducible crash Operating System: Windows XP PHP Version:5.3SVN-2010-09-14 (SVN) Block user comment: N New Comment: the exception i get is: 0xC005: Infracción de acceso al leer la ubicación 0x00030005. (Read Access Infracion. Address:0x00030005) Previous Comments: [2010-09-14 18:35:03] raulsalitrero at gmail dot com Description: php svn crashes when calling phpinfo() and having php_enchant loaded. apparently an uninitialñized pointer is passed around while invoking php_info_print_table_start(); the problem occurs only using php_enchant, any other extension, i havent seen this crash on any other extension, in fact im using php.ini-production modified only to load php_enchant and no other extension. i am using the lates sources from php 5.3 branch in svn. this bug started to happen recently, code from about one or two weeks ago doesn't crash. the following stack trace was obtained using vc2008 Test script: --- Expected result: phpinfo page shown. Actual result: -- php5ts.dll!_erealloc(void * ptr=0x, unsigned int size=79, int allow_failure=0) LÃnea 2359 + 0x4 bytes C php5ts.dll!xbuf_format_converter(smart_str * xbuf=0x037cf93c, const char * fmt=0x, char * ap=0x) LÃnea 234 + 0x3f bytes C php5ts.dll!vspprintf(char * * pbuf=0x037cf968, unsigned int max_len=0, const char * format=0x022c6fe8, char * ap=0x037cf974) LÃnea 799 C php5ts.dll!php_printf(const char * format=0x022c6fe8, ...) LÃnea 626 C php5ts.dll!php_info_print_table_start() LÃnea 1040 + 0xa bytes C php_enchant.dll!zm_info_enchant(_zend_module_entry * zend_module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 323 C php5ts.dll!php_info_print_module(_zend_module_entry * zend_module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 103 + 0x8 bytes C php5ts.dll!_display_module_info_func(_zend_module_entry * module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 123 + 0xb bytes C php5ts.dll!zend_hash_apply(_hashtable * ht=0x037cfa38, int (void *, void * * *)* apply_func=0x020b5fc0, void * * * tsrm_ls=0x025433f0) LÃnea 676 + 0x9 bytes C php5ts.dll!php_print_info(int flag=-1, void * * * tsrm_ls=0x025433f0) LÃnea 939 + 0x10 bytes C php5ts.dll!zif_phpinfo(int ht=0, _zval_struct * return_value=0x0389dfc8, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x, int return_value_used=0, void * * * tsrm_ls=0x025433f0) LÃnea 1254C php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data=0x038d0080, void * * * tsrm_ls=0x02543300) LÃnea 316 + 0x41 bytes C php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data=0x, void * * * tsrm_ls=0x) LÃnea 1606 + 0xe bytes C php5ts.dll!execute(_zend_op_array * op_array=0x0389db10, void * * * tsrm_ls=0x02543300) LÃnea 107 + 0xa bytes C php5ts.dll!zend_execute_scripts(int type=8, void * * * tsrm_ls=0x025433f0, _zval_struct * * retval=0x, int file_count=3, ...) LÃnea 1195 C php5ts.dll!php_execute_script(_zend_file_handle * primary_file=0x037cfe5c, void * * * tsrm_ls=0x025433f0) LÃnea 2260 + 0x12 bytes C php5apache2_2.dll!php_handler(request_rec * r=0x025d34e8) LÃnea 669 + 0xe bytes C libhttpd.dll!ap_run_handler(request_rec * r=0x025d34e8) LÃnea 158 + 0x28 bytes C libhttpd.dll!ap_invoke_handler(request_rec * r=0x01596640) LÃnea 376 + 0x6 bytes C libhttpd.dll!ap_process_request(request_rec * r=0x025d34e8) LÃnea 286 C libhttpd.dll!ap_process_http_connection(conn_rec * c=0x025ce488) LÃnea 190 + 0x6 bytes C libhttpd.dll!ap_run_process_connection(conn_rec * c=0x025ce488) LÃnea 43 + 0x28 bytes C libhttpd.dll!ap_process_connection(conn_rec * c=0x025ce488, void * csd=0x025c7460) LÃnea 178 + 0x6 bytes C libhttpd.dll!worker_main(void * thread_num_val=0x025ce480) LÃnea 778 C -- Edit this bug report at http://bugs.php.net/bug.php?id=52841&edit=1
Req #52832 [Opn]: unserialize() performance
Edit report at http://bugs.php.net/bug.php?id=52832&edit=1 ID: 52832 User updated by:galaxy dot mipt at gmail dot com Reported by:galaxy dot mipt at gmail dot com Summary:unserialize() performance Status: Open Type: Feature/Change Request Package:Performance problem Operating System: Linux PHP Version:5.3.3 Block user comment: N New Comment: Added a patch against latest SVN version, did things in a way that required least code modification. Here goes the test script: It's a bit memory consuming, so array sizes might need to be reduced depending on available hardware. My test results: Original PHP: Size: 10Serialize: 483msUnserialize: 470ms Size: 20Serialize: 1047ms Unserialize: 1308ms Size: 50Serialize: 2638ms Unserialize: 14360ms Size: 100 Serialize: 6319ms Unserialize: 72744ms Patched PHP: Size: 10Serialize: 500msUnserialize: 357ms Size: 20Serialize: 870msUnserialize: 703ms Size: 50Serialize: 2212ms Unserialize: 1315ms Size: 100 Serialize: 4898ms Unserialize: 2823ms Previous Comments: [2010-09-14 02:58:37] cataphr...@php.net > In my tests doing so reduced the unserialize time from 7 secs to ~0.3 sec on 100-size array and size dependency apparently changed to something more like O(n*log(n)) Could you submit a patch with that modification and a test script that exemplifies the speedup? [2010-09-14 02:46:32] galaxy dot mipt at gmail dot com Description: Performance of built-in unserializer degrades at unexpectedly high rate with the increase of unserialized data size (rather, with number of serialized items). Say, unserializing a plain array of ~100 integers might take somewhat 10 secs on average P4 machine, and the worst part is that the time raises quadratically (O(n^2)) with the array size, i.e. ~200-ish array would take 40 secs or so. The main performance killer is var_hash linked list where every extracted variable is pushed. It is looked up sequentally from the very beginning up to, in fact, the very end during every push operation (var_push() in ext/standard/var_unserializer.c). It appears that looking from the end (or just storing last used element elsewhere) would save a lot of cycles. In my tests doing so reduced the unserialize time from 7 secs to ~0.3 sec on 100-size array and size dependency apparently changed to something more like O(n*log(n)) -- Edit this bug report at http://bugs.php.net/bug.php?id=52832&edit=1
[PHP-BUG] Bug #52841 [NEW]: php crash on phpinfo(); using php_enchant
From: Operating system: Windows XP PHP version: 5.3SVN-2010-09-14 (SVN) Package: Reproducible crash Bug Type: Bug Bug description:php crash on phpinfo(); using php_enchant Description: php svn crashes when calling phpinfo() and having php_enchant loaded. apparently an uninitialñized pointer is passed around while invoking php_info_print_table_start(); the problem occurs only using php_enchant, any other extension, i havent seen this crash on any other extension, in fact im using php.ini-production modified only to load php_enchant and no other extension. i am using the lates sources from php 5.3 branch in svn. this bug started to happen recently, code from about one or two weeks ago doesn't crash. the following stack trace was obtained using vc2008 Test script: --- Expected result: phpinfo page shown. Actual result: -- php5ts.dll!_erealloc(void * ptr=0x, unsigned int size=79, int allow_failure=0) LÃnea 2359 + 0x4 bytes C php5ts.dll!xbuf_format_converter(smart_str * xbuf=0x037cf93c, const char * fmt=0x, char * ap=0x) LÃnea 234 + 0x3f bytesC php5ts.dll!vspprintf(char * * pbuf=0x037cf968, unsigned int max_len=0, const char * format=0x022c6fe8, char * ap=0x037cf974) LÃnea 799 C php5ts.dll!php_printf(const char * format=0x022c6fe8, ...) LÃnea 626 C php5ts.dll!php_info_print_table_start() LÃnea 1040 + 0xa bytes C php_enchant.dll!zm_info_enchant(_zend_module_entry * zend_module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 323 C php5ts.dll!php_info_print_module(_zend_module_entry * zend_module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 103 + 0x8 bytes C php5ts.dll!_display_module_info_func(_zend_module_entry * module=0x0266de20, void * * * tsrm_ls=0x025433f0) LÃnea 123 + 0xb bytes C php5ts.dll!zend_hash_apply(_hashtable * ht=0x037cfa38, int (void *, void * * *)* apply_func=0x020b5fc0, void * * * tsrm_ls=0x025433f0) LÃnea 676 + 0x9 bytes C php5ts.dll!php_print_info(int flag=-1, void * * * tsrm_ls=0x025433f0) LÃnea 939 + 0x10 bytes C php5ts.dll!zif_phpinfo(int ht=0, _zval_struct * return_value=0x0389dfc8, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x, int return_value_used=0, void * * * tsrm_ls=0x025433f0) LÃnea 1254C php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data=0x038d0080, void * * * tsrm_ls=0x02543300) LÃnea 316 + 0x41 bytes C php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data=0x, void * * * tsrm_ls=0x) LÃnea 1606 + 0xe bytes C php5ts.dll!execute(_zend_op_array * op_array=0x0389db10, void * * * tsrm_ls=0x02543300) LÃnea 107 + 0xa bytes C php5ts.dll!zend_execute_scripts(int type=8, void * * * tsrm_ls=0x025433f0, _zval_struct * * retval=0x, int file_count=3, ...) LÃnea 1195 C php5ts.dll!php_execute_script(_zend_file_handle * primary_file=0x037cfe5c, void * * * tsrm_ls=0x025433f0) LÃnea 2260 + 0x12 bytes C php5apache2_2.dll!php_handler(request_rec * r=0x025d34e8) LÃnea 669 + 0xe bytes C libhttpd.dll!ap_run_handler(request_rec * r=0x025d34e8) LÃnea 158 + 0x28 bytes C libhttpd.dll!ap_invoke_handler(request_rec * r=0x01596640) LÃnea 376 + 0x6 bytes C libhttpd.dll!ap_process_request(request_rec * r=0x025d34e8) LÃnea 286 C libhttpd.dll!ap_process_http_connection(conn_rec * c=0x025ce488) LÃnea 190 + 0x6 bytes C libhttpd.dll!ap_run_process_connection(conn_rec * c=0x025ce488) LÃnea 43 + 0x28 bytes C libhttpd.dll!ap_process_connection(conn_rec * c=0x025ce488, void * csd=0x025c7460) LÃnea 178 + 0x6 bytes C libhttpd.dll!worker_main(void * thread_num_val=0x025ce480) LÃnea 778 C -- Edit bug report at http://bugs.php.net/bug.php?id=52841&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52841&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52841&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52841&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52841&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52841&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52841&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52841&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52841&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52841&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52841&r=su
Req #52374 [Com]: socket_read(): PHP_NORMAL_READ against user defined string
Edit report at http://bugs.php.net/bug.php?id=52374&edit=1
ID: 52374
Comment by: recycling dot sp dot am at gmail dot com
Reported by:bastard dot internets at gmail dot com
Summary:socket_read(): PHP_NORMAL_READ against user defined
string
Status: Open
Type: Feature/Change Request
Package:Sockets related
Operating System: any
PHP Version:5.3.2
Block user comment: N
New Comment:
In most text protocols, the end of line is written "\r\n" (See http,
POP3,...). Consequently, it requires two consecutive calls using
socket_read() to handle answers from these protocol. The latter call is
only done to bypass the '\n'.
Previous Comments:
[2010-07-19 03:04:39] bastard dot internets at gmail dot com
Note: on the echo line, you may want to replace the end
'$current_line\n' with '".trim($current_line)."\n";'. Because of all
the extra line breaks and carriage returns echoed directly from the read
text, the original example might output a bit oddly.
[2010-07-19 02:20:03] bastard dot internets at gmail dot com
Description:
With the assumption that the PHP_NORMAL_READ flag can be used to
basically read in line-by-line, can a 4th optional function argument be
added to allow users to define what exactly denotes an end of line for
their chosen protocol? If this 4th parameter is not passed by the user,
socket_read() could default to it's current behavior.
With PHP_NORMAL_READ set, socket_read() now stops and returns on any of
the first "\r", "\n", and presumably "\0" characters found. Because
protocols would more often use a different character or character chains
to denote end of line - such as HTTP's "\r\n" - allowing the user to
pass in "\r\n" to tell socket_read() where to stop and return would help
save extra code to correctly handle message parsing, or having to
confirm and discard any useless character socket_read() grabs next.
Also, the current behavior of socket_read() is to consume and return
that "end of line" character, which is good. If the above is
implemented, the function should also consume and return everything up
to and and including that user defined string, to avoid infinite loops.
Test script:
---
// read in line-by-line, echoing the first ord and last ord of each line
just to show my point
$conn = socket_accept($s_socket);
socket_set_nonblock($conn) OR
trigger_error("Failed to set non-blocking for accepted connection!",
E_USER_ERROR);
for($current_line = ''; 1;) {
$current_line = socket_read($conn, 4096, PHP_NORMAL_READ);
if ($current_line == '') {
break;
}
echo "[Start ord at pos 0: ".ord($current_line[0])."; End ord at pos
".(strlen($current_line) - 1).":
".ord($current_line[strlen($current_line) - 1])."]: $current_line\n";
}
Expected result:
With the optional 4th function parameter, the read behavior could be
controlled by the user. For example if a client connected with an HTTP
request, socket_read($conn, 4096, PHP_NORMAL_READ, "\r\n") would return
the current header. The next iteration of socket_read() would return
the next header. And, if socket_read() returned only "\r\n", this would
denote end of headers section.
Actual result:
--
The test script above shows the undesirable behavior if using something
like HTTP to connect to this server. Line 'echo "[Start ord at pos...'
produces an extra line each time. This is because socket_read() stopped
and returned at the first encounter of "\r" in each header line, and on
the next read, stopped and returned at the first encounter of "\n",
which was the very next character in the header line.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52374&edit=1
Bug #52818 [Bgs]: PCRE segfault
Edit report at http://bugs.php.net/bug.php?id=52818&edit=1 ID: 52818 Updated by: paj...@php.net Reported by:svimik at mail dot ru Summary:PCRE segfault Status: Bogus Type: Bug Package:Reproducible crash Operating System: Debian-50-lenny-64 PHP Version:5.3.3 Block user comment: N New Comment: It does not matter if you use apache or not, same cause, same solution. I mentioned apache as an example. Previous Comments: [2010-09-14 17:32:26] svimik at mail dot ru >Because it depends on your apache builds As I said, I'm NOT using Apache, I run this script directly in console, by "php -f file.php" command. >In any case, that's not something we can fix. Why is not possible to catch this error? [2010-09-14 17:06:21] paj...@php.net Because it depends on your apache builds and configurations. You can increase both using php.ini and with some tools on unix (don't remember which, but there is other reports about how to do it here). In any case, that's not something we can fix. [2010-09-14 16:27:11] svimik at mail dot ru Why stack overflow is not a bug? [2010-09-14 13:09:14] ahar...@php.net I can replicate this on a stock trunk build, and it is (as usual) a simple stack overflow. Closing. [2010-09-12 11:35:08] svimik at mail dot ru Thanks to pajoye, the problem was solved by reducing recursion limit. pcre.recursion_limit was default value (10), and only reducing to 1 solved the problem. The only question is: is default value of pcre.recursion_limit too high? And should it work? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52818 -- Edit this bug report at http://bugs.php.net/bug.php?id=52818&edit=1
Bug #52796 [Asn->Fbk]: Sep 08 15:22:32.861368 [WARNING] [pool www0] child 25271 said into stderr: "php
Edit report at http://bugs.php.net/bug.php?id=52796&edit=1 ID: 52796 Updated by: f...@php.net Reported by:momchil at xaxo dot eu Summary:Sep 08 15:22:32.861368 [WARNING] [pool www0] child 25271 said into stderr: "php -Status: Assigned +Status: Feedback Type: Bug Package:FPM related Operating System: linux PHP Version:5.3SVN-2010-09-08 (SVN) Assigned To:fat Block user comment: N New Comment: Can you please test the following patch ? This patch removes libevent from FPM. A simple select base event mechanism has been made instead. It should prevent the forking problem when using libevent. Previous Comments: [2010-09-14 17:38:28] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v2.patch Revision: 1284478708 URL: http://bugs.php.net/patch-display.php?bug=52796&patch=fpm-nomorelibevent.v2.patch&revision=1284478708 [2010-09-10 00:08:56] f...@php.net just follow the current bug and the following http://bugs.php.net/52501 [2010-09-10 00:03:11] momchil at xaxo dot eu ok, can you please point me to the bug report about reloading so that I can follow it and know when it gets fixed? [2010-09-10 00:00:49] f...@php.net you should not use FPM reloading since this bug has not been corrected. Please use restart instead. [2010-09-09 23:57:39] momchil at xaxo dot eu 1,2,4,5 are known. about forking: I thought you mean forking inside php code and did not thought about system(), there is some code using the system() function. reloading: I did not reload fpm at the moment when the crash happened, we are reloading it on fpm.conf/php.ini changes about what I wrote just before on 2010-09-09 21:38 UTC: I was told that the mail() function has been used about 1500 times in a script for sending newsletter, which might be related as you pointed out. I will try without the emergency restart as you suggest, thank you for the pointers and your time investigating this :) 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=52796 -- Edit this bug report at http://bugs.php.net/bug.php?id=52796&edit=1
Bug #52796 [PATCH]: Sep 08 15:22:32.861368 [WARNING] [pool www0] child 25271 said into stderr: "php
Edit report at http://bugs.php.net/bug.php?id=52796&edit=1 ID: 52796 Patch added by: f...@php.net Reported by:momchil at xaxo dot eu Summary:Sep 08 15:22:32.861368 [WARNING] [pool www0] child 25271 said into stderr: "php Status: Assigned Type: Bug Package:FPM related Operating System: linux PHP Version:5.3SVN-2010-09-08 (SVN) Assigned To:fat Block user comment: N New Comment: The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v2.patch Revision: 1284478708 URL: http://bugs.php.net/patch-display.php?bug=52796&patch=fpm-nomorelibevent.v2.patch&revision=1284478708 Previous Comments: [2010-09-10 00:08:56] f...@php.net just follow the current bug and the following http://bugs.php.net/52501 [2010-09-10 00:03:11] momchil at xaxo dot eu ok, can you please point me to the bug report about reloading so that I can follow it and know when it gets fixed? [2010-09-10 00:00:49] f...@php.net you should not use FPM reloading since this bug has not been corrected. Please use restart instead. [2010-09-09 23:57:39] momchil at xaxo dot eu 1,2,4,5 are known. about forking: I thought you mean forking inside php code and did not thought about system(), there is some code using the system() function. reloading: I did not reload fpm at the moment when the crash happened, we are reloading it on fpm.conf/php.ini changes about what I wrote just before on 2010-09-09 21:38 UTC: I was told that the mail() function has been used about 1500 times in a script for sending newsletter, which might be related as you pointed out. I will try without the emergency restart as you suggest, thank you for the pointers and your time investigating this :) [2010-09-09 23:47:47] f...@php.net You have a lots of error in your LOG file: 1- Sep 08 14:10:10.251071 [WARNING] [pool www0] child 13097 said into stderr: "Connection from disallowed IP address '10.13.20.24' is dropped." you should allow those IP address 2- you have a lots of PHP errors which are written to stdout. Search for "said into stderr" in you LOG file. 3- You have calls from external command (rm, convert). when run, php forks for running those command. The problem seem to be similar to bug http://bugs.php.net/52501 4- you have a lot of requests which are executing too slow after 15s and which are ptraced to slowlog. 5- you have a lot of requests which are timeouted after 30s. 6- you have a lot of warning saying your server "seems busy". you should review your configuration file to increase min/max_spare_server. 4- I asked if you did reload FPM. You said no and your LOG file says you had: Sep 08 03:10:07.634996 [NOTICE] using inherited socket fd=6, "10.13.20.26:9910" 5- I asked if your PHP scripts forks somehow. It appears so finaly, the problem occurs when: - some PHP scripts are forking some process (via system() or mail()) - FPM is reloading via emergency_restart_threshold It's a bug related to libevent and forking. I'm on it. You should try disabling emergency_restart_threshold temporarily. 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=52796 -- Edit this bug report at http://bugs.php.net/bug.php?id=52796&edit=1
Bug #52501 [Ana->Fbk]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1
ID: 52501
Updated by: f...@php.net
Reported by:marekroman1 at gmail dot com
Summary:Misconfigured Sendmail sends PHP-FPM into an
infinite loop
-Status: Analyzed
+Status: Feedback
Type: Bug
Package:FPM related
Operating System: DebianLenny2.6.26-2-openvz-amd64
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
Can you please test the following patch ?
This patch removes libevent from FPM. A simple select base event
mechanism has
been made instead. It should prevent the forking problem when using
libevent.
Previous Comments:
[2010-09-14 17:36:23] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-nomorelibevent.v2.patch
Revision: 1284478582
URL:
http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v2.patch&revision=1284478582
[2010-07-31 21:46:46] marekroman1 at gmail dot com
Oh, thanks fat.
[2010-07-31 17:25:58] f...@php.net
the problem does not exist when using kqueue,poll or select on openbsd
(and
certainely on freebsd also).
the problem exists on linux when using epoll,poll or select.
It's all the problem of the libevent when forking.
[2010-07-31 03:23:51] f...@php.net
when calling the mail() function on unix, there is a fork to run the
sendmail command. If the sendmail does not return
quickly and FPM tries to kill the process because of
request_terminate_timeout the bug happens.
Here is a sample C code to simulate a bug sendmail config:
// sendmail_bug.c
#include
int main() {
char buf[11];
while (1) {
read(0, buf, 10);
}
return 0;
}
gcc -o /tmp/sendmail_bug sendmail_bug.c
then configure your php.ini this way:
sendmail_path = /tmp/sendmail_bug
set request_terminate_timeout to a 5s and load a page with the mail
function.
[2010-07-31 00:25:45] marekroman1 at gmail dot com
Description:
(Misconfigured) Sendmail sends PHP-FPM into an infinite loop of
spawning/exiting worker processes when attempting to send an email
through the mail() function. (The php script itself just times out
without any output.)
Since this loop produces 100% cpu load and warnings AND logs these
warnings, the log file has grown to 400MB+ before I noticed the load
spike and stopped PHP-FPM master process with kill -9 PID (nothing else
worked e.g. -QUIT).
After I purge-removed the Sendmail package and installed Postfix
instead, everything is working as it should (I didn't made any changes
to nginx/php-fpm/php config files whatsoever).
Server: nginx-0.8.47
PHP ini settings related to mail: "sendmail_path = /usr/sbin/sendmail -t
-i"
Sendmail state: daemon was not running (sendmail process was called, it
did it's work i.e. nothing, then exited)
PHP configure:
./configure --prefix=/usr --enable-fpm --disable-rpath --with-pear
--disable-debug --with-openssl --with-pcre-regex --with-zlib
--enable-bcmath --with-bz2 --enable-calendar --with-curl --enable-exif
--enable-inline-optimization --with-gd --enable-gd-native-ttf
--with-gettext --with-imap --with-imap-ssl --with-kerberos --with-ldap
--enable-mbstring --enable-mbregex --with-mcrypt --with-mysql
--with-mysqli --enable-pcntl --enable-pdo --with-pdo-firebird
--with-pdo-mysql --with-pdo-pgsql --with-pgsql --enable-shmop
--enable-soap --enable-sockets --enable-sqlite-utf8 --enable-sysvmsg
--enable-sysvsem --enable-sysvshm --with-tidy --enable-wddx
--with-xmlrpc --with-xsl --enable-zip --with-pic --enable-ftp
--enable-dom --enable-xmlwriter --enable-xmlreader --enable-tokenizer
--enable-simplexml --enable-session --enable-posix --enable-phar
--enable-libxml --enable-json --with-iconv --enable-filter
--enable-fileinfo --enable-dba --enable-ctype
Dynamic extensions:
pecl apc-beta (apc.so) and rar (rar.so).
Changed PHP-FPM settings:
listen = /var/run/php-fpm/php-fpm.sock
listen.owner = www-data
listen.group = www-data
user = www-data
group = www-data
pm = dynamic
pm.max_children = 10
pm.start_servers = 4
pm.min_spare_servers = 3
pm.max_spare_servers = 6
request_terminate_timeout = 60
rlimit_files = 10240
chdir = /var/www
catch_workers_output = yes
Test script:
---
$to = 'x...@abc.com';
// subject
$subject = 'Birthday Reminders for August';
// message
$message = '
Birthday Reminders for August
Here are the birthdays upcoming in August!
PersonDayMonthYear
Joe3rdAugust1970
Bug #52501 [PATCH]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1
ID: 52501
Patch added by: f...@php.net
Reported by:marekroman1 at gmail dot com
Summary:Misconfigured Sendmail sends PHP-FPM into an
infinite loop
Status: Analyzed
Type: Bug
Package:FPM related
Operating System: DebianLenny2.6.26-2-openvz-amd64
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
The following patch has been added/updated:
Patch Name: fpm-nomorelibevent.v2.patch
Revision: 1284478582
URL:
http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v2.patch&revision=1284478582
Previous Comments:
[2010-07-31 21:46:46] marekroman1 at gmail dot com
Oh, thanks fat.
[2010-07-31 17:25:58] f...@php.net
the problem does not exist when using kqueue,poll or select on openbsd
(and
certainely on freebsd also).
the problem exists on linux when using epoll,poll or select.
It's all the problem of the libevent when forking.
[2010-07-31 03:23:51] f...@php.net
when calling the mail() function on unix, there is a fork to run the
sendmail command. If the sendmail does not return
quickly and FPM tries to kill the process because of
request_terminate_timeout the bug happens.
Here is a sample C code to simulate a bug sendmail config:
// sendmail_bug.c
#include
int main() {
char buf[11];
while (1) {
read(0, buf, 10);
}
return 0;
}
gcc -o /tmp/sendmail_bug sendmail_bug.c
then configure your php.ini this way:
sendmail_path = /tmp/sendmail_bug
set request_terminate_timeout to a 5s and load a page with the mail
function.
[2010-07-31 00:25:45] marekroman1 at gmail dot com
Description:
(Misconfigured) Sendmail sends PHP-FPM into an infinite loop of
spawning/exiting worker processes when attempting to send an email
through the mail() function. (The php script itself just times out
without any output.)
Since this loop produces 100% cpu load and warnings AND logs these
warnings, the log file has grown to 400MB+ before I noticed the load
spike and stopped PHP-FPM master process with kill -9 PID (nothing else
worked e.g. -QUIT).
After I purge-removed the Sendmail package and installed Postfix
instead, everything is working as it should (I didn't made any changes
to nginx/php-fpm/php config files whatsoever).
Server: nginx-0.8.47
PHP ini settings related to mail: "sendmail_path = /usr/sbin/sendmail -t
-i"
Sendmail state: daemon was not running (sendmail process was called, it
did it's work i.e. nothing, then exited)
PHP configure:
./configure --prefix=/usr --enable-fpm --disable-rpath --with-pear
--disable-debug --with-openssl --with-pcre-regex --with-zlib
--enable-bcmath --with-bz2 --enable-calendar --with-curl --enable-exif
--enable-inline-optimization --with-gd --enable-gd-native-ttf
--with-gettext --with-imap --with-imap-ssl --with-kerberos --with-ldap
--enable-mbstring --enable-mbregex --with-mcrypt --with-mysql
--with-mysqli --enable-pcntl --enable-pdo --with-pdo-firebird
--with-pdo-mysql --with-pdo-pgsql --with-pgsql --enable-shmop
--enable-soap --enable-sockets --enable-sqlite-utf8 --enable-sysvmsg
--enable-sysvsem --enable-sysvshm --with-tidy --enable-wddx
--with-xmlrpc --with-xsl --enable-zip --with-pic --enable-ftp
--enable-dom --enable-xmlwriter --enable-xmlreader --enable-tokenizer
--enable-simplexml --enable-session --enable-posix --enable-phar
--enable-libxml --enable-json --with-iconv --enable-filter
--enable-fileinfo --enable-dba --enable-ctype
Dynamic extensions:
pecl apc-beta (apc.so) and rar (rar.so).
Changed PHP-FPM settings:
listen = /var/run/php-fpm/php-fpm.sock
listen.owner = www-data
listen.group = www-data
user = www-data
group = www-data
pm = dynamic
pm.max_children = 10
pm.start_servers = 4
pm.min_spare_servers = 3
pm.max_spare_servers = 6
request_terminate_timeout = 60
rlimit_files = 10240
chdir = /var/www
catch_workers_output = yes
Test script:
---
$to = 'x...@abc.com';
// subject
$subject = 'Birthday Reminders for August';
// message
$message = '
Birthday Reminders for August
Here are the birthdays upcoming in August!
PersonDayMonthYear
Joe3rdAugust1970
Sally17thAugust1973
';
// To send HTML mail, the Content-type header must be set
$headers = 'MIME-Version: 1.0' . "\r\n";
$headers .= 'Content-type: text/html; charset=UTF-8' . "\r\n";
// Additional headers
$headers .= 'To: Dude Dudeson , Kelly ' .
"\r\n";
$headers .= 'From: Birthday Reminder ' . "\r\n";
$headers
Bug #52818 [Bgs]: PCRE segfault
Edit report at http://bugs.php.net/bug.php?id=52818&edit=1 ID: 52818 User updated by:svimik at mail dot ru Reported by:svimik at mail dot ru Summary:PCRE segfault Status: Bogus Type: Bug Package:Reproducible crash Operating System: Debian-50-lenny-64 PHP Version:5.3.3 Block user comment: N New Comment: >Because it depends on your apache builds As I said, I'm NOT using Apache, I run this script directly in console, by "php -f file.php" command. >In any case, that's not something we can fix. Why is not possible to catch this error? Previous Comments: [2010-09-14 17:06:21] paj...@php.net Because it depends on your apache builds and configurations. You can increase both using php.ini and with some tools on unix (don't remember which, but there is other reports about how to do it here). In any case, that's not something we can fix. [2010-09-14 16:27:11] svimik at mail dot ru Why stack overflow is not a bug? [2010-09-14 13:09:14] ahar...@php.net I can replicate this on a stock trunk build, and it is (as usual) a simple stack overflow. Closing. [2010-09-12 11:35:08] svimik at mail dot ru Thanks to pajoye, the problem was solved by reducing recursion limit. pcre.recursion_limit was default value (10), and only reducing to 1 solved the problem. The only question is: is default value of pcre.recursion_limit too high? And should it work? [2010-09-12 02:35:15] paj...@php.net What's your pcre recursion limit setting? Also it looks like a stack issue to me. In any case, please provide a backtrace, without any patch or random extension (suhoshin or whatever else). 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=52818 -- Edit this bug report at http://bugs.php.net/bug.php?id=52818&edit=1
Bug #52818 [Bgs]: PCRE segfault
Edit report at http://bugs.php.net/bug.php?id=52818&edit=1 ID: 52818 Updated by: paj...@php.net Reported by:svimik at mail dot ru Summary:PCRE segfault Status: Bogus Type: Bug Package:Reproducible crash Operating System: Debian-50-lenny-64 PHP Version:5.3.3 Block user comment: N New Comment: Because it depends on your apache builds and configurations. You can increase both using php.ini and with some tools on unix (don't remember which, but there is other reports about how to do it here). In any case, that's not something we can fix. Previous Comments: [2010-09-14 16:27:11] svimik at mail dot ru Why stack overflow is not a bug? [2010-09-14 13:09:14] ahar...@php.net I can replicate this on a stock trunk build, and it is (as usual) a simple stack overflow. Closing. [2010-09-12 11:35:08] svimik at mail dot ru Thanks to pajoye, the problem was solved by reducing recursion limit. pcre.recursion_limit was default value (10), and only reducing to 1 solved the problem. The only question is: is default value of pcre.recursion_limit too high? And should it work? [2010-09-12 02:35:15] paj...@php.net What's your pcre recursion limit setting? Also it looks like a stack issue to me. In any case, please provide a backtrace, without any patch or random extension (suhoshin or whatever else). [2010-09-12 00:57:27] svimik at mail dot ru Tested versions: PHP 5.3.2-2 with Suhosin-Patch (cli) (built: Jul 19 2010 01:22:58) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with XCache v1.3.0, Copyright (c) 2005-2009, by mOo PHP 5.2.12-2 with Suhosin-Patch 0.9.7 (cli) (built: Jan 11 2010 16:51:28) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with XCache v1.3.0, Copyright (c) 2005-2009, by mOo PHP 5.2.9 (cli) (built: Mar 31 2009 23:21:47) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies PHP 5.2.6-1+lenny8 with Suhosin-Patch 0.9.6.2 (cli) (built: Mar 14 2010 08:14:04) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies 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=52818 -- Edit this bug report at http://bugs.php.net/bug.php?id=52818&edit=1
Bug #52818 [Bgs]: PCRE segfault
Edit report at http://bugs.php.net/bug.php?id=52818&edit=1 ID: 52818 User updated by:svimik at mail dot ru Reported by:svimik at mail dot ru Summary:PCRE segfault Status: Bogus Type: Bug Package:Reproducible crash Operating System: Debian-50-lenny-64 PHP Version:5.3.3 Block user comment: N New Comment: Why stack overflow is not a bug? Previous Comments: [2010-09-14 13:09:14] ahar...@php.net I can replicate this on a stock trunk build, and it is (as usual) a simple stack overflow. Closing. [2010-09-12 11:35:08] svimik at mail dot ru Thanks to pajoye, the problem was solved by reducing recursion limit. pcre.recursion_limit was default value (10), and only reducing to 1 solved the problem. The only question is: is default value of pcre.recursion_limit too high? And should it work? [2010-09-12 02:35:15] paj...@php.net What's your pcre recursion limit setting? Also it looks like a stack issue to me. In any case, please provide a backtrace, without any patch or random extension (suhoshin or whatever else). [2010-09-12 00:57:27] svimik at mail dot ru Tested versions: PHP 5.3.2-2 with Suhosin-Patch (cli) (built: Jul 19 2010 01:22:58) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with XCache v1.3.0, Copyright (c) 2005-2009, by mOo PHP 5.2.12-2 with Suhosin-Patch 0.9.7 (cli) (built: Jan 11 2010 16:51:28) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with XCache v1.3.0, Copyright (c) 2005-2009, by mOo PHP 5.2.9 (cli) (built: Mar 31 2009 23:21:47) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies PHP 5.2.6-1+lenny8 with Suhosin-Patch 0.9.6.2 (cli) (built: Mar 14 2010 08:14:04) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies [2010-09-12 00:48:44] svimik at mail dot ru Description: My phpinfo: http://188.40.74.4/_phpinfo.php My hardware configuration: http://www.hetzner.de/en/hosting/produkte_rootserver/eq4/ Test condition: Run the script below in console (via SSH in my case). Result: Segmentation fault Note: the regular expression may look senseless, because it was shortened to the minimun length for reproducing the bug. Bug is reproducible on php 5.2.6, 5.2.9, 5.2.12 and 5.3.2. (Sorry, can't test on the latest version, waiting for someone to confirm the bug on 5.3.3). Sorry, can't make a backtrace on a production server, because it is necessary to recompile the php. In Windows this script works well. Test script: --- $str="
Bug #52839 [Opn->Bgs]: Wrong NumberFormatter::SPELLOUT for Russian language
Edit report at http://bugs.php.net/bug.php?id=52839&edit=1 ID: 52839 Updated by: ahar...@php.net Reported by:rtmvnv at gmail dot com Summary:Wrong NumberFormatter::SPELLOUT for Russian language -Status: Open +Status: Bogus Type: Bug Package:*Unicode Issues Operating System: all PHP Version:5.3.3 Block user comment: N New Comment: This looks to be dependent on the installed version of libicu: a libicu 3.8 installation results in "ÑÑÑÑÑа девÑÑÑ ÑÑо воÑемÑдеÑÑÑ ÑеÑÑÑе", whereas libicu 4.2.1 results in "одна ÑÑÑÑÑа девÑÑÑÑÐ¾Ñ Ð²Ð¾ÑемÑдеÑÑÑ ÑеÑÑÑе". In short, it's an upstream bug that's been fixed, so the only useful advice I can offer is to upgrade libicu. Previous Comments: [2010-09-14 15:56:18] rtmvnv at gmail dot com Description: format(1984); ?> As a result we get "ÑÑÑÑÑа девÑÑÑ ÑÑо воÑемÑдеÑÑÑ ÑеÑÑÑе" which is incorrect. Should be "ÑÑÑÑÑа девÑÑÑÑÐ¾Ñ Ð²Ð¾ÑемÑдеÑÑÑ ÑеÑÑÑе". Test script: --- format(1984); ?> Expected result: ÑÑÑÑÑа девÑÑÑÑÐ¾Ñ Ð²Ð¾ÑемÑдеÑÑÑ ÑеÑÑÑе Actual result: -- ÑÑÑÑÑа девÑÑÑ ÑÑо воÑемÑдеÑÑÑ ÑеÑÑÑе -- Edit this bug report at http://bugs.php.net/bug.php?id=52839&edit=1
[PHP-BUG] Bug #52839 [NEW]: Wrong NumberFormatter::SPELLOUT for Russian language
From: Operating system: all PHP version: 5.3.3 Package: *Unicode Issues Bug Type: Bug Bug description:Wrong NumberFormatter::SPELLOUT for Russian language Description: format(1984); ?> As a result we get "ÑÑÑÑÑа девÑÑÑ ÑÑо воÑемÑдеÑÑÑ ÑеÑÑÑе" which is incorrect. Should be "ÑÑÑÑÑа девÑÑÑÑÐ¾Ñ Ð²Ð¾ÑемÑдеÑÑÑ ÑеÑÑÑе". Test script: --- format(1984); ?> Expected result: ÑÑÑÑÑа девÑÑÑÑÐ¾Ñ Ð²Ð¾ÑемÑдеÑÑÑ ÑеÑÑÑе Actual result: -- ÑÑÑÑÑа девÑÑÑ ÑÑо воÑемÑдеÑÑÑ ÑеÑÑÑе -- Edit bug report at http://bugs.php.net/bug.php?id=52839&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52839&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52839&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52839&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52839&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52839&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52839&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52839&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52839&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52839&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52839&r=support Expected behavior: http://bugs.php.net/fix.php?id=52839&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52839&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52839&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52839&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52839&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52839&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52839&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52839&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52839&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52839&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52839&r=mysqlcfg
Bug #51857 [Ver->Fbk]: deleteName() for directories returns True on non-success
Edit report at http://bugs.php.net/bug.php?id=51857&edit=1
ID: 51857
Updated by: paj...@php.net
Reported by:nuabaranda at web dot de
Summary:deleteName() for directories returns True on
non-success
-Status: Verified
+Status: Feedback
Type: Bug
Package:Zip Related
Operating System: Linux 2.6.27
PHP Version:5.3.3-dev
Assigned To:pajoye
Block user comment: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can't reproduce the problem, can you try again pls?
Previous Comments:
[2010-05-21 19:41:42] phi...@php.net
And for good measure:
open(FILEPATH_ZIPFILE, ZIPARCHIVE::CREATE) === TRUE) {
$zip->addFromString('foo.txt', 'foo');
$zip->addFromString('bar.txt', 'bar');
$zip->addEmptyDir('EmptyDirectory');
$zip->addEmptyDir('FullDirectory');
$zip->addFromString('FullDirectory/baz.txt', 'baz');
$zip->close();
}
/* Mess with the Zip file */
$zip = new ZipArchive;
if ($zip->open(FILEPATH_ZIPFILE) === TRUE) {
/* Fails to delete */
$r1 = $zip->deleteName('EmptyDirectory');
/* Successful delete (note the appended '/' */
$r2 = $zip->deleteName('EmptyDirectory/');
/* Fails to delete */
$r3 = $zip->deleteName('FullDirectory');
/* Fails to delete, although returns true */
$r4 = $zip->deleteName('FullDirectory/');
$zip->close();
}
/* Display the Zip file contents */
$zip = new ZipArchive;
if ($zip->open(FILEPATH_ZIPFILE) === TRUE) {
echo 'File count: ', $zip->numFiles, PHP_EOL;
echo 'Status: ', $zip->status, PHP_EOL;
for ($i = 0; $i < $zip->numFiles; $i++) {
$stat = $zip->statIndex($i);
echo 'Index: ', $i, ' ', $stat['name'], PHP_EOL;
}
$zip->close();
}
var_dump(
array('r1' => $r1, 'r2' => $r2, 'r3' => $r3, 'r4' => $r4)
);
Returns:
File count: 3
Status: 0
Index: 0 foo.txt
Index: 1 bar.txt
Index: 2 FullDirectory/baz.txt
array(4) {
["r1"]=>
bool(false)
["r2"]=>
bool(true)
["r3"]=>
bool(false)
["r4"]=>
bool(true)
}
[2010-05-19 09:43:27] nuabaranda at web dot de
Description:
When trying to delete a non-empty directory in a ZIP file with
deleteName() the function will return True and not delete the directory
if it is not empty. Expectation would be to return False if the
directory can not be deleted.
Also the directory handling should be better documentated (usage of
trailing slashes, examples).
Test script:
---
$zip = new ZipArchive;
if( $zip->open('archive.zip', ZipArchive::CREATE) ) {
$zip->addEmptyDir('folder');
$zip->addFile('folder/file.txt');
if( ! $zip->deleteName('folder/') ) {
echo 'Should end up here if folder not deletable';
}
}
$zip->close();
Expected result:
Should echo.
Actual result:
--
Will not echo.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51857&edit=1
Bug #52830 [Bgs]: PHP hangs on various setups when trying to read from a corrupted ZIP file
Edit report at http://bugs.php.net/bug.php?id=52830&edit=1 ID: 52830 User updated by:johannes_schultz at gmx dot de Reported by:johannes_schultz at gmx dot de Summary:PHP hangs on various setups when trying to read from a corrupted ZIP file Status: Bogus Type: Bug Package:Zip Related Operating System: Windows, Debian PHP Version:Irrelevant Block user comment: N New Comment: Ok, so is there a quick way to _just_ build the zip extension? A quick glance at the "configure" help at least doesn't show a quick way to ignore all other stuff to be built... Previous Comments: [2010-09-14 13:33:22] paj...@php.net You can compile your own zip extension and use it until Debian has updated their package. [2010-09-14 13:26:54] johannes_schultz at gmx dot de Is there a way to somehow circumvent this problem on older versions, though? I don't really want to mess around with the server software, even if I can. [2010-09-14 13:23:38] paj...@php.net Thanks :) Not a bug, already fixed > bogus. [2010-09-14 13:22:55] johannes_schultz at gmx dot de I tried 5.3.3, no problems there. [2010-09-14 13:21:30] paj...@php.net Current snapshot or 5.3.3? It should work with 5.3.3 too. Can you try it as well please? 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=52830 -- Edit this bug report at http://bugs.php.net/bug.php?id=52830&edit=1
Bug #52830 [Bgs]: PHP hangs on various setups when trying to read from a corrupted ZIP file
Edit report at http://bugs.php.net/bug.php?id=52830&edit=1 ID: 52830 Updated by: paj...@php.net Reported by:johannes_schultz at gmx dot de Summary:PHP hangs on various setups when trying to read from a corrupted ZIP file Status: Bogus Type: Bug Package:Zip Related Operating System: Windows, Debian PHP Version:Irrelevant Block user comment: N New Comment: You can compile your own zip extension and use it until Debian has updated their package. Previous Comments: [2010-09-14 13:26:54] johannes_schultz at gmx dot de Is there a way to somehow circumvent this problem on older versions, though? I don't really want to mess around with the server software, even if I can. [2010-09-14 13:23:38] paj...@php.net Thanks :) Not a bug, already fixed > bogus. [2010-09-14 13:22:55] johannes_schultz at gmx dot de I tried 5.3.3, no problems there. [2010-09-14 13:21:30] paj...@php.net Current snapshot or 5.3.3? It should work with 5.3.3 too. Can you try it as well please? [2010-09-14 13:17:40] johannes_schultz at gmx dot de Seems to work with the current snapshot, thanks. No I wonder when this fix will be available through the Debian update... 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=52830 -- Edit this bug report at http://bugs.php.net/bug.php?id=52830&edit=1
Bug #52830 [Bgs]: PHP hangs on various setups when trying to read from a corrupted ZIP file
Edit report at http://bugs.php.net/bug.php?id=52830&edit=1 ID: 52830 User updated by:johannes_schultz at gmx dot de Reported by:johannes_schultz at gmx dot de Summary:PHP hangs on various setups when trying to read from a corrupted ZIP file Status: Bogus Type: Bug Package:Zip Related Operating System: Windows, Debian PHP Version:Irrelevant Block user comment: N New Comment: Is there a way to somehow circumvent this problem on older versions, though? I don't really want to mess around with the server software, even if I can. Previous Comments: [2010-09-14 13:23:38] paj...@php.net Thanks :) Not a bug, already fixed > bogus. [2010-09-14 13:22:55] johannes_schultz at gmx dot de I tried 5.3.3, no problems there. [2010-09-14 13:21:30] paj...@php.net Current snapshot or 5.3.3? It should work with 5.3.3 too. Can you try it as well please? [2010-09-14 13:17:40] johannes_schultz at gmx dot de Seems to work with the current snapshot, thanks. No I wonder when this fix will be available through the Debian update... [2010-09-14 08:12:28] ahar...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ This sounds like bug #44382, which was fixed some time ago, and I can't reproduce it on a current version of PHP. 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=52830 -- Edit this bug report at http://bugs.php.net/bug.php?id=52830&edit=1
Bug #52830 [Opn->Bgs]: PHP hangs on various setups when trying to read from a corrupted ZIP file
Edit report at http://bugs.php.net/bug.php?id=52830&edit=1
ID: 52830
Updated by: paj...@php.net
Reported by:johannes_schultz at gmx dot de
Summary:PHP hangs on various setups when trying to read from
a corrupted ZIP file
-Status: Open
+Status: Bogus
Type: Bug
Package:Zip Related
Operating System: Windows, Debian
PHP Version:Irrelevant
Block user comment: N
New Comment:
Thanks :)
Not a bug, already fixed > bogus.
Previous Comments:
[2010-09-14 13:22:55] johannes_schultz at gmx dot de
I tried 5.3.3, no problems there.
[2010-09-14 13:21:30] paj...@php.net
Current snapshot or 5.3.3? It should work with 5.3.3 too. Can you try it
as well please?
[2010-09-14 13:17:40] johannes_schultz at gmx dot de
Seems to work with the current snapshot, thanks. No I wonder when this
fix will be available through the Debian update...
[2010-09-14 08:12:28] ahar...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
This sounds like bug #44382, which was fixed some time ago, and I can't
reproduce it on a current version of PHP.
[2010-09-13 21:47:22] johannes_schultz at gmx dot de
Description:
I have a broken ZIP file which makes PHP hang on various setups on both
Windows and Linux (Debian):
http://modplug.soonlabel.com/music/1000/1342-The_Mighty_Roofus-Trondheim.mp3.zip
If the CHECKCONS flag is involved, it hangs already when opening the
archive, else it will hang when trying to extract the file.
Test script:
---
$zipRead = new ZipArchive;
$res = $zipRead->open("1342-The_Mighty_Roofus-Trondheim.mp3.zip",
ZipArchive::CHECKCONS); // this will hang PHP
Expected result:
Returning an error
Actual result:
--
PHP hangs
--
Edit this bug report at http://bugs.php.net/bug.php?id=52830&edit=1
Bug #52830 [Fbk->Opn]: PHP hangs on various setups when trying to read from a corrupted ZIP file
Edit report at http://bugs.php.net/bug.php?id=52830&edit=1
ID: 52830
User updated by:johannes_schultz at gmx dot de
Reported by:johannes_schultz at gmx dot de
Summary:PHP hangs on various setups when trying to read from
a corrupted ZIP file
-Status: Feedback
+Status: Open
Type: Bug
Package:Zip Related
Operating System: Windows, Debian
PHP Version:Irrelevant
Block user comment: N
New Comment:
I tried 5.3.3, no problems there.
Previous Comments:
[2010-09-14 13:21:30] paj...@php.net
Current snapshot or 5.3.3? It should work with 5.3.3 too. Can you try it
as well please?
[2010-09-14 13:17:40] johannes_schultz at gmx dot de
Seems to work with the current snapshot, thanks. No I wonder when this
fix will be available through the Debian update...
[2010-09-14 08:12:28] ahar...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
This sounds like bug #44382, which was fixed some time ago, and I can't
reproduce it on a current version of PHP.
[2010-09-13 21:47:22] johannes_schultz at gmx dot de
Description:
I have a broken ZIP file which makes PHP hang on various setups on both
Windows and Linux (Debian):
http://modplug.soonlabel.com/music/1000/1342-The_Mighty_Roofus-Trondheim.mp3.zip
If the CHECKCONS flag is involved, it hangs already when opening the
archive, else it will hang when trying to extract the file.
Test script:
---
$zipRead = new ZipArchive;
$res = $zipRead->open("1342-The_Mighty_Roofus-Trondheim.mp3.zip",
ZipArchive::CHECKCONS); // this will hang PHP
Expected result:
Returning an error
Actual result:
--
PHP hangs
--
Edit this bug report at http://bugs.php.net/bug.php?id=52830&edit=1
Bug #52830 [Opn->Fbk]: PHP hangs on various setups when trying to read from a corrupted ZIP file
Edit report at http://bugs.php.net/bug.php?id=52830&edit=1
ID: 52830
Updated by: paj...@php.net
Reported by:johannes_schultz at gmx dot de
Summary:PHP hangs on various setups when trying to read from
a corrupted ZIP file
-Status: Open
+Status: Feedback
Type: Bug
Package:Zip Related
Operating System: Windows, Debian
PHP Version:Irrelevant
Block user comment: N
New Comment:
Current snapshot or 5.3.3? It should work with 5.3.3 too. Can you try it
as well please?
Previous Comments:
[2010-09-14 13:17:40] johannes_schultz at gmx dot de
Seems to work with the current snapshot, thanks. No I wonder when this
fix will be available through the Debian update...
[2010-09-14 08:12:28] ahar...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
This sounds like bug #44382, which was fixed some time ago, and I can't
reproduce it on a current version of PHP.
[2010-09-13 21:47:22] johannes_schultz at gmx dot de
Description:
I have a broken ZIP file which makes PHP hang on various setups on both
Windows and Linux (Debian):
http://modplug.soonlabel.com/music/1000/1342-The_Mighty_Roofus-Trondheim.mp3.zip
If the CHECKCONS flag is involved, it hangs already when opening the
archive, else it will hang when trying to extract the file.
Test script:
---
$zipRead = new ZipArchive;
$res = $zipRead->open("1342-The_Mighty_Roofus-Trondheim.mp3.zip",
ZipArchive::CHECKCONS); // this will hang PHP
Expected result:
Returning an error
Actual result:
--
PHP hangs
--
Edit this bug report at http://bugs.php.net/bug.php?id=52830&edit=1
Bug #52830 [Fbk->Opn]: PHP hangs on various setups when trying to read from a corrupted ZIP file
Edit report at http://bugs.php.net/bug.php?id=52830&edit=1
ID: 52830
User updated by:johannes_schultz at gmx dot de
Reported by:johannes_schultz at gmx dot de
Summary:PHP hangs on various setups when trying to read from
a corrupted ZIP file
-Status: Feedback
+Status: Open
Type: Bug
Package:Zip Related
Operating System: Windows, Debian
PHP Version:Irrelevant
Block user comment: N
New Comment:
Seems to work with the current snapshot, thanks. No I wonder when this
fix will be available through the Debian update...
Previous Comments:
[2010-09-14 08:12:28] ahar...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
This sounds like bug #44382, which was fixed some time ago, and I can't
reproduce it on a current version of PHP.
[2010-09-13 21:47:22] johannes_schultz at gmx dot de
Description:
I have a broken ZIP file which makes PHP hang on various setups on both
Windows and Linux (Debian):
http://modplug.soonlabel.com/music/1000/1342-The_Mighty_Roofus-Trondheim.mp3.zip
If the CHECKCONS flag is involved, it hangs already when opening the
archive, else it will hang when trying to extract the file.
Test script:
---
$zipRead = new ZipArchive;
$res = $zipRead->open("1342-The_Mighty_Roofus-Trondheim.mp3.zip",
ZipArchive::CHECKCONS); // this will hang PHP
Expected result:
Returning an error
Actual result:
--
PHP hangs
--
Edit this bug report at http://bugs.php.net/bug.php?id=52830&edit=1
Bug #52818 [Opn->Bgs]: PCRE segfault
Edit report at http://bugs.php.net/bug.php?id=52818&edit=1 ID: 52818 Updated by: ahar...@php.net Reported by:svimik at mail dot ru Summary:PCRE segfault -Status: Open +Status: Bogus Type: Bug Package:Reproducible crash Operating System: Debian-50-lenny-64 PHP Version:5.3.3 Block user comment: N New Comment: I can replicate this on a stock trunk build, and it is (as usual) a simple stack overflow. Closing. Previous Comments: [2010-09-12 11:35:08] svimik at mail dot ru Thanks to pajoye, the problem was solved by reducing recursion limit. pcre.recursion_limit was default value (10), and only reducing to 1 solved the problem. The only question is: is default value of pcre.recursion_limit too high? And should it work? [2010-09-12 02:35:15] paj...@php.net What's your pcre recursion limit setting? Also it looks like a stack issue to me. In any case, please provide a backtrace, without any patch or random extension (suhoshin or whatever else). [2010-09-12 00:57:27] svimik at mail dot ru Tested versions: PHP 5.3.2-2 with Suhosin-Patch (cli) (built: Jul 19 2010 01:22:58) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with XCache v1.3.0, Copyright (c) 2005-2009, by mOo PHP 5.2.12-2 with Suhosin-Patch 0.9.7 (cli) (built: Jan 11 2010 16:51:28) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with XCache v1.3.0, Copyright (c) 2005-2009, by mOo PHP 5.2.9 (cli) (built: Mar 31 2009 23:21:47) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies PHP 5.2.6-1+lenny8 with Suhosin-Patch 0.9.6.2 (cli) (built: Mar 14 2010 08:14:04) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies [2010-09-12 00:48:44] svimik at mail dot ru Description: My phpinfo: http://188.40.74.4/_phpinfo.php My hardware configuration: http://www.hetzner.de/en/hosting/produkte_rootserver/eq4/ Test condition: Run the script below in console (via SSH in my case). Result: Segmentation fault Note: the regular expression may look senseless, because it was shortened to the minimun length for reproducing the bug. Bug is reproducible on php 5.2.6, 5.2.9, 5.2.12 and 5.3.2. (Sorry, can't test on the latest version, waiting for someone to confirm the bug on 5.3.3). Sorry, can't make a backtrace on a production server, because it is necessary to recompile the php. In Windows this script works well. Test script: --- $str="
Bug #52827 [Asn->Csd]: cURL leaks handle and causes assertion error (CURLOPT_STDERR)
Edit report at http://bugs.php.net/bug.php?id=52827&edit=1 ID: 52827 Updated by: ahar...@php.net Reported by:cataphr...@php.net Summary:cURL leaks handle and causes assertion error (CURLOPT_STDERR) -Status: Assigned +Status: Closed Type: Bug Package:cURL related Operating System: Debian Lenny x64; Windows 7 x64 PHP Version:5.3.3 Assigned To:aharvey Block user comment: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Thanks Gustavo! Previous Comments: [2010-09-14 12:59:01] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=303361 Log: Fix bug #52827 (cURL leaks handle and causes assertion error (CURLOPT_STDERR)). Patch by Gustavo. [2010-09-13 20:49:58] cataphr...@php.net The following patch has been added/updated: Patch Name: curlopt_stderr_with_test Revision: 1284403798 URL: http://bugs.php.net/patch-display.php?bug=52827&patch=curlopt_stderr_with_test&revision=1284403798 [2010-09-13 16:56:01] cataphr...@php.net The following patch has been added/updated: Patch Name: curlopt_stderr Revision: 1284389761 URL: http://bugs.php.net/patch-display.php?bug=52827&patch=curlopt_stderr&revision=1284389761 [2010-09-13 16:55:39] cataphr...@php.net Description: curl_setopt, when given a stream with CURLOPT_STDERR, stores the zval* and increments both the refcount of the zval* and of the resource. Only the refcount of the zval should be incremented. Additionally, due to a flaw in the streams API, this leak results in an assertion error. The reason is that on shutdown the unexposed/leaked resources are destroyed in reverse order, so the encapsulated STDIO stream is destroyed first and when the TEMP stream is destroyed, it then tries to close the encapsulated STDIO steam again. I will submit this as a separate bug report. Test script: --- http://www.example.com'); curl_setopt($handle, CURLOPT_STDERR, $s); Expected result: No output. Actual result: -- (with stream debug) stream_alloc: TEMP:0x12a61b0 persistent=(null) stream_alloc: MEMORY:0x12a6488 persistent=(null) stream_alloc: STDIO:0x12a6f90 persistent=(null) stream_free: MEMORY:0x12a6488[(null)] in_free=0 opts=0003 stream_free: MEMORY:0x12a6488[(null)] preserve_handle=0 release_cast=1 remove_rs rc=1 stream_free: MEMORY:0x12a6488[(null)] in_free=1 opts=000b stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] in_free=0 opts=000b stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] preserve_handle=0 release_cast=1 re move_rsrc=1 /tmp/php-5.3.3/main/streams/streams.c(400) : Stream of type 'STDIO' 0x12a6f90 (p ath:/tmp/phpghmjqQ) was not closed stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] in_free=0 opts=000b stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] preserve_handle=0 release _cast=1 remove_rsrc=1 php: /tmp/php-5.3.3/main/streams/plain_wrapper.c:434: php_stdiop_flush: Assertio n `data != ((void *)0)' failed. Aborted #0 0x7f74b5a22ed5 in raise () from /lib/libc.so.6 #1 0x7f74b5a243f3 in abort () from /lib/libc.so.6 #2 0x7f74b5a1bdc9 in __assert_fail () from /lib/libc.so.6 #3 0x0076129e in php_stdiop_flush (stream=0x1049dc8) at /tmp/php-5.3.3/main/streams/plain_wrapper.c:434 #4 0x007596dd in _php_stream_flush (stream=0x1049dc8, closing=0) at /tmp/php-5.3.3/main/streams/streams.c:1050 #5 0x0075df57 in php_stream_temp_flush (stream=0x1049050) at /tmp/php-5.3.3/main/streams/memory.c:440 #6 0x007596dd in _php_stream_flush (stream=0x1049050, closing=1) at /tmp/php-5.3.3/main/streams/streams.c:1050 #7 0x00757b4d in _php_stream_free (stream=0x1049050, close_options=11) at /tmp/php-5.3.3/main/streams/streams.c:331 #8 0x0075a831 in stream_resource_regular_dtor (rsrc=0x104ab48) at /tmp/php-5.3.3/main/streams/streams.c:1426 #9 0x007c4f9e in list_entry_destructor (ptr=0x104ab48) at /tmp/php-5.3.3/Zend/zend_list.c:184 #10 0x007c249d in zend_hash_apply_deleter (ht=0xe0c650, p=0x1049198) at /tmp/php-5.3.3/Zend/zend_hash.c:611 #11 0x007c25ff in zend_hash_graceful_reverse_destroy (ht=0xe0c650) at /tmp/php-5.3.3/Zend/zend_hash.c:646 #12 0x007c510f in zend_destroy_rsrc_list (ht=0xe0c650
Bug #52827 [Opn->Asn]: cURL leaks handle and causes assertion error (CURLOPT_STDERR)
Edit report at http://bugs.php.net/bug.php?id=52827&edit=1 ID: 52827 Updated by: ahar...@php.net Reported by:cataphr...@php.net Summary:cURL leaks handle and causes assertion error (CURLOPT_STDERR) -Status: Open +Status: Assigned Type: Bug Package:cURL related Operating System: Debian Lenny x64; Windows 7 x64 PHP Version:5.3.3 -Assigned To: +Assigned To:aharvey Block user comment: N Previous Comments: [2010-09-13 20:49:58] cataphr...@php.net The following patch has been added/updated: Patch Name: curlopt_stderr_with_test Revision: 1284403798 URL: http://bugs.php.net/patch-display.php?bug=52827&patch=curlopt_stderr_with_test&revision=1284403798 [2010-09-13 16:56:01] cataphr...@php.net The following patch has been added/updated: Patch Name: curlopt_stderr Revision: 1284389761 URL: http://bugs.php.net/patch-display.php?bug=52827&patch=curlopt_stderr&revision=1284389761 [2010-09-13 16:55:39] cataphr...@php.net Description: curl_setopt, when given a stream with CURLOPT_STDERR, stores the zval* and increments both the refcount of the zval* and of the resource. Only the refcount of the zval should be incremented. Additionally, due to a flaw in the streams API, this leak results in an assertion error. The reason is that on shutdown the unexposed/leaked resources are destroyed in reverse order, so the encapsulated STDIO stream is destroyed first and when the TEMP stream is destroyed, it then tries to close the encapsulated STDIO steam again. I will submit this as a separate bug report. Test script: --- http://www.example.com'); curl_setopt($handle, CURLOPT_STDERR, $s); Expected result: No output. Actual result: -- (with stream debug) stream_alloc: TEMP:0x12a61b0 persistent=(null) stream_alloc: MEMORY:0x12a6488 persistent=(null) stream_alloc: STDIO:0x12a6f90 persistent=(null) stream_free: MEMORY:0x12a6488[(null)] in_free=0 opts=0003 stream_free: MEMORY:0x12a6488[(null)] preserve_handle=0 release_cast=1 remove_rs rc=1 stream_free: MEMORY:0x12a6488[(null)] in_free=1 opts=000b stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] in_free=0 opts=000b stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] preserve_handle=0 release_cast=1 re move_rsrc=1 /tmp/php-5.3.3/main/streams/streams.c(400) : Stream of type 'STDIO' 0x12a6f90 (p ath:/tmp/phpghmjqQ) was not closed stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] in_free=0 opts=000b stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] preserve_handle=0 release _cast=1 remove_rsrc=1 php: /tmp/php-5.3.3/main/streams/plain_wrapper.c:434: php_stdiop_flush: Assertio n `data != ((void *)0)' failed. Aborted #0 0x7f74b5a22ed5 in raise () from /lib/libc.so.6 #1 0x7f74b5a243f3 in abort () from /lib/libc.so.6 #2 0x7f74b5a1bdc9 in __assert_fail () from /lib/libc.so.6 #3 0x0076129e in php_stdiop_flush (stream=0x1049dc8) at /tmp/php-5.3.3/main/streams/plain_wrapper.c:434 #4 0x007596dd in _php_stream_flush (stream=0x1049dc8, closing=0) at /tmp/php-5.3.3/main/streams/streams.c:1050 #5 0x0075df57 in php_stream_temp_flush (stream=0x1049050) at /tmp/php-5.3.3/main/streams/memory.c:440 #6 0x007596dd in _php_stream_flush (stream=0x1049050, closing=1) at /tmp/php-5.3.3/main/streams/streams.c:1050 #7 0x00757b4d in _php_stream_free (stream=0x1049050, close_options=11) at /tmp/php-5.3.3/main/streams/streams.c:331 #8 0x0075a831 in stream_resource_regular_dtor (rsrc=0x104ab48) at /tmp/php-5.3.3/main/streams/streams.c:1426 #9 0x007c4f9e in list_entry_destructor (ptr=0x104ab48) at /tmp/php-5.3.3/Zend/zend_list.c:184 #10 0x007c249d in zend_hash_apply_deleter (ht=0xe0c650, p=0x1049198) at /tmp/php-5.3.3/Zend/zend_hash.c:611 #11 0x007c25ff in zend_hash_graceful_reverse_destroy (ht=0xe0c650) at /tmp/php-5.3.3/Zend/zend_hash.c:646 #12 0x007c510f in zend_destroy_rsrc_list (ht=0xe0c650) at /tmp/php-5.3.3/Zend/zend_list.c:240 #13 0x007b1549 in zend_deactivate () at /tmp/php-5.3.3/Zend/zend.c:896 #14 0x0073e71b in php_request_shutdown (dummy=0x0) at /tmp/php-5.3.3/main/main.c:1633 #15 0x00899a12 in main (argc=2, argv=0x7fffea5acfa8) at /tmp/php-5.3.3/sapi/cli/php_cli.c:1373 -- Edit this bug report at http://bugs.php.net/bug.php?id=52827&edit=1
Bug #48831 [Asn->Csd]: php -i has different output to php --ini
Edit report at http://bugs.php.net/bug.php?id=48831&edit=1
ID: 48831
Updated by: paj...@php.net
Reported by:RQuadling at GMail dot com
Summary:php -i has different output to php --ini
-Status: Assigned
+Status: Closed
Type: Bug
Package:CGI related
Operating System: *
-PHP Version:5.*, 6CVS (2009-07-07)
+PHP Version:5.*
Assigned To:pajoye
Block user comment: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-09-14 12:36:23] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=303357
Log: - fix #48831 php -i has different output to php --ini
[2010-04-12 17:23:30] rquadl...@php.net
The following patch has been added/updated:
Patch Name: ScanIniDir
Revision: 1271085810
URL:
http://bugs.php.net/patch-display.php?bug=48831&patch=ScanIniDir&revision=1271085810
[2009-08-24 12:48:57] RQuadling at GMail dot com
Missed an PHPAPI extern char *php_ini_scanned_path;
[2009-07-07 11:28:46] rquadl...@php.net
Typo: had => has
[2009-07-07 11:24:31] RQuadling at GMail dot com
Description:
If the environment variable PHP_INI_SCAN_DIR is set, then
php -i
outputs the path and any ini files.
If you enter
php --ini
the ini files are correct, but the scan directory is not.
php --ini is only showing the PHP_CONFIG_FILE_SCAN_DIR value rather
than the php_ini_scanned_path (which may be PHP_CONFIG_FILE_SCAN_DIR
if there is no PHP_INI_SCAN_DIR envvar).
Patch below
Index: php_cli.c
===
RCS file: /repository/php-src/sapi/cli/php_cli.c,v
retrieving revision 1.211
diff -u -r1.211 php_cli.c
--- php_cli.c 5 Jun 2009 18:50:10 - 1.211
+++ php_cli.c 7 Jul 2009 11:16:14 -
@@ -1360,7 +1360,7 @@
{
zend_printf("Configuration
File (php.ini) Path: %s\n", PHP_CONFIG_FILE_PATH);
zend_printf("Loaded
Configuration File: %s\n", php_ini_opened_path ?
php_ini_opened_path : "(none)");
- zend_printf("Scan for
additional .ini files in: %s\n", *PHP_CONFIG_FILE_SCAN_DIR ?
PHP_CONFIG_FILE_SCAN_DIR : "(none)");
+ zend_printf("Scan for
additional .ini files in: %s\n", php_ini_scanned_path ?
php_ini_scanned_path : "(none)");
zend_printf("Additional .ini
files parsed: %s\n", php_ini_scanned_files ?
php_ini_scanned_files : "(none)");
break;
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=48831&edit=1
Bug #31050 [Com]: SOAP class will not parse WSDL file located on a secure HTTPS connection
Edit report at http://bugs.php.net/bug.php?id=31050&edit=1 ID: 31050 Comment by: zhb1208 at hotmail dot com Reported by:dylanwoster at mac dot com Summary:SOAP class will not parse WSDL file located on a secure HTTPS connection Status: No Feedback Type: Bug Package:SOAP related Operating System: Mac OS X 10.3.6 PHP Version:5.0.2 Assigned To:dmitry Block user comment: N New Comment: SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://192.168.0.14:8080/rpc/soap/jirasoapservice-v2?wsdl' : failed to load external entity "http://192.168.0.14:8080/rpc/soap/jirasoapservice-v2?wsdl"; Previous Comments: [2009-03-05 12:13:40] ykohut at parallels dot com I have the same bug on: # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.2 (Tikanga) # uname -p i686 # /hsphere/shared/php5/bin/php-cli --version PHP 5.2.9 (cli) (built: Mar 5 2009 01:52:37) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with the ionCube PHP Loader v3.1.32, Copyright (c) 2002-2007, by ionCube Ltd., and with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies with Zend Optimizer v3.3.0, Copyright (c) 1998-2007, by Zend Technologies The SOAP is loaded as external extension via corresponded .ini file: #cat php.d/soap.ini ; Enable soap extension module extension=soap.so The extension is successfully loaded, which is reported php_info(): soap Soap Client enabled Soap Server enabled Directive Local Value Master Value soap.wsdl_cache 1 1 soap.wsdl_cache_dir /tmp/tmp soap.wsdl_cache_enabled 1 1 soap.wsdl_cache_limit 5 5 soap.wsdl_cache_ttl 86400 86400 and with # php-cli -i: # /hsphere/shared/php5/bin/php-cli -i|grep soap Configure Command => './configure' '--localstatedir=/var/hsphere/php' '--with-bz2=/hsphere/shared' '--enable-ctype' '--enable-dba' '--enable-ftp' '--with-gettext=/hsphere/shared' '--enable-mbstring=all' '--with-gd' '--with-mhash=/hsphere/shared' '--with-mcrypt=/hsphere/shared' '--with-openssl=/usr' '--enable-overload' '--enable-posix' '--enable-session' '--enable-sockets' '--enable-standard' '--enable-tokenizer' '--with-xml=/hsphere/shared' '--with-xsl=/hsphere/shared' '--with-zip=/hsphere/shared' '--with-zlib=/hsphere/shared' '--with-zlib-dir=/hsphere/shared' '--with-freetype-dir=/hsphere/shared' '--with-png-dir=/hsphere/shared' '--with-jpeg-dir=/hsphere/shared' '--with-expat-dir=/hsphere/shared' '--with-iconv-dir=/hsphere/shared' '--with-libxml-dir=/hsphere/shared' '--enable-gd-native-ttf' '--with-ttf' '--enable-mbstr-enc-trans' '--with-expat-dir=/hsphere/shared' '--with-xslt-sablot=/hsphere/shared' '--with-gnu-ld' '--with-curl=shared,/hsphere/shared' '--with-curlwrappers' '--with-dom=shared,/hsphere/shared' '--with-dom-xslt=/hsphere/shared' '--with-dom-exslt=/hsphere/shared' '--with-dom=shared,/hsphere/shared' '--with-fileinfo=shared,/hsphere/shared' '--with-gmp=shared,/hsphere/shared' '--with-iconv=shared,/hsphere/shared' '--with-imap=shared,/hsphere/shared' '--with-imap-ssl=shared,/usr' '--with-mcal=shared,/hsphere/shared' '--with-mysql=shared,/usr' '--with-mysqli=shared' '--with-pgsql=shared,/usr' '--with-sqlite=shared' '--enable-sqlite-utf8' '--with-unixODBC=shared,/hsphere/shared' '--with-xmlrpc=shared' '--enable-htscanner' '--enable-track-vars' '--enable-trans-sid' '--enable-memory-limit' '--enable-force-cgi-redirect' '--enable-fastcgi' '--with-config-file-path=/hsphere/local/config/httpd/php5' '--with-config-file-scan-dir=/hsphere/local/config/httpd/php5/php.d' '--enable-magic-quotes' '--with-pear=/hsphere/shared/apache/libexec/php5ext/php' '--with-mime-magic=/hsphere/local/config/httpd/magic' '--with-inifile' '--with-flatfile' '--enable-pdo=shared' '--with-pdo-sqlite=shared' '--with-pdo-mysql=shared' '--with-pdo-pgsql=shared' '--enable-soap=shared' '--prefix=/hsphere/shared/php5' '--with-apxs=/hsphere/shared/apache/bin/apxs' '--enable-cli' /hsphere/local/config/httpd/php5/php.d/soap.ini, soap soap.wsdl_cache => 1 => 1 soap.wsdl_cache_dir => /tmp => /tmp soap.wsdl_cache_enabled => 1 => 1 soap.wsdl_cache_limit => 5 => 5 soap.wsdl_cache_ttl => 86400 => 86400 The is no matter in which mode PHP is running. The problem take place as well on Apache handler (libphp mode) and CGI/FastCGI modes. The error looks like in: - Apache error_log : [Wed Mar 11 08:23:34 2009] [error] [client 192.168.128.234] failed to load external entity "https://soap.amazon.com/schemas3/AmazonWebServices.wsdl"; - php_error.log : [11-Mar-2009 08:23:34] PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'https://soap.amazon.com/schemas3/AmazonWebServices.wsdl' : failed to load external entity "https://soap.amazon.com/schemas
Bug #52833 [Opn->Bgs]: memory limit and custom error handler produces more errors than expected
Edit report at http://bugs.php.net/bug.php?id=52833&edit=1
ID: 52833
Updated by: rquadl...@php.net
Reported by:me at unreal4u dot com
Summary:memory limit and custom error handler produces more
errors than expected
-Status: Open
+Status: Bogus
Type: Bug
Package:Output Control
Operating System: CentOS5.5 32bits
PHP Version:5.2.14
Block user comment: N
New Comment:
As reported on the mailing list http://news.php.net/php.general/308053.
Previous Comments:
[2010-09-14 07:59:25] me at unreal4u dot com
Description:
When I get to the memory limit of a script, a fatal error raises
(expected behaviour). In order to nicely capture this error, I have
created a custom error handler (through register_shutdown_function)
which checks whether the script ended normally and so I can capture
certain fatal errors. (Expected behaviour)
Inside this error handler, I raise the memory limit in order to capture
this particular kind of error so that I can begin to check what
happened.
When I check with empty or isset if a certain variable which shouldn't
be initialized yet exists (or doesn't evaluate to FALSE), the function
returns a rather strange error instead of the default FALSE or TRUE.
(Not expected).
Test script:
---
date_default_timezone_set('America/Santiago');
ini_set('memory_limit','1M');
function my_error_handler($errno = '0', $errstr = '[FATAL] General
Error', $errfile = 'N/A', $errline = 'N/A', $errctx = '') {
global $clean_exit;
if(empty($clean_exit)) { // if isset or !empty, the script would have
been exited cleanly.
ini_set('memory_limit','16M'); // This would be just to have enough
memory to print out the error.
echo '-- BEGIN ERROR --Error N°:
'.$errno.'Error Description:
'.$errstr.'File: '.$errfile.'Line: '.$errline.'Memory:
'.round(memory_get_usage() / 1024).'KiB /
'.round(memory_get_peak_usage() / 1024).'KiB';
if (isset($errctx['r']['print'])) echo 'THIS LINE GIVES THE ERROR
AND IS NOT PRINTED'; // isset or empty gives the same error
echo '-- END ERROR --';
die(); // shutdown_function == manual die() or else it will continue
to execute.
}
}
set_error_handler('my_error_handler');
register_shutdown_function('my_error_handler');
for ($i = 0; $i < 15000; $i++) $a[$i] = mt_rand(1,255);
$r['print'] = (string)$a[1]; // Just to fill something up
echo 'Everything fine.';
$clean_exit = TRUE;
Expected result:
empty or isset returns FALSE, thus dying (normally) one level earlier.
Actual result:
--
An E_NOTICE appears:
Uninitialized string offset: 0 on file X line Y
--
Edit this bug report at http://bugs.php.net/bug.php?id=52833&edit=1
Bug #52836 [Fbk->Bgs]: iconv //TRANSLIT property not functioning as it should
Edit report at http://bugs.php.net/bug.php?id=52836&edit=1 ID: 52836 Updated by: ahar...@php.net Reported by:danny at studyportals dot eu Summary:iconv //TRANSLIT property not functioning as it should -Status: Feedback +Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: Windows 7 PHP Version:5.3.3 Block user comment: N New Comment: Not developer issue -> closing. Previous Comments: [2010-09-14 11:25:48] danny at studyportals dot eu This seemed to have solved the test I have set up, but for us, the issue persists. I will investigate this issue further and try to find out why it is not working for me. Thank you for your quick responce [2010-09-14 10:48:26] ahar...@php.net Are you sure your PHP script is saved as UTF-8? This works as expected for me when it is, but fails similarly to your example when the PHP script is in a single-byte encoding where ⬠is an invalid UTF-8 string, such as ISO-8859-15. [2010-09-14 10:41:01] danny at studyportals dot eu Description: This bug was discovered in libiconv 1.11 The //TRANSLIT property seems to be discarded. While passing this property and encountering characters as ⬠it handles as if you used the plain variant on it. See test case below, this is the example given in the PHP docs (http://php.net/manual/en/function.iconv.php) Test script: --- Expected result: Original : This is the Euro symbol 'â¬'. TRANSLIT : This is the Euro symbol 'EUR'. IGNORE : This is the Euro symbol ''. Plain: Notice: iconv(): Detected an illegal character in input string in .\iconv- example.php on line 7 This is the Euro symbol ' (Example on http://php.net/manual/en/function.iconv.php) Actual result: -- Original : This is the Euro symbol 'â¬'. TRANSLIT : Notice: iconv(): Detected an illegal character in input string in D:\Web\Webroot\test.php on line 6 This is the Euro symbol ' IGNORE : This is the Euro symbol ''. Plain : Notice: iconv(): Detected an illegal character in input string in D:\Web\Webroot\test.php on line 8 This is the Euro symbol ' -- Edit this bug report at http://bugs.php.net/bug.php?id=52836&edit=1
Bug #52836 [Com]: iconv //TRANSLIT property not functioning as it should
Edit report at http://bugs.php.net/bug.php?id=52836&edit=1 ID: 52836 Comment by: danny at studyportals dot eu Reported by:danny at studyportals dot eu Summary:iconv //TRANSLIT property not functioning as it should Status: Feedback Type: Bug Package:Unknown/Other Function Operating System: Windows 7 PHP Version:5.3.3 Block user comment: N New Comment: This seemed to have solved the test I have set up, but for us, the issue persists. I will investigate this issue further and try to find out why it is not working for me. Thank you for your quick responce Previous Comments: [2010-09-14 10:48:26] ahar...@php.net Are you sure your PHP script is saved as UTF-8? This works as expected for me when it is, but fails similarly to your example when the PHP script is in a single-byte encoding where ⬠is an invalid UTF-8 string, such as ISO-8859-15. [2010-09-14 10:41:01] danny at studyportals dot eu Description: This bug was discovered in libiconv 1.11 The //TRANSLIT property seems to be discarded. While passing this property and encountering characters as ⬠it handles as if you used the plain variant on it. See test case below, this is the example given in the PHP docs (http://php.net/manual/en/function.iconv.php) Test script: --- Expected result: Original : This is the Euro symbol 'â¬'. TRANSLIT : This is the Euro symbol 'EUR'. IGNORE : This is the Euro symbol ''. Plain: Notice: iconv(): Detected an illegal character in input string in .\iconv- example.php on line 7 This is the Euro symbol ' (Example on http://php.net/manual/en/function.iconv.php) Actual result: -- Original : This is the Euro symbol 'â¬'. TRANSLIT : Notice: iconv(): Detected an illegal character in input string in D:\Web\Webroot\test.php on line 6 This is the Euro symbol ' IGNORE : This is the Euro symbol ''. Plain : Notice: iconv(): Detected an illegal character in input string in D:\Web\Webroot\test.php on line 8 This is the Euro symbol ' -- Edit this bug report at http://bugs.php.net/bug.php?id=52836&edit=1
Bug #52838 [Opn->Bgs]: include/require problems with ../
Edit report at http://bugs.php.net/bug.php?id=52838&edit=1 ID: 52838 Updated by: ahar...@php.net Reported by:winzent at gmail dot com Summary:include/require problems with ../ -Status: Open +Status: Bogus Type: Bug Package:*Directory/Filesystem functions Operating System: WinXP maybe others PHP Version:5.3.3 Block user comment: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Include paths are relative to the initial working directory -- that's how PHP has always worked. You may wish to investigate the __FILE__ and __DIR__ constants in the manual. Previous Comments: [2010-09-14 11:18:25] winzent at gmail dot com Description: So here is the layout of my files: B.php page/1.php page/A.php page/mod/2.php 1 and 2 are pages that are used independently. A and B are included files with classes and functions. 1 includes A which includes B 2 includes A which includes B This affects the include,include_once,require and require_once functions. Found this in the 5.2.3 so I upgraded to 5.3.3 and it's still there. I have WinXP Pro SP3 and use Apache 2.2.4 --- I have come up with a workaround for my site, which is to remove B from A and include B in 1 and 2 and all the other filers in the page/mod/ directory, but that is just a pain when it shouldn't work like this! Right? Expected result: Well I expected both 1 and 2 to work. I should not have to take in to account where the file that includes my file lies, so 1 and 2 should get the same results. Actual result: -- The 1,A,B combo works fine. But the 2,A,B does not. (The B file not found!) And the thing that goes wrong is when A is to include B with ../B.php it ignores the ../ and just looks in the current directory of A. After some more testing I found that 1 including 2 including A would result in the same error with the file not being found because it searches in the wrong directory. So this is similar to the PHP4 error of included files searching from their parents directory instead of their own when trying to further include files, but this only happens when an ../ is involved. If I put ../../B.php in A then it works in 2, but then 1 tries to go back one directory to much, which it should because that's what's written. Also /B.php or ./B.php seem to work for 2, but messes things up for 1. -- Edit this bug report at http://bugs.php.net/bug.php?id=52838&edit=1
[PHP-BUG] Bug #52838 [NEW]: include/require problems with ../
From: Operating system: WinXP maybe others PHP version: 5.3.3 Package: *Directory/Filesystem functions Bug Type: Bug Bug description:include/require problems with ../ Description: So here is the layout of my files: B.php page/1.php page/A.php page/mod/2.php 1 and 2 are pages that are used independently. A and B are included files with classes and functions. 1 includes A which includes B 2 includes A which includes B This affects the include,include_once,require and require_once functions. Found this in the 5.2.3 so I upgraded to 5.3.3 and it's still there. I have WinXP Pro SP3 and use Apache 2.2.4 --- I have come up with a workaround for my site, which is to remove B from A and include B in 1 and 2 and all the other filers in the page/mod/ directory, but that is just a pain when it shouldn't work like this! Right? Expected result: Well I expected both 1 and 2 to work. I should not have to take in to account where the file that includes my file lies, so 1 and 2 should get the same results. Actual result: -- The 1,A,B combo works fine. But the 2,A,B does not. (The B file not found!) And the thing that goes wrong is when A is to include B with ../B.php it ignores the ../ and just looks in the current directory of A. After some more testing I found that 1 including 2 including A would result in the same error with the file not being found because it searches in the wrong directory. So this is similar to the PHP4 error of included files searching from their parents directory instead of their own when trying to further include files, but this only happens when an ../ is involved. If I put ../../B.php in A then it works in 2, but then 1 tries to go back one directory to much, which it should because that's what's written. Also /B.php or ./B.php seem to work for 2, but messes things up for 1. -- Edit bug report at http://bugs.php.net/bug.php?id=52838&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52838&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52838&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52838&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52838&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52838&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52838&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52838&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52838&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52838&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52838&r=support Expected behavior: http://bugs.php.net/fix.php?id=52838&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52838&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52838&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52838&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52838&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52838&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52838&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52838&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52838&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52838&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52838&r=mysqlcfg
php-bugs@lists.php.net
Edit report at http://bugs.php.net/bug.php?id=52837&edit=1 ID: 52837 Updated by: ahar...@php.net Reported by:frankyue1019 at gmail dot com Summary:function implode can't do well with character '&' -Status: Open +Status: Bogus Type: Bug Package:Strings related Operating System: ubuntu 10.04 PHP Version:5.2SVN-2010-09-14 (SVN) Block user comment: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2010-09-14 11:09:13] frankyue1019 at gmail dot com Description: Expected result: web should print this: 20lastname&email&phone Actual result: -- web just print this: 20lastname&email -- Edit this bug report at http://bugs.php.net/bug.php?id=52837&edit=1
php-bugs@lists.php.net
From: Operating system: ubuntu 10.04 PHP version: 5.2SVN-2010-09-14 (SVN) Package: Strings related Bug Type: Bug Bug description:function implode can't do well with character '&' Description: Expected result: web should print this: 20lastname&email&phone Actual result: -- web just print this: 20lastname&email -- Edit bug report at http://bugs.php.net/bug.php?id=52837&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52837&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52837&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52837&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52837&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52837&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52837&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52837&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52837&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52837&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52837&r=support Expected behavior: http://bugs.php.net/fix.php?id=52837&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52837&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52837&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52837&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52837&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52837&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52837&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52837&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52837&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52837&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52837&r=mysqlcfg
Bug #43410 [NoF->Fbk]: SNMP cause "PHP has encountered an Access Violation" when wrong IP or CommStr
Edit report at http://bugs.php.net/bug.php?id=43410&edit=1 ID: 43410 Updated by: paj...@php.net Reported by:andy_wolk at mail dot ru Summary:SNMP cause "PHP has encountered an Access Violation" when wrong IP or CommStr -Status: No Feedback +Status: Feedback Type: Bug Package:SNMP related Operating System: Windows 2003 Server Enterprise PHP Version:5.2.5 Block user comment: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2010-09-14 08:29:50] andy_wolk at mail dot ru Still got the problem. We use the latest 5.2.x version as isapi. But no luck. I think we are not alone. Check this out (a post from Mar 2010)http://stackoverflow.com/questions/154290/php-access-violation/2482839#2482839 [2008-10-29 01:00:01] 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". [2008-10-21 12:06:43] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Do not paste such huge texts here. Put them somewhere in net (like http://phpfi.com/) where we can check them out. [2007-11-26 11:50:45] andy_wolk at mail dot ru Description: SNMP functions cause "PHP has encountered an Access Violation" when wrong IP or Community String. IIS 6 + PHP5.2.2dev isapi module. PHP_snmp.dll (ver 5.2.2.2) All next php versions has the same problem. After this error, IIS does not can operate with snmp module and needs to be restarted. Event viewer: Faulting application w3wp.exe, version 6.0.3790.3959, faulting module unknown, version 0.0.0.0, fault address 0x010cfdf4. No errors in php_error.log Reproduce code: --- Expected result: Start...Finish Actual result: -- Start...PHP has encountered an Access Violation at -- Edit this bug report at http://bugs.php.net/bug.php?id=43410&edit=1
Bug #52836 [Opn->Fbk]: iconv //TRANSLIT property not functioning as it should
Edit report at http://bugs.php.net/bug.php?id=52836&edit=1 ID: 52836 Updated by: ahar...@php.net Reported by:danny at studyportals dot eu Summary:iconv //TRANSLIT property not functioning as it should -Status: Open +Status: Feedback Type: Bug Package:Unknown/Other Function Operating System: Windows 7 PHP Version:5.3.3 Block user comment: N New Comment: Are you sure your PHP script is saved as UTF-8? This works as expected for me when it is, but fails similarly to your example when the PHP script is in a single-byte encoding where ⬠is an invalid UTF-8 string, such as ISO-8859-15. Previous Comments: [2010-09-14 10:41:01] danny at studyportals dot eu Description: This bug was discovered in libiconv 1.11 The //TRANSLIT property seems to be discarded. While passing this property and encountering characters as ⬠it handles as if you used the plain variant on it. See test case below, this is the example given in the PHP docs (http://php.net/manual/en/function.iconv.php) Test script: --- Expected result: Original : This is the Euro symbol 'â¬'. TRANSLIT : This is the Euro symbol 'EUR'. IGNORE : This is the Euro symbol ''. Plain: Notice: iconv(): Detected an illegal character in input string in .\iconv- example.php on line 7 This is the Euro symbol ' (Example on http://php.net/manual/en/function.iconv.php) Actual result: -- Original : This is the Euro symbol 'â¬'. TRANSLIT : Notice: iconv(): Detected an illegal character in input string in D:\Web\Webroot\test.php on line 6 This is the Euro symbol ' IGNORE : This is the Euro symbol ''. Plain : Notice: iconv(): Detected an illegal character in input string in D:\Web\Webroot\test.php on line 8 This is the Euro symbol ' -- Edit this bug report at http://bugs.php.net/bug.php?id=52836&edit=1
[PHP-BUG] Bug #52836 [NEW]: iconv //TRANSLIT property not functioning as it should
From: Operating system: Windows 7 PHP version: 5.3.3 Package: Unknown/Other Function Bug Type: Bug Bug description:iconv //TRANSLIT property not functioning as it should Description: This bug was discovered in libiconv 1.11 The //TRANSLIT property seems to be discarded. While passing this property and encountering characters as ⬠it handles as if you used the plain variant on it. See test case below, this is the example given in the PHP docs (http://php.net/manual/en/function.iconv.php) Test script: --- Expected result: Original : This is the Euro symbol 'â¬'. TRANSLIT : This is the Euro symbol 'EUR'. IGNORE : This is the Euro symbol ''. Plain: Notice: iconv(): Detected an illegal character in input string in .\iconv- example.php on line 7 This is the Euro symbol ' (Example on http://php.net/manual/en/function.iconv.php) Actual result: -- Original : This is the Euro symbol 'â¬'. TRANSLIT : Notice: iconv(): Detected an illegal character in input string in D:\Web\Webroot\test.php on line 6 This is the Euro symbol ' IGNORE : This is the Euro symbol ''. Plain : Notice: iconv(): Detected an illegal character in input string in D:\Web\Webroot\test.php on line 8 This is the Euro symbol ' -- Edit bug report at http://bugs.php.net/bug.php?id=52836&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52836&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52836&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52836&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52836&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52836&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52836&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52836&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52836&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52836&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52836&r=support Expected behavior: http://bugs.php.net/fix.php?id=52836&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52836&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52836&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52836&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52836&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52836&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52836&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52836&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52836&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52836&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52836&r=mysqlcfg
Bug #52741 [Asn->Opn]: OOP late static bindings bug
Edit report at http://bugs.php.net/bug.php?id=52741&edit=1
ID: 52741
Updated by: col...@php.net
Reported by:flyguy dot by at gmail dot com
Summary:OOP late static bindings bug
-Status: Assigned
+Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3.3
Assigned To:colder
Block user comment: N
New Comment:
You are dealing here with static properties (assigned to a class) and
resolution
fallbacks (reference to an undefined property in one class)
my_child::$blabla will fallback to the parent property, since strictly
speaking
no static property named "$blabla" exists in my_child. It will thus
reference
my_parent::$blabla.
No bug here.
Previous Comments:
[2010-09-13 23:01:24] flyguy dot by at gmail dot com
Sory, my English is very bad :))
[2010-09-13 22:46:23] flyguy dot by at gmail dot com
class my_parent {
public static $blabla='asd';
public static function set_blabla($val) {
static::$blabla=$val;
}
}
class my_child extends my_parent {
}
my_child::set_blabla('qwerty');
var_dump(my_child::$blabla);
var_dump(my_parent::$blabla);
prints:
string 'qwerty' (length=6)
string 'qwerty' (length=6)
This is normal code too ?
Why changed extended propety on parent ?
By your logic inherited properties are not inherited properties.
Simply class-parent becomes part of the subclass.
[2010-09-13 21:42:17] col...@php.net
parent:: forwards LSB information
In the initial case, it makes it perfectly normal for get_called_class
to return
test2, this is by design, if you don't want to pass the LSB info,
reference your
class by name, without keyword (i.e. test1::testing_method()).
---
Johannes:
on test3::testingmethod():
- parent::testing_method() will call parent (here test2), passing LSB
info
(test3)
- test2::testing_method falls back to test1::method, passing LSB info
test1::testing_method's get_called_class will be test3.
To me it sounds perfectly normal?
---
For the last comment:
static::$field is resolved to once my_child::$field and once
my_parent::$field,
my_child::$field falls back to my_parent::$field, and updates it.
=> normal again
Am I missing something here?
[2010-09-13 00:13:13] flyguy dot by at gmail dot com
Ok. This situation is analogous to the one hand, but why then:
class my_parent {
public static $field;
public static function field_setup() {
static::$field='asd';
}
}
class my_child extends my_parent {
}
my_child::field_setup();
var_dump(my_child::$field);
var_dump(my_parent::$field);
--
prints:
string 'asd' (length=3)
string 'asd' (length=3)
[2010-08-30 18:35:08] johan...@php.net
Etienne, you are the LSB expert - what's your take on this? - In the
given example I can see the reporter's point. (While there is a "extends
test1" missing)
I wonder about this:
class test1 {
public static function testing_method() {
var_dump(get_called_class());
}
}
class test2 extends test1 {
}
class test3 extends test2 {
public static function testing_method() {
parent::testing_method();
}
}
Here parent might refer to test2, test2 inherits testing_method() from
test1 so the called class might be test2 ... some might argue that test1
is correct.
I think the most simple thing is to keep the current behavior and define
parent not to change the lsb scope.
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=52741
--
Edit this bug report at http://bugs.php.net/bug.php?id=52741&edit=1
