Bug #52891 [Opn->Asn]: Wrong data inserted with mysqli/mysqlnd when using bind_param,value>LONG_MAX
Edit report at http://bugs.php.net/bug.php?id=52891&edit=1
ID: 52891
Updated by: and...@php.net
Reported by:and...@php.net
Summary:Wrong data inserted with mysqli/mysqlnd when using
bind_param,value>LONG_MAX
-Status: Open
+Status: Assigned
Type: Bug
Package:MySQLi related
Operating System: All
PHP Version:5.3SVN-2010-09-20 (SVN)
-Assigned To:
+Assigned To:mysql
Block user comment: N
Previous Comments:
[2010-09-20 08:56:45] and...@php.net
Description:
LONG_MAX is differs from platform to platform.
Because zval internally uses a signed long for integer fields when the
value in the script is over LONG_MAX, or under -LONG_MAX-1 then the
value is fit into a double. When using mysqli_stmt_bind_param with such
a value and "i" modifier then the value is converted back to long, which
results in incorrect results - like if the VALUE was LONG_MAX+1 the
result will be -1 (internally it is a signed long).
Test script:
---
CREATE TABLE tint(a bigint unsigned);
./php -r
'$c=mysqli_connect("127.0.0.1","root","root","test");$s=$c->prepare("insert
into tint
values(?)");$param=4294967295;$s->bind_param("i",$param);var_dump($s->execute());'
bool(true)
Expected result:
Don't bork the data. Check if the value can't be fit into a long, and if
this is the case use string to send to the server (changing the modifier
to "s" just for the next execution, preserve "i" for further
executions).
Actual result:
--
-1
--
Edit this bug report at http://bugs.php.net/bug.php?id=52891&edit=1
[PHP-BUG] Bug #52891 [NEW]: Wrong data inserted with mysqli/mysqlnd when using bind_param,value>LONG_MAX
From:
Operating system: All
PHP version: 5.3SVN-2010-09-20 (SVN)
Package: MySQLi related
Bug Type: Bug
Bug description:Wrong data inserted with mysqli/mysqlnd when using
bind_param,value>LONG_MAX
Description:
LONG_MAX is differs from platform to platform.
Because zval internally uses a signed long for integer fields when the
value in the script is over LONG_MAX, or under -LONG_MAX-1 then the value
is fit into a double. When using mysqli_stmt_bind_param with such a value
and "i" modifier then the value is converted back to long, which results in
incorrect results - like if the VALUE was LONG_MAX+1 the result will be -1
(internally it is a signed long).
Test script:
---
CREATE TABLE tint(a bigint unsigned);
./php -r
'$c=mysqli_connect("127.0.0.1","root","root","test");$s=$c->prepare("insert
into tint
values(?)");$param=4294967295;$s->bind_param("i",$param);var_dump($s->execute());'
bool(true)
Expected result:
Don't bork the data. Check if the value can't be fit into a long, and if
this is the case use string to send to the server (changing the modifier to
"s" just for the next execution, preserve "i" for further executions).
Actual result:
--
-1
--
Edit bug report at http://bugs.php.net/bug.php?id=52891&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52891&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52891&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52891&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52891&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52891&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52891&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52891&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52891&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52891&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52891&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52891&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52891&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52891&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52891&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52891&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52891&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52891&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52891&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52891&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52891&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52891&r=mysqlcfg
Bug #50916 [Dup]: DateTime::sub repeats each time getTimestamp is called
Edit report at http://bugs.php.net/bug.php?id=50916&edit=1
ID: 50916
Updated by: ras...@php.net
Reported by:charlesb at itsmystuff dot com
Summary:DateTime::sub repeats each time getTimestamp is
called
Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: Windows Server 2003 SP2
PHP Version:5.3.1
Block user comment: N
New Comment:
Sure, if you follow the links here you will see it was fixed in 5.3.3
which has
been out for 2 months now.
Previous Comments:
[2010-09-20 07:33:07] david dot wright at opticsplanet dot com
Problem is still alive and kicking under 5.3.2.
I had it happen repetition of prior sub() right after a call to
getTimeStamp().
Easily the most aggravating "not-my-bug-but-the-language-itself" I've
ever
encountered.
[2010-03-10 09:00:03] yoarvi at gmail dot com
The fix for http://bugs.php.net/bug.php?id=49059 fixes this problem as
well. I think this bug can be closed as a duplicate of 49059.
[2010-03-02 23:00:01] v-ryanbi at microsoft dot com
I've attached a patch that is tested on Windows, although the code that
needs to be changed appears to be universal. The patch also includes a
.phpt that compares the resulting timestamps.
The fix for this is a bit disconcerting for me, but as I'm not entirely
familiar with the codebase, I didn't want to muck things up too much.
Shouldn't the c function do_adjust_relative() in tm2unixtime.c be the
one to clear the flags it uses after it applies changes? If we're
clearing the flags in the calling functions, we're bound to miss more
stuff like this one.
[2010-02-20 10:28:40] pontus dot alexander at gmail dot com
This bug is confirmed to still be alive in snapshot "5.3-201002200930"
compiled on Debian Linux.
Reproduction code:
$Time = new \DateTime('NOW');
$Month = new \DateInterval('P1Y');
var_dump($Time);
// Correctly subtracted
$Time->sub($Month);
var_dump($Time);
// Wrongly subtracted
$Time->getTimestamp();
var_dump($Time);
[2010-02-02 18:04:23] charlesb at itsmystuff dot com
Description:
Each time DateTime::getTimestamp is called, a previously called
DateTime::sub value is applied. This does not occur with DateTime::add.
Reproduce code:
---
$work_time = new DateTime("2010-01-30 12:00:00");
$work_time->sub(new DateInterval("P7D"));
$window_start = $work_time->getTimestamp();
echo date("Y-m-d H:i:s", $window_start) . "";
$window_start = $work_time->getTimestamp();
echo date("Y-m-d H:i:s", $window_start) . "";
Expected result:
2010-01-23 12:00:00
2010-01-23 12:00:00
Actual result:
--
2010-01-16 12:00:00
2010-01-09 12:00:00
--
Edit this bug report at http://bugs.php.net/bug.php?id=50916&edit=1
Bug #50916 [Com]: DateTime::sub repeats each time getTimestamp is called
Edit report at http://bugs.php.net/bug.php?id=50916&edit=1
ID: 50916
Comment by: david dot wright at opticsplanet dot com
Reported by:charlesb at itsmystuff dot com
Summary:DateTime::sub repeats each time getTimestamp is
called
Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: Windows Server 2003 SP2
PHP Version:5.3.1
Block user comment: N
New Comment:
Problem is still alive and kicking under 5.3.2.
I had it happen repetition of prior sub() right after a call to
getTimeStamp().
Easily the most aggravating "not-my-bug-but-the-language-itself" I've
ever
encountered.
Previous Comments:
[2010-03-10 09:00:03] yoarvi at gmail dot com
The fix for http://bugs.php.net/bug.php?id=49059 fixes this problem as
well. I think this bug can be closed as a duplicate of 49059.
[2010-03-02 23:00:01] v-ryanbi at microsoft dot com
I've attached a patch that is tested on Windows, although the code that
needs to be changed appears to be universal. The patch also includes a
.phpt that compares the resulting timestamps.
The fix for this is a bit disconcerting for me, but as I'm not entirely
familiar with the codebase, I didn't want to muck things up too much.
Shouldn't the c function do_adjust_relative() in tm2unixtime.c be the
one to clear the flags it uses after it applies changes? If we're
clearing the flags in the calling functions, we're bound to miss more
stuff like this one.
[2010-02-20 10:28:40] pontus dot alexander at gmail dot com
This bug is confirmed to still be alive in snapshot "5.3-201002200930"
compiled on Debian Linux.
Reproduction code:
$Time = new \DateTime('NOW');
$Month = new \DateInterval('P1Y');
var_dump($Time);
// Correctly subtracted
$Time->sub($Month);
var_dump($Time);
// Wrongly subtracted
$Time->getTimestamp();
var_dump($Time);
[2010-02-02 18:04:23] charlesb at itsmystuff dot com
Description:
Each time DateTime::getTimestamp is called, a previously called
DateTime::sub value is applied. This does not occur with DateTime::add.
Reproduce code:
---
$work_time = new DateTime("2010-01-30 12:00:00");
$work_time->sub(new DateInterval("P7D"));
$window_start = $work_time->getTimestamp();
echo date("Y-m-d H:i:s", $window_start) . "";
$window_start = $work_time->getTimestamp();
echo date("Y-m-d H:i:s", $window_start) . "";
Expected result:
2010-01-23 12:00:00
2010-01-23 12:00:00
Actual result:
--
2010-01-16 12:00:00
2010-01-09 12:00:00
--
Edit this bug report at http://bugs.php.net/bug.php?id=50916&edit=1
[PHP-BUG] Bug #52890 [NEW]: Exception not caught sometimes
From:
Operating system: Linux
PHP version: 5.3.3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Exception not caught sometimes
Description:
An Exception thrown is not caught by the corresponding catch block, instead
the global exception handler is invoked. That only happens on one page
during a long selenium test case. The bug is reproduceable with the
selenium test script, but stripping the code to a small example does not
result in an error. Will will add the stripped version of the code which
does not fail, but show the code.
The System is a 64bit Zend Server 5.3 CE on CentOS 5.5. The same code on a
Zend Server 5.2 CE does not have this problem. The problem also occurred in
PHP 5.3.2
In the example script $defer should be set to true but instead of catching
the excepetion in that block the global exception handler is called.
A fix for this is currently to use bofre the throw:
if (version_compare(PHP_VERSION, '5.3.0', '>=') &&
version_compare(PHP_VERSION, '5.3.3', '<=')) {
set_exception_handler(create_function('$exception', 'return $exception
instanceof iwat_ui_controller_ObjectSaveDeferredException ? true :
userExceptionHandler($exception);'));
}
as the application behaves as expected, but that bug still exists.
Disabling all Zend modules has no effect
Test script:
---
try {
doSave();
} catch (iwat_ui_controller_ObjectSaveDeferredException $e) {
$defer = true;
} catch (IWATException $e) {
}
function doSave() {
throw new iwat_ui_controller_ObjectSaveDeferredException();
}
--
Edit bug report at http://bugs.php.net/bug.php?id=52890&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52890&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52890&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52890&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52890&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52890&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52890&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52890&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52890&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52890&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52890&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52890&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52890&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52890&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52890&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52890&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52890&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52890&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52890&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52890&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52890&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52890&r=mysqlcfg
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:
heis: yes, the behaviour changed in 5.3.0. I'm not saying it was a good
idea, I'm just saying you should complain on some other bug report,
preferably one that I'm not CC'ed on.
The correct way to pass reference arguments to functions via
call_user_func_array() hasn't changed, we've been doing it this way
since PHP 4. It's just that the impact of doing it the wrong way has
changed. Previously, the argument was silently converted to a value.
Now, a warning is shown and the function isn't called.
Previous Comments:
[2010-09-19 10:54:53] heis dot turtlemad at gmail dot com
Please note that the "user code" we are talking about was running as
expected until php5.3 was released; and that downgrading to 5.2 solves
the issue.
that means, that the way to pass arrays as references in function args
has
changed since the 5.3 release ?
[2010-09-15 02:23:34] tstarling at wikimedia dot org
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.
[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 ?
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 #52888 [Asn]: Zend MM shutdown crash
Edit report at http://bugs.php.net/bug.php?id=52888&edit=1 ID: 52888 Updated by: paj...@php.net Reported by:paj...@php.net Summary:Zend MM shutdown crash Status: Assigned Type: Bug Package:Reproducible crash Operating System: Windows-VC9-release PHP Version:trunk-SVN-2010-09-19 (SVN) -Assigned To:kalle +Assigned To:dmitry Block user comment: N New Comment: Other crash, same script, this one can happen in debug mode too. php5ts_debug.dll!zend_mm_shutdown(_zend_mm_heap * heap=0x02697d18, int full_shutdown=0, int silent=0, void * * * tsrm_ls=0x02513da8) Line 1683 + 0x6 bytes C php5ts_debug.dll!shutdown_memory_manager(int silent=0, int full_shutdown=0, void * * * tsrm_ls=0x02513da8) Line 2586 + 0x23 bytes C php5ts_debug.dll!php_request_shutdown(void * dummy=0x) Line 1689 + 0x4a bytes C php.exe!main(int argc=3, char * * argv=0x02513c90) Line 1438 + 0xa bytes C php.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C php.exe!mainCRTStartup() Line 403 C Previous Comments: [2010-09-20 01:59:27] ka...@php.net Added a simple patch that fixes the crash and re-assigned to me [2010-09-20 01:58:48] ka...@php.net The following patch has been added/updated: Patch Name: ze2-bug-52888 Revision: 1284940727 URL: http://bugs.php.net/patch-display.php?bug=52888&patch=ze2-bug-52888&revision=1284940727 [2010-09-19 14:30:48] paj...@php.net Description: The segments_list test seems to do not be thread safe. But it could come from something else. The crash happens after the end of the script, on shutdown. php5ts.dll!zend_mm_shutdown(_zend_mm_heap * heap=0x024a7a00, int full_shutdown=0, int silent=0, void * * * tsrm_ls=0x001d1bb8) Line 1570C php5ts.dll!shutdown_memory_manager(int silent=0, int full_shutdown=0, void * * * tsrm_ls=0x001d1bb8) Line 2583 + 0x23 bytes C php5ts.dll!php_request_shutdown(void * dummy=0x) Line 1689 + 0x2d bytes C php.exe!main(int argc=5, char * * argv=0x001d1b10) Line 1438 + 0x8 bytes C php.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C Test script: --- Zend/bench.php -- Edit this bug report at http://bugs.php.net/bug.php?id=52888&edit=1
Bug #48634 [Opn->Fbk]: Calling ob_get_flush() inside an output handler causes crashes
Edit report at http://bugs.php.net/bug.php?id=48634&edit=1 ID: 48634 Updated by: ka...@php.net Reported by:gwy...@php.net Summary:Calling ob_get_flush() inside an output handler causes crashes -Status: Open +Status: Feedback Type: Bug Package:Reproducible crash Operating System: Darwin9 (MacOS X 10.5) PHP Version:5.* (2009-07-25) Block user comment: N Previous Comments: [2010-09-20 02:17:39] ka...@php.net Wasn't this fixed with the backport of the ob handling API in trunk? [2009-07-21 12:04:22] gwy...@php.net Correction: This does NOT happen in HEAD. [2009-07-18 01:42:45] gwy...@php.net Yes, it happens in all three branches. [2009-07-17 17:40:04] j...@php.net Does this happen with PHP_5_2 and/or HEAD? (if so, update the version properly) [2009-06-22 00:34:03] gwy...@php.net Description: The subject kind of says most of it. Under both GDB and Valgrind, PHP enters a massive recursion until it finally crashes by overrunning the stack, which is expected, according to a comment in a test that a fix needs to be backported from HEAD. So this bug is mostly about "please backport this fix", I suppose. Reproduce code: --- See tests/output/ob_11.phpt Expected result: A fatal error saying "you can't do that". Actual result: -- Endless recursion. -- Edit this bug report at http://bugs.php.net/bug.php?id=48634&edit=1
Bug #48634 [Opn]: Calling ob_get_flush() inside an output handler causes crashes
Edit report at http://bugs.php.net/bug.php?id=48634&edit=1 ID: 48634 Updated by: ka...@php.net Reported by:gwy...@php.net Summary:Calling ob_get_flush() inside an output handler causes crashes Status: Open Type: Bug Package:Reproducible crash Operating System: Darwin9 (MacOS X 10.5) PHP Version:5.* (2009-07-25) Block user comment: N New Comment: Wasn't this fixed with the backport of the ob handling API in trunk? Previous Comments: [2009-07-21 12:04:22] gwy...@php.net Correction: This does NOT happen in HEAD. [2009-07-18 01:42:45] gwy...@php.net Yes, it happens in all three branches. [2009-07-17 17:40:04] j...@php.net Does this happen with PHP_5_2 and/or HEAD? (if so, update the version properly) [2009-06-22 00:34:03] gwy...@php.net Description: The subject kind of says most of it. Under both GDB and Valgrind, PHP enters a massive recursion until it finally crashes by overrunning the stack, which is expected, according to a comment in a test that a fix needs to be backported from HEAD. So this bug is mostly about "please backport this fix", I suppose. Reproduce code: --- See tests/output/ob_11.phpt Expected result: A fatal error saying "you can't do that". Actual result: -- Endless recursion. -- Edit this bug report at http://bugs.php.net/bug.php?id=48634&edit=1
Req #52832 [Asn->Csd]: 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: Assigned +Status: Closed Type: Feature/Change Request Package:Performance problem Operating System: Linux PHP Version:5.3.3 Assigned To:kalle Block user comment: N Previous Comments: [2010-09-18 18:09:45] ka...@php.net Implemented in trunk, thanks for your work. [2010-09-15 04:46:59] ka...@php.net 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. [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 #52888 [Asn]: Zend MM shutdown crash
Edit report at http://bugs.php.net/bug.php?id=52888&edit=1 ID: 52888 Updated by: ka...@php.net Reported by:paj...@php.net Summary:Zend MM shutdown crash Status: Assigned Type: Bug Package:Reproducible crash Operating System: Windows-VC9-release PHP Version:trunk-SVN-2010-09-19 (SVN) -Assigned To:dmitry +Assigned To:Kalle Block user comment: N New Comment: Added a simple patch that fixes the crash and re-assigned to me Previous Comments: [2010-09-20 01:58:48] ka...@php.net The following patch has been added/updated: Patch Name: ze2-bug-52888 Revision: 1284940727 URL: http://bugs.php.net/patch-display.php?bug=52888&patch=ze2-bug-52888&revision=1284940727 [2010-09-19 14:30:48] paj...@php.net Description: The segments_list test seems to do not be thread safe. But it could come from something else. The crash happens after the end of the script, on shutdown. php5ts.dll!zend_mm_shutdown(_zend_mm_heap * heap=0x024a7a00, int full_shutdown=0, int silent=0, void * * * tsrm_ls=0x001d1bb8) Line 1570C php5ts.dll!shutdown_memory_manager(int silent=0, int full_shutdown=0, void * * * tsrm_ls=0x001d1bb8) Line 2583 + 0x23 bytes C php5ts.dll!php_request_shutdown(void * dummy=0x) Line 1689 + 0x2d bytes C php.exe!main(int argc=5, char * * argv=0x001d1b10) Line 1438 + 0x8 bytes C php.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C Test script: --- Zend/bench.php -- Edit this bug report at http://bugs.php.net/bug.php?id=52888&edit=1
Bug #52888 [PATCH]: Zend MM shutdown crash
Edit report at http://bugs.php.net/bug.php?id=52888&edit=1 ID: 52888 Patch added by: ka...@php.net Reported by:paj...@php.net Summary:Zend MM shutdown crash Status: Assigned Type: Bug Package:Reproducible crash Operating System: Windows-VC9-release PHP Version:trunk-SVN-2010-09-19 (SVN) Assigned To:dmitry Block user comment: N New Comment: The following patch has been added/updated: Patch Name: ze2-bug-52888 Revision: 1284940727 URL: http://bugs.php.net/patch-display.php?bug=52888&patch=ze2-bug-52888&revision=1284940727 Previous Comments: [2010-09-19 14:30:48] paj...@php.net Description: The segments_list test seems to do not be thread safe. But it could come from something else. The crash happens after the end of the script, on shutdown. php5ts.dll!zend_mm_shutdown(_zend_mm_heap * heap=0x024a7a00, int full_shutdown=0, int silent=0, void * * * tsrm_ls=0x001d1bb8) Line 1570C php5ts.dll!shutdown_memory_manager(int silent=0, int full_shutdown=0, void * * * tsrm_ls=0x001d1bb8) Line 2583 + 0x23 bytes C php5ts.dll!php_request_shutdown(void * dummy=0x) Line 1689 + 0x2d bytes C php.exe!main(int argc=5, char * * argv=0x001d1b10) Line 1438 + 0x8 bytes C php.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C Test script: --- Zend/bench.php -- Edit this bug report at http://bugs.php.net/bug.php?id=52888&edit=1
[PHP-BUG] Bug #52889 [NEW]: Getting a SimpleXMLElement tree with differents objects as nodes
From:
Operating system:
PHP version: Irrelevant
Package: SimpleXML related
Bug Type: Bug
Bug description:Getting a SimpleXMLElement tree with differents objects as nodes
Description:
Now, it is not possible to get different objects that inherit from
SimpleXMLElement as nodes of the SimpleXML tree. We get a warning with the
message "It is not yet possible to assign complex types to properties", but
it is not a complex types: it is a child of SimpleXMLElement. Maybe, we can
avoid the warning of assigning unknown object if this object inherits from
SimpleXMLElement? It could save a lot of time for interpreting a SimpleXML
tree.
Test script:
---
' . "\n" .
'' . "\n" .
' ' . "\n" .
'baz' . "\n" .
' ' . "\n" .
' ' . "\n" .
'qux' . "\n" .
' ' . "\n" .
'';
class A extends SimpleXMLElement { }
class B extends SimpleXMLElement { }
$sxe = simplexml_load_string($xml, 'A');
$sxe->foo[0] = simplexml_import_dom(
dom_import_simplexml($sxe->foo[0]),
'B'
);
print_r($sxe);
Expected result:
A Object
(
[foo] => Array
(
[0] => ___B___ Object
(
[bar] => baz
)
[1] => A Object
(
[bar] => qux
)
)
)
Actual result:
--
Warning: It is not yet possible to assign complex types to properties in
... on line 18
A Object
(
[foo] => Array
(
[0] => A Object
(
[bar] => baz
)
[1] => A Object
(
[bar] => qux
)
)
)
--
Edit bug report at http://bugs.php.net/bug.php?id=52889&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52889&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52889&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52889&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52889&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52889&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52889&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52889&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52889&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52889&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52889&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52889&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52889&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52889&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52889&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52889&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52889&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52889&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52889&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52889&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52889&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52889&r=mysqlcfg
Bug #52887 [Opn->Fbk]: socket_recv MSG_PEEK bug
Edit report at http://bugs.php.net/bug.php?id=52887&edit=1 ID: 52887 Updated by: cataphr...@php.net Reported by:bitset at ya dot ru Summary:socket_recv MSG_PEEK bug -Status: Open +Status: Feedback Type: Bug Package:Sockets related Operating System: Debian Linux PHP Version:5.3.3 Block user comment: N New Comment: I'm not sure what the problem is here. Did it return 0 or not? What were you expecting it to return? Can you provide a complete yet short script that exemplifies the problem, together with its expected and actual output? Previous Comments: [2010-09-19 09:24:46] bitset at ya dot ru Description: if TCP-buffer is empty then function socket_recv(.., MSG_PEEK) can't returned zero example: $buf = ""; $n = socket_recv($icq->socket, $buf, 125, MSG_PEEK ); Expected result: if TCP-buffer is empty then function socket_recv(.., MSG_PEEK) must returned zero -- Edit this bug report at http://bugs.php.net/bug.php?id=52887&edit=1
Req #52868 [Opn->Bgs]: string variable array acces with string index should emit E_NOTICE
Edit report at http://bugs.php.net/bug.php?id=52868&edit=1 ID: 52868 Updated by: markskilb...@php.net Reported by:sht dot alien at gmx dot net Summary:string variable array acces with string index should emit E_NOTICE -Status: Open +Status: Bogus Type: Feature/Change Request Package:Variables related Operating System: Ubuntu Linux 10.04 x64 PHP Version:5.3.3 Block user comment: N New Comment: I don't see that this makes sense. PHP expects an integer for the key, and PHP being PHP, it will just juggle the type if it can. The PHP Way(tm). Previous Comments: [2010-09-17 11:56:20] sht dot alien at gmx dot net Description: It sometimes happens that you accidentially acces a string via array access and be so unfortunate to have used a string index :-) Since I see no point in using stingindexes for accessing strings via array access at any time, I propose to issue an E_NOTICE when a string index is cast to integer for array access (on strings), if that is possible. Test script: --- Expected result: f b f -- Edit this bug report at http://bugs.php.net/bug.php?id=52868&edit=1
Bug #52888 [Opn->Asn]: Zend MM shutdown crash
Edit report at http://bugs.php.net/bug.php?id=52888&edit=1 ID: 52888 Updated by: paj...@php.net Reported by:paj...@php.net Summary:Zend MM shutdown crash -Status: Open +Status: Assigned Type: Bug Package:Reproducible crash Operating System: Windows-VC9-release PHP Version:trunk-SVN-2010-09-19 (SVN) -Assigned To: +Assigned To:dmitry Block user comment: N Previous Comments: [2010-09-19 14:30:48] paj...@php.net Description: The segments_list test seems to do not be thread safe. But it could come from something else. The crash happens after the end of the script, on shutdown. php5ts.dll!zend_mm_shutdown(_zend_mm_heap * heap=0x024a7a00, int full_shutdown=0, int silent=0, void * * * tsrm_ls=0x001d1bb8) Line 1570C php5ts.dll!shutdown_memory_manager(int silent=0, int full_shutdown=0, void * * * tsrm_ls=0x001d1bb8) Line 2583 + 0x23 bytes C php5ts.dll!php_request_shutdown(void * dummy=0x) Line 1689 + 0x2d bytes C php.exe!main(int argc=5, char * * argv=0x001d1b10) Line 1438 + 0x8 bytes C php.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C Test script: --- Zend/bench.php -- Edit this bug report at http://bugs.php.net/bug.php?id=52888&edit=1
[PHP-BUG] Bug #52888 [NEW]: Zend MM shutdown crash
From: pajoye Operating system: Windows-VC9-release PHP version: trunk-SVN-2010-09-19 (SVN) Package: Reproducible crash Bug Type: Bug Bug description:Zend MM shutdown crash Description: The segments_list test seems to do not be thread safe. But it could come from something else. The crash happens after the end of the script, on shutdown. php5ts.dll!zend_mm_shutdown(_zend_mm_heap * heap=0x024a7a00, int full_shutdown=0, int silent=0, void * * * tsrm_ls=0x001d1bb8) Line 1570 C php5ts.dll!shutdown_memory_manager(int silent=0, int full_shutdown=0, void * * * tsrm_ls=0x001d1bb8) Line 2583 + 0x23 bytes C php5ts.dll!php_request_shutdown(void * dummy=0x) Line 1689 + 0x2d bytes C php.exe!main(int argc=5, char * * argv=0x001d1b10) Line 1438 + 0x8 bytes C php.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C Test script: --- Zend/bench.php -- Edit bug report at http://bugs.php.net/bug.php?id=52888&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52888&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52888&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52888&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52888&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52888&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52888&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52888&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52888&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52888&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52888&r=support Expected behavior: http://bugs.php.net/fix.php?id=52888&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52888&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52888&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52888&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52888&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52888&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52888&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52888&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52888&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52888&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52888&r=mysqlcfg
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: heis dot turtlemad at gmail 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:
Please note that the "user code" we are talking about was running as
expected until php5.3 was released; and that downgrading to 5.2 solves
the issue.
that means, that the way to pass arrays as references in function args
has
changed since the 5.3 release ?
Previous Comments:
[2010-09-15 02:23:34] tstarling at wikimedia dot org
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.
[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.
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
[PHP-BUG] Bug #52887 [NEW]: socket_recv MSG_PEEK bug
From: Operating system: Debian Linux PHP version: 5.3.3 Package: Sockets related Bug Type: Bug Bug description:socket_recv MSG_PEEK bug Description: if TCP-buffer is empty then function socket_recv(.., MSG_PEEK) can't returned zero example: $buf = ""; $n = socket_recv($icq->socket, $buf, 125, MSG_PEEK ); Expected result: if TCP-buffer is empty then function socket_recv(.., MSG_PEEK) must returned zero -- Edit bug report at http://bugs.php.net/bug.php?id=52887&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52887&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52887&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52887&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52887&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52887&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52887&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52887&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52887&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52887&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52887&r=support Expected behavior: http://bugs.php.net/fix.php?id=52887&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52887&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52887&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52887&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52887&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52887&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52887&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52887&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52887&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52887&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52887&r=mysqlcfg
