[PHP-BUG] Bug #64935 [NEW]: Huge memory usage on unknown Content-Type
From: julien at palard dot fr
Operating system: GNU/Linux
PHP version: 5.4.15
Package: Performance problem
Bug Type: Bug
Bug description:Huge memory usage on unknown Content-Type
Description:
When a POST have an unknwon Content-Type, the php_default_post_reader store
the body of the request three times :
* In SG(request_info).post_data
* In SET_VAR_STRINGL("HTTP_RAW_POST_DATA", ...
* In SG(request_info).raw_post_data
So, getting a 500Mb request body result in a 1.5Gb memory usage, easily
triggering a "memory limit exhausted" error.
Known content types are found in main/php_content_types.c and are
"application/x-www-form-urlencoded" and "multipart/form-data", so this case
is easily triggered.
This fact seems well known as we can read in main/php_content_types.c:59 :
/* for php://input stream:
some post handlers modify the content of request_info.post_data
so for now we need a copy for the php://input stream
in the long run post handlers should be changed to not touch
request_info.post_data for memory preservation reasons
*/
Solving this comment only fix 1/2 of the bug, keeping the body stored in
two different locations, but it's a first step.
I only open this ticket to track the history of this issue, I do not really
need it to be fixed.
--
Edit bug report at https://bugs.php.net/bug.php?id=64935&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64935&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64935&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64935&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64935&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64935&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64935&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64935&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64935&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64935&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64935&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64935&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64935&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64935&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64935&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64935&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64935&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64935&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64935&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64935&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64935&r=mysqlcfg
Bug #64463 [Com]: Segfault (For the moment, can't reproduce it)
Edit report at https://bugs.php.net/bug.php?id=64463&edit=1
ID: 64463
Comment by: julien at palard dot fr
Reported by:julien at palard dot fr
Summary:Segfault (For the moment, can't reproduce it)
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Debian 6.0.7
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
@laruence :
> could you please disable all these exts and try ?
As we are unable to reproduce the bug in a dev server, and only able to
reproduce it after a buch of traffic went to it, it's not an option to disable
modules in production.
But i have a hint : We do not use rar plugin for this request.
And another hint : Since I restarted php-fpm at 11h46 today (to test with
valgrind) it never segfaulted (previously we had almost 1 segfault / hour),
like if it's an APC cache "random bug" corrupting something at compile time.
So two solutions :
* As i though in the past, the bug takes times to come (users / requests /
time ...)
* The bug does not happen at every restart of PHP-FPM but take place at
bytecode-compiling time, murphy helping in not producing the bug when I want to
try, leading me to think that a fresh php-fpm does not segfault.
> I assume the segfault is caused by some out-bounder write
Same asumption here.
Previous Comments:
[2013-03-21 14:21:54] larue...@php.net
could you please disable all these exts and try ?
I assume the segfault is caused by some out-bounder write
--------
[2013-03-21 13:50:43] julien at palard dot fr
@laruence :
Yes, exactly : rar-3.0.1 mongo-1.3.5 APC-3.1.13
And PHP compiled from sources (5.4.13) with :
./configure --disable-all --prefix=/usr/local/php-5.4.13 --enable-fpm
--enable-ctype --enable-mbstring --enable-gd-native-ttf --enable-zip
--with-mcrypt --with-openssl --with-gd --with-jpeg-dir=/usr/lib
--with-freetype-dir --with-curl --with-pcre-regex --with-gettext --enable-pdo
--with-pdo-mysql=mysqlnd --with-iconv --enable-fileinfo --enable-filter
--enable-json --enable-session --enable-hash --enable-libxml --enable-dom
--enable-libxml --enable-simplexml --enable-bcmath
[2013-03-21 13:42:24] larue...@php.net
do you use any non-offcial php extension, includes the exts at PECL?
--------
[2013-03-21 10:21:21] julien at palard dot fr
Sometimes segfault occur in php_request_shutdown (57 times since a few days)
and sometimes in php_execute_script (32 times in the same timespan).
Here are two segfaults occuring during php_execute_script :
Program terminated with signal 11, Segmentation fault.
#0 _zend_mm_alloc_int (heap=0x143a330, size=72) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2016
2016ZEND_MM_CHECK_BLOCK_LINKAGE(best_fit);
(gdb) p best_fit
$1 = (zend_mm_free_block *) 0x1c7e050
(gdb) p *best_fit
$2 = {info = {_size = 7308604897320202088, _prev = 28263411883601481},
prev_free_block = 0x1c7e710, next_free_block = 0x143a728, parent =
0x687461703f2f6e75, child = {0x31243d, 0x59}}
core.php-fpm.11335
#0 _zend_mm_realloc_int (heap=0x143a330, p=0x1665e78, size=452) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2151
2151if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) p *next_block
Cannot access memory at address 0x656d616e75d9cdd0
--------
[2013-03-21 10:00:42] julien at palard dot fr
Good news of the day : We have collected some core dumps, and the URL producing
the segfault is always the same.
Bad news of the day : This URL does a lot of work, so it's not a "little
script".
Bad news of the day 2 : If we restart php-fpm, for a few minutes it will not
segfault, we have to let some users hit the server first, wait a bit, and it
will start to segfault.
Bad news of the day 3 : As we have to wait for traffic to see the segfault we
can't reproduce it under valgrind.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=64463
--
Edit this bug report at https://bugs.php.net/bug.php?id=64463&edit=1
Bug #64463 [Com]: Segfault (For the moment, can't reproduce it)
Edit report at https://bugs.php.net/bug.php?id=64463&edit=1
ID: 64463
Comment by: julien at palard dot fr
Reported by:julien at palard dot fr
Summary:Segfault (For the moment, can't reproduce it)
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Debian 6.0.7
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
@laruence :
Yes, exactly : rar-3.0.1 mongo-1.3.5 APC-3.1.13
And PHP compiled from sources (5.4.13) with :
./configure --disable-all --prefix=/usr/local/php-5.4.13 --enable-fpm
--enable-ctype --enable-mbstring --enable-gd-native-ttf --enable-zip
--with-mcrypt --with-openssl --with-gd --with-jpeg-dir=/usr/lib
--with-freetype-dir --with-curl --with-pcre-regex --with-gettext --enable-pdo
--with-pdo-mysql=mysqlnd --with-iconv --enable-fileinfo --enable-filter
--enable-json --enable-session --enable-hash --enable-libxml --enable-dom
--enable-libxml --enable-simplexml --enable-bcmath
Previous Comments:
[2013-03-21 13:42:24] larue...@php.net
do you use any non-offcial php extension, includes the exts at PECL?
[2013-03-21 10:21:21] julien at palard dot fr
Sometimes segfault occur in php_request_shutdown (57 times since a few days)
and sometimes in php_execute_script (32 times in the same timespan).
Here are two segfaults occuring during php_execute_script :
Program terminated with signal 11, Segmentation fault.
#0 _zend_mm_alloc_int (heap=0x143a330, size=72) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2016
2016ZEND_MM_CHECK_BLOCK_LINKAGE(best_fit);
(gdb) p best_fit
$1 = (zend_mm_free_block *) 0x1c7e050
(gdb) p *best_fit
$2 = {info = {_size = 7308604897320202088, _prev = 28263411883601481},
prev_free_block = 0x1c7e710, next_free_block = 0x143a728, parent =
0x687461703f2f6e75, child = {0x31243d, 0x59}}
core.php-fpm.11335
#0 _zend_mm_realloc_int (heap=0x143a330, p=0x1665e78, size=452) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2151
2151if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) p *next_block
Cannot access memory at address 0x656d616e75d9cdd0
[2013-03-21 10:00:42] julien at palard dot fr
Good news of the day : We have collected some core dumps, and the URL producing
the segfault is always the same.
Bad news of the day : This URL does a lot of work, so it's not a "little
script".
Bad news of the day 2 : If we restart php-fpm, for a few minutes it will not
segfault, we have to let some users hit the server first, wait a bit, and it
will start to segfault.
Bad news of the day 3 : As we have to wait for traffic to see the segfault we
can't reproduce it under valgrind.
----
[2013-03-21 09:43:20] julien at palard dot fr
No, sadly, for the moment we do not have any small script to reproduce it. It
happen some times in our production servers, but never in our development one,
so, for the moment, we can't try to reduce the script to a minimal test case...
[2013-03-20 19:12:58] ahar...@php.net
Do you have a small script that can reproduce this easily (even if it's just
0.018% of the time)?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=64463
--
Edit this bug report at https://bugs.php.net/bug.php?id=64463&edit=1
Bug #64463 [Com]: Segfault (For the moment, can't reproduce it)
Edit report at https://bugs.php.net/bug.php?id=64463&edit=1
ID: 64463
Comment by: julien at palard dot fr
Reported by:julien at palard dot fr
Summary:Segfault (For the moment, can't reproduce it)
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Debian 6.0.7
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
Sometimes segfault occur in php_request_shutdown (57 times since a few days)
and sometimes in php_execute_script (32 times in the same timespan).
Here are two segfaults occuring during php_execute_script :
Program terminated with signal 11, Segmentation fault.
#0 _zend_mm_alloc_int (heap=0x143a330, size=72) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2016
2016ZEND_MM_CHECK_BLOCK_LINKAGE(best_fit);
(gdb) p best_fit
$1 = (zend_mm_free_block *) 0x1c7e050
(gdb) p *best_fit
$2 = {info = {_size = 7308604897320202088, _prev = 28263411883601481},
prev_free_block = 0x1c7e710, next_free_block = 0x143a728, parent =
0x687461703f2f6e75, child = {0x31243d, 0x59}}
core.php-fpm.11335
#0 _zend_mm_realloc_int (heap=0x143a330, p=0x1665e78, size=452) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2151
2151if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) p *next_block
Cannot access memory at address 0x656d616e75d9cdd0
Previous Comments:
[2013-03-21 10:00:42] julien at palard dot fr
Good news of the day : We have collected some core dumps, and the URL producing
the segfault is always the same.
Bad news of the day : This URL does a lot of work, so it's not a "little
script".
Bad news of the day 2 : If we restart php-fpm, for a few minutes it will not
segfault, we have to let some users hit the server first, wait a bit, and it
will start to segfault.
Bad news of the day 3 : As we have to wait for traffic to see the segfault we
can't reproduce it under valgrind.
----
[2013-03-21 09:43:20] julien at palard dot fr
No, sadly, for the moment we do not have any small script to reproduce it. It
happen some times in our production servers, but never in our development one,
so, for the moment, we can't try to reduce the script to a minimal test case...
[2013-03-20 19:12:58] ahar...@php.net
Do you have a small script that can reproduce this easily (even if it's just
0.018% of the time)?
--------
[2013-03-20 14:54:59] julien at palard dot fr
Same segfault, other stacktrace, don't think it help a lot :
Program terminated with signal 11, Segmentation fault.
#0 _zend_mm_alloc_int (heap=0x143a330, size=82) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2016
2016ZEND_MM_CHECK_BLOCK_LINKAGE(best_fit);
(gdb) bt
#0 _zend_mm_alloc_int (heap=0x143a330, size=82) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2016
#1 0x00691791 in _zend_hash_quick_add_or_update (ht=0x1675e18,
arKey=0x7fc905b7fb50 "regexChar", nKeyLength=,
h=8246864001117707262, pData=0x1, nDataSize=8, pDest=0x7fc9207513a8, flag=1) at
/usr/src/php-5.4.13/Zend/zend_hash.c:330
#2 0x006a9948 in _get_zval_cv_lookup_BP_VAR_W (ptr=0x7fc9207513a8,
var=) at /usr/src/php-5.4.13/Zend/zend_execute.c:281
#3 0x0070557a in _get_zval_ptr_ptr_cv_BP_VAR_W
(execute_data=0x7fc9207512c8) at /usr/src/php-5.4.13/Zend/zend_execute.c:442
#4 ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (execute_data=0x7fc9207512c8) at
/usr/src/php-5.4.13/Zend/zend_vm_execute.h:33048
#5 0x006e8990 in execute (op_array=0x1a22840) at
/usr/src/php-5.4.13/Zend/zend_vm_execute.h:410
#6 0x00676473 in zend_call_function (fci=0x7fff3c616460,
fci_cache=) at
/usr/src/php-5.4.13/Zend/zend_execute_API.c:958
#7 0x0055bf1a in zim_reflection_method_invokeArgs (ht=, return_value=0x166df40, return_value_ptr=,
this_ptr=, return_value_used=)
at /usr/src/php-5.4.13/ext/reflection/php_reflection.c:3017
#8 0x006fb5dc in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fc92074d7f8) at /usr/src/php-5.4.13/Zend/zend_vm_execute.h:642
#9 0x006e8990 in execute (op_array=0x17b52b0) at
/usr/src/php-5.4.13/Zend/zend_vm_execute.h:410
#10 0x00681d9e in zend_execute_scripts (type=8, retval=, file_count=3) at /usr/src/php-5.4.13/Zend/zend.c:1315
#11 0x0062746e in php_execute_script (primary_file=) at /usr/src/php-5.4.13/main/main.c:2492
#12 0x00730fda in main (argc=, argv=) at /usr/src/php-5.4.13/sapi/fpm/fpm/fpm_main.c:1924
(gdb) list
2021
2022remaining_size = block_size - true_size;
2023
2024if (remaining_size < ZEND_MM_ALIGNED_MIN_HEADER_SIZ
Bug #64463 [Com]: Segfault (For the moment, can't reproduce it)
Edit report at https://bugs.php.net/bug.php?id=64463&edit=1
ID: 64463
Comment by: julien at palard dot fr
Reported by:julien at palard dot fr
Summary:Segfault (For the moment, can't reproduce it)
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Debian 6.0.7
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
Good news of the day : We have collected some core dumps, and the URL producing
the segfault is always the same.
Bad news of the day : This URL does a lot of work, so it's not a "little
script".
Bad news of the day 2 : If we restart php-fpm, for a few minutes it will not
segfault, we have to let some users hit the server first, wait a bit, and it
will start to segfault.
Bad news of the day 3 : As we have to wait for traffic to see the segfault we
can't reproduce it under valgrind.
Previous Comments:
----
[2013-03-21 09:43:20] julien at palard dot fr
No, sadly, for the moment we do not have any small script to reproduce it. It
happen some times in our production servers, but never in our development one,
so, for the moment, we can't try to reduce the script to a minimal test case...
[2013-03-20 19:12:58] ahar...@php.net
Do you have a small script that can reproduce this easily (even if it's just
0.018% of the time)?
--------
[2013-03-20 14:54:59] julien at palard dot fr
Same segfault, other stacktrace, don't think it help a lot :
Program terminated with signal 11, Segmentation fault.
#0 _zend_mm_alloc_int (heap=0x143a330, size=82) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2016
2016ZEND_MM_CHECK_BLOCK_LINKAGE(best_fit);
(gdb) bt
#0 _zend_mm_alloc_int (heap=0x143a330, size=82) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2016
#1 0x00691791 in _zend_hash_quick_add_or_update (ht=0x1675e18,
arKey=0x7fc905b7fb50 "regexChar", nKeyLength=,
h=8246864001117707262, pData=0x1, nDataSize=8, pDest=0x7fc9207513a8, flag=1) at
/usr/src/php-5.4.13/Zend/zend_hash.c:330
#2 0x006a9948 in _get_zval_cv_lookup_BP_VAR_W (ptr=0x7fc9207513a8,
var=) at /usr/src/php-5.4.13/Zend/zend_execute.c:281
#3 0x0070557a in _get_zval_ptr_ptr_cv_BP_VAR_W
(execute_data=0x7fc9207512c8) at /usr/src/php-5.4.13/Zend/zend_execute.c:442
#4 ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (execute_data=0x7fc9207512c8) at
/usr/src/php-5.4.13/Zend/zend_vm_execute.h:33048
#5 0x006e8990 in execute (op_array=0x1a22840) at
/usr/src/php-5.4.13/Zend/zend_vm_execute.h:410
#6 0x00676473 in zend_call_function (fci=0x7fff3c616460,
fci_cache=) at
/usr/src/php-5.4.13/Zend/zend_execute_API.c:958
#7 0x0055bf1a in zim_reflection_method_invokeArgs (ht=, return_value=0x166df40, return_value_ptr=,
this_ptr=, return_value_used=)
at /usr/src/php-5.4.13/ext/reflection/php_reflection.c:3017
#8 0x006fb5dc in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fc92074d7f8) at /usr/src/php-5.4.13/Zend/zend_vm_execute.h:642
#9 0x006e8990 in execute (op_array=0x17b52b0) at
/usr/src/php-5.4.13/Zend/zend_vm_execute.h:410
#10 0x00681d9e in zend_execute_scripts (type=8, retval=, file_count=3) at /usr/src/php-5.4.13/Zend/zend.c:1315
#11 0x0062746e in php_execute_script (primary_file=) at /usr/src/php-5.4.13/main/main.c:2492
#12 0x00730fda in main (argc=, argv=) at /usr/src/php-5.4.13/sapi/fpm/fpm/fpm_main.c:1924
(gdb) list
2021
2022remaining_size = block_size - true_size;
2023
2024if (remaining_size < ZEND_MM_ALIGNED_MIN_HEADER_SIZE) {
2025true_size = block_size;
2026ZEND_MM_BLOCK(best_fit, ZEND_MM_USED_BLOCK, true_size);
2027} else {
2028zend_mm_free_block *new_free_block;
2029
2030/* prepare new free block */
(gdb) p *best_fit->info._prev
Cannot access memory at address 0x64696c61766e49
Same as the last, seems ASCII data instead of memory pointer :
$ echo $'\x64\x69\x6c\x61\x76\x6e\x49'
dilavnI
----------------
[2013-03-20 14:44:59] julien at palard dot fr
Description:
I got a chance of 0.018% of segfaulting in my current setup, can't reproduce it
for the moment.
But I got a stacktrace ! :-)
gdb /usr/local/php-current/sbin/php-fpm ./core.php-fpm.9958
list
2105mm_block = ZEND_MM_PREV_BLOCK(mm_block);
2106zend_mm_remove_from_free_list(heap, (zend_mm_free_block
*) mm_block);
2107size += ZEND_MM_FREE_BLOCK_SIZE(mm_block);
2108}
2109if (ZEN
Bug #64463 [Com]: Segfault (For the moment, can't reproduce it)
Edit report at https://bugs.php.net/bug.php?id=64463&edit=1
ID: 64463
Comment by: julien at palard dot fr
Reported by:julien at palard dot fr
Summary:Segfault (For the moment, can't reproduce it)
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Debian 6.0.7
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
No, sadly, for the moment we do not have any small script to reproduce it. It
happen some times in our production servers, but never in our development one,
so, for the moment, we can't try to reduce the script to a minimal test case...
Previous Comments:
[2013-03-20 19:12:58] ahar...@php.net
Do you have a small script that can reproduce this easily (even if it's just
0.018% of the time)?
[2013-03-20 14:54:59] julien at palard dot fr
Same segfault, other stacktrace, don't think it help a lot :
Program terminated with signal 11, Segmentation fault.
#0 _zend_mm_alloc_int (heap=0x143a330, size=82) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2016
2016ZEND_MM_CHECK_BLOCK_LINKAGE(best_fit);
(gdb) bt
#0 _zend_mm_alloc_int (heap=0x143a330, size=82) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2016
#1 0x00691791 in _zend_hash_quick_add_or_update (ht=0x1675e18,
arKey=0x7fc905b7fb50 "regexChar", nKeyLength=,
h=8246864001117707262, pData=0x1, nDataSize=8, pDest=0x7fc9207513a8, flag=1) at
/usr/src/php-5.4.13/Zend/zend_hash.c:330
#2 0x006a9948 in _get_zval_cv_lookup_BP_VAR_W (ptr=0x7fc9207513a8,
var=) at /usr/src/php-5.4.13/Zend/zend_execute.c:281
#3 0x0070557a in _get_zval_ptr_ptr_cv_BP_VAR_W
(execute_data=0x7fc9207512c8) at /usr/src/php-5.4.13/Zend/zend_execute.c:442
#4 ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (execute_data=0x7fc9207512c8) at
/usr/src/php-5.4.13/Zend/zend_vm_execute.h:33048
#5 0x006e8990 in execute (op_array=0x1a22840) at
/usr/src/php-5.4.13/Zend/zend_vm_execute.h:410
#6 0x00676473 in zend_call_function (fci=0x7fff3c616460,
fci_cache=) at
/usr/src/php-5.4.13/Zend/zend_execute_API.c:958
#7 0x0055bf1a in zim_reflection_method_invokeArgs (ht=, return_value=0x166df40, return_value_ptr=,
this_ptr=, return_value_used=)
at /usr/src/php-5.4.13/ext/reflection/php_reflection.c:3017
#8 0x006fb5dc in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fc92074d7f8) at /usr/src/php-5.4.13/Zend/zend_vm_execute.h:642
#9 0x006e8990 in execute (op_array=0x17b52b0) at
/usr/src/php-5.4.13/Zend/zend_vm_execute.h:410
#10 0x00681d9e in zend_execute_scripts (type=8, retval=, file_count=3) at /usr/src/php-5.4.13/Zend/zend.c:1315
#11 0x0062746e in php_execute_script (primary_file=) at /usr/src/php-5.4.13/main/main.c:2492
#12 0x00730fda in main (argc=, argv=) at /usr/src/php-5.4.13/sapi/fpm/fpm/fpm_main.c:1924
(gdb) list
2021
2022remaining_size = block_size - true_size;
2023
2024if (remaining_size < ZEND_MM_ALIGNED_MIN_HEADER_SIZE) {
2025true_size = block_size;
2026ZEND_MM_BLOCK(best_fit, ZEND_MM_USED_BLOCK, true_size);
2027} else {
2028zend_mm_free_block *new_free_block;
2029
2030/* prepare new free block */
(gdb) p *best_fit->info._prev
Cannot access memory at address 0x64696c61766e49
Same as the last, seems ASCII data instead of memory pointer :
$ echo $'\x64\x69\x6c\x61\x76\x6e\x49'
dilavnI
----------------
[2013-03-20 14:44:59] julien at palard dot fr
Description:
I got a chance of 0.018% of segfaulting in my current setup, can't reproduce it
for the moment.
But I got a stacktrace ! :-)
gdb /usr/local/php-current/sbin/php-fpm ./core.php-fpm.9958
list
2105mm_block = ZEND_MM_PREV_BLOCK(mm_block);
2106zend_mm_remove_from_free_list(heap, (zend_mm_free_block
*) mm_block);
2107size += ZEND_MM_FREE_BLOCK_SIZE(mm_block);
2108}
2109if (ZEND_MM_IS_FIRST_BLOCK(mm_block) &&
2110ZEND_MM_IS_GUARD_BLOCK(ZEND_MM_BLOCK_AT(mm_block, size))) {
2111zend_mm_del_segment(heap, (zend_mm_segment *) ((char
*)mm_block - ZEND_MM_ALIGNED_SEGMENT_SIZE));
2112} else {
2113ZEND_MM_BLOCK(mm_block, ZEND_MM_FREE_BLOCK, size);
2114zend_mm_add_to_free_list(heap, (zend_mm_free_block *)
mm_block);
(gdb) bt
#0 _zend_mm_free_int (heap=0x143a330, p=0x1b15518) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2100
#1 0x0068ef1b in zend_hash_destroy (ht=0x1700318) at
/usr/src/php-5.4.13/Zend/zend_ha
Bug #64463 [Com]: Segfault (For the moment, can't reproduce it)
Edit report at https://bugs.php.net/bug.php?id=64463&edit=1
ID: 64463
Comment by: julien at palard dot fr
Reported by:julien at palard dot fr
Summary:Segfault (For the moment, can't reproduce it)
Status: Open
Type: Bug
Package:*General Issues
Operating System: Debian 6.0.7
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
Same segfault, other stacktrace, don't think it help a lot :
Program terminated with signal 11, Segmentation fault.
#0 _zend_mm_alloc_int (heap=0x143a330, size=82) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2016
2016ZEND_MM_CHECK_BLOCK_LINKAGE(best_fit);
(gdb) bt
#0 _zend_mm_alloc_int (heap=0x143a330, size=82) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2016
#1 0x00691791 in _zend_hash_quick_add_or_update (ht=0x1675e18,
arKey=0x7fc905b7fb50 "regexChar", nKeyLength=,
h=8246864001117707262, pData=0x1, nDataSize=8, pDest=0x7fc9207513a8, flag=1) at
/usr/src/php-5.4.13/Zend/zend_hash.c:330
#2 0x006a9948 in _get_zval_cv_lookup_BP_VAR_W (ptr=0x7fc9207513a8,
var=) at /usr/src/php-5.4.13/Zend/zend_execute.c:281
#3 0x0070557a in _get_zval_ptr_ptr_cv_BP_VAR_W
(execute_data=0x7fc9207512c8) at /usr/src/php-5.4.13/Zend/zend_execute.c:442
#4 ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (execute_data=0x7fc9207512c8) at
/usr/src/php-5.4.13/Zend/zend_vm_execute.h:33048
#5 0x006e8990 in execute (op_array=0x1a22840) at
/usr/src/php-5.4.13/Zend/zend_vm_execute.h:410
#6 0x00676473 in zend_call_function (fci=0x7fff3c616460,
fci_cache=) at
/usr/src/php-5.4.13/Zend/zend_execute_API.c:958
#7 0x0055bf1a in zim_reflection_method_invokeArgs (ht=, return_value=0x166df40, return_value_ptr=,
this_ptr=, return_value_used=)
at /usr/src/php-5.4.13/ext/reflection/php_reflection.c:3017
#8 0x006fb5dc in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fc92074d7f8) at /usr/src/php-5.4.13/Zend/zend_vm_execute.h:642
#9 0x006e8990 in execute (op_array=0x17b52b0) at
/usr/src/php-5.4.13/Zend/zend_vm_execute.h:410
#10 0x00681d9e in zend_execute_scripts (type=8, retval=, file_count=3) at /usr/src/php-5.4.13/Zend/zend.c:1315
#11 0x0062746e in php_execute_script (primary_file=) at /usr/src/php-5.4.13/main/main.c:2492
#12 0x00730fda in main (argc=, argv=) at /usr/src/php-5.4.13/sapi/fpm/fpm/fpm_main.c:1924
(gdb) list
2021
2022remaining_size = block_size - true_size;
2023
2024if (remaining_size < ZEND_MM_ALIGNED_MIN_HEADER_SIZE) {
2025true_size = block_size;
2026ZEND_MM_BLOCK(best_fit, ZEND_MM_USED_BLOCK, true_size);
2027} else {
2028zend_mm_free_block *new_free_block;
2029
2030/* prepare new free block */
(gdb) p *best_fit->info._prev
Cannot access memory at address 0x64696c61766e49
Same as the last, seems ASCII data instead of memory pointer :
$ echo $'\x64\x69\x6c\x61\x76\x6e\x49'
dilavnI
Previous Comments:
------------
[2013-03-20 14:44:59] julien at palard dot fr
Description:
I got a chance of 0.018% of segfaulting in my current setup, can't reproduce it
for the moment.
But I got a stacktrace ! :-)
gdb /usr/local/php-current/sbin/php-fpm ./core.php-fpm.9958
list
2105mm_block = ZEND_MM_PREV_BLOCK(mm_block);
2106zend_mm_remove_from_free_list(heap, (zend_mm_free_block
*) mm_block);
2107size += ZEND_MM_FREE_BLOCK_SIZE(mm_block);
2108}
2109if (ZEND_MM_IS_FIRST_BLOCK(mm_block) &&
2110ZEND_MM_IS_GUARD_BLOCK(ZEND_MM_BLOCK_AT(mm_block, size))) {
2111zend_mm_del_segment(heap, (zend_mm_segment *) ((char
*)mm_block - ZEND_MM_ALIGNED_SEGMENT_SIZE));
2112} else {
2113ZEND_MM_BLOCK(mm_block, ZEND_MM_FREE_BLOCK, size);
2114zend_mm_add_to_free_list(heap, (zend_mm_free_block *)
mm_block);
(gdb) bt
#0 _zend_mm_free_int (heap=0x143a330, p=0x1b15518) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2100
#1 0x0068ef1b in zend_hash_destroy (ht=0x1700318) at
/usr/src/php-5.4.13/Zend/zend_hash.c:560
#2 0x006a2ffc in zend_object_std_dtor (object=0x168a238) at
/usr/src/php-5.4.13/Zend/zend_objects.c:44
#3 0x006a3089 in zend_objects_free_object_storage (object=0x143a330)
at /usr/src/php-5.4.13/Zend/zend_objects.c:137
#4 0x006a87ca in zend_objects_store_free_object_storage
(objects=0xe2d3c0) at /usr/src/php-5.4.13/Zend/zend_objects_API.c:92
#5 0x00677f9a in shutdown_executor () at
/usr/src/php-5.4.13/Zend/zend_execute_API.c:297
#6 0x00682c93 in zend_deactivate () at
/usr/src/php-5.4.13/Zend/zend.c:938
#7 0x00627e0f in
[PHP-BUG] Bug #64463 [NEW]: Segfault (For the moment, can't reproduce it)
From: julien at palard dot fr
Operating system: Debian 6.0.7
PHP version: 5.4.13
Package: *General Issues
Bug Type: Bug
Bug description:Segfault (For the moment, can't reproduce it)
Description:
I got a chance of 0.018% of segfaulting in my current setup, can't
reproduce it for the moment.
But I got a stacktrace ! :-)
gdb /usr/local/php-current/sbin/php-fpm ./core.php-fpm.9958
list
2105mm_block = ZEND_MM_PREV_BLOCK(mm_block);
2106zend_mm_remove_from_free_list(heap,
(zend_mm_free_block *) mm_block);
2107size += ZEND_MM_FREE_BLOCK_SIZE(mm_block);
2108}
2109if (ZEND_MM_IS_FIRST_BLOCK(mm_block) &&
2110ZEND_MM_IS_GUARD_BLOCK(ZEND_MM_BLOCK_AT(mm_block,
size))) {
2111zend_mm_del_segment(heap, (zend_mm_segment *)
((char *)mm_block - ZEND_MM_ALIGNED_SEGMENT_SIZE));
2112} else {
2113ZEND_MM_BLOCK(mm_block, ZEND_MM_FREE_BLOCK, size);
2114zend_mm_add_to_free_list(heap, (zend_mm_free_block
*) mm_block);
(gdb) bt
#0 _zend_mm_free_int (heap=0x143a330, p=0x1b15518) at
/usr/src/php-5.4.13/Zend/zend_alloc.c:2100
#1 0x0068ef1b in zend_hash_destroy (ht=0x1700318) at
/usr/src/php-5.4.13/Zend/zend_hash.c:560
#2 0x006a2ffc in zend_object_std_dtor (object=0x168a238) at
/usr/src/php-5.4.13/Zend/zend_objects.c:44
#3 0x006a3089 in zend_objects_free_object_storage
(object=0x143a330) at /usr/src/php-5.4.13/Zend/zend_objects.c:137
#4 0x006a87ca in zend_objects_store_free_object_storage
(objects=0xe2d3c0) at /usr/src/php-5.4.13/Zend/zend_objects_API.c:92
#5 0x00677f9a in shutdown_executor () at
/usr/src/php-5.4.13/Zend/zend_execute_API.c:297
#6 0x00682c93 in zend_deactivate () at
/usr/src/php-5.4.13/Zend/zend.c:938
#7 0x00627e0f in php_request_shutdown (dummy=) at /usr/src/php-5.4.13/main/main.c:1800
#8 0x00730c63 in main (argc=, argv=) at /usr/src/php-5.4.13/sapi/fpm/fpm/fpm_main.c:1952
(gdb) p *next_block
Cannot access memory at address 0x656d616e7624c470
(gdb) print next_block
$7 = (zend_mm_block *) 0x656d616e7624c470
Pointer strangely look like ASCII / UTF8 data, but .. don't know, dropping
it here, if it can help :
$ echo $'\x65\x6d\x61\x6e\x76\x24\xc4\x70'
emanv$�p
Expected result:
No Segfault :)
Actual result:
--
Segfault ):
--
Edit bug report at https://bugs.php.net/bug.php?id=64463&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64463&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64463&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64463&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64463&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64463&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64463&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64463&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64463&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64463&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64463&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64463&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64463&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64463&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64463&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64463&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64463&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64463&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64463&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64463&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64463&r=mysqlcfg
Bug #62769 [Com]: Inconsistent notice reporting using []
Edit report at https://bugs.php.net/bug.php?id=62769&edit=1
ID: 62769
Comment by: julien at palard dot fr
Reported by:julien at palard dot fr
Summary:Inconsistent notice reporting using []
Status: Open
Type: Bug
Package:Output Control
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
larue...@php.net : Nice for const array dereference :-)
But what about the point of the ticket :
$foo = NULL;
echo $foo["bar"];
that fails silently ?
Previous Comments:
[2012-08-08 02:36:41] larue...@php.net
const array dereference is only in trunk
[2012-08-07 14:42:36] julien at palard dot fr
Description:
Error reported for invalid [] access seems inconsistent :
echo NULL["bar"] -> Parse error
echo []["bar"] -> Parse error
$foo = NULL; echo $foo["bar"] -> Fails silently
$foo = []; echo $foo["bar"] -> Notice: Undefined index
class Bar {} ; $foo = new Bar(); echo $foo["bar"]; -> PHP Fatal error
I whish :
[]["bar"] to trigger Notice: Undefined index
NULL["bar"] to trigger something catcheable with set_error_handler
$foo = NULL; $foo["bar"] to trigger a catcheable Notice.
Test script:
---
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); echo []["bar"];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); echo NULL["bar"];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); $foo = NULL; $foo["bar"];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); $foo = []; $foo["bar"];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); class Bar {} ; $foo = new
Bar(); echo $foo["bar"];'
Expected result:
At least get a Notice on :
$foo = NULL;
echo $foo["bar"];
Actual result:
--
Fails silently.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62769&edit=1
[PHP-BUG] Bug #62769 [NEW]: Inconsistent notice reporting using []
From: julien at palard dot fr
Operating system:
PHP version: 5.4.5
Package: Output Control
Bug Type: Bug
Bug description:Inconsistent notice reporting using []
Description:
Error reported for invalid [] access seems inconsistent :
echo NULL["bar"] -> Parse error
echo []["bar"] -> Parse error
$foo = NULL; echo $foo["bar"] -> Fails silently
$foo = []; echo $foo["bar"] -> Notice: Undefined index
class Bar {} ; $foo = new Bar(); echo $foo["bar"]; -> PHP Fatal error
I whish :
[]["bar"] to trigger Notice: Undefined index
NULL["bar"] to trigger something catcheable with set_error_handler
$foo = NULL; $foo["bar"] to trigger a catcheable Notice.
Test script:
---
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); echo []["bar"];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); echo NULL["bar"];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); $foo = NULL;
$foo["bar"];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); $foo = [];
$foo["bar"];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); class Bar {} ; $foo =
new Bar(); echo $foo["bar"];'
Expected result:
At least get a Notice on :
$foo = NULL;
echo $foo["bar"];
Actual result:
--
Fails silently.
--
Edit bug report at https://bugs.php.net/bug.php?id=62769&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62769&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62769&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62769&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62769&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62769&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62769&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62769&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62769&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62769&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62769&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62769&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62769&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62769&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62769&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62769&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62769&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62769&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62769&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62769&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62769&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62769&r=mysqlcfg
[PHP-BUG] Bug #62059 [NEW]: ArrayObject and isset are not friends.
From:
Operating system: Linux 2.6.32-5-amd64
PHP version: Irrelevant
Package: SPL related
Bug Type: Bug
Bug description:ArrayObject and isset are not friends.
Description:
The doc state that isset() is not a function, so that it can do weird
things
like deep inspection, without raising a NOTICE about 'b' being undefined :
$a = array();
isset($a['b']['c']);
But if $a is an ArrayObject, the deep inspection does not work and a
"Undefined
index 'b'" NOTICE is triggered.
But I found a __isset() in the documentation,
(http://www.php.net/manual/en/language.oop5.overloading.php#object.isset)
it
have a very concise documentation but it seems a sufficient convention to
make
this work :
I think that isset should call __isset() from left to right returning FALSE
at
the 1st non set member, like this :
$a = SomeObject();
isset($a['b']['c']['d']['e']);
should call :
$a->__isset('b'), that should return FALSE, and stop here, wihout NOTICE.
Test script:
---
echo "isset on array, work without notice\n";
$array = array();
var_dump(isset($array['a']['b']));
echo "isset on arrayobject, should work as ArrayObject implements
__isset\n";
$arrayobject = new ArrayObject();
var_dump(isset($arrayobject['a']['b']));
Expected result:
isset on array, work without notice
bool(false)
isset on arrayobject, should work as ArrayObject implements __isset
bool(false)
Actual result:
--
isset on array, work without notice
bool(false)
isset on arrayobject, should work as ArrayObject implements __isset
PHP Notice: Undefined index: a in test.php on line 10
Notice: Undefined index: a in test.php on line 10
bool(false)
--
Edit bug report at https://bugs.php.net/bug.php?id=62059&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62059&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62059&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62059&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62059&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62059&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62059&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62059&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62059&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62059&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62059&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62059&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62059&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62059&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62059&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62059&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62059&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62059&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62059&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62059&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62059&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62059&r=mysqlcfg
Bug #61516 [Com]: PDOStatement::errorInfo returning NULL for driver code and message
Edit report at https://bugs.php.net/bug.php?id=61516&edit=1
ID: 61516
Comment by: julien at palard dot fr
Reported by:julien at palard dot fr
Summary:PDOStatement::errorInfo returning NULL for driver
code and message
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux 2.6.32-5-amd64
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
u...@php.net, I think that one can expect to have as much as possible
informations about an error, and that it's not fair to provide different level
of precision to one querying the error description from one way.
Just think about those who just didn't spotted the difference or those who
simply don't want to use ERRMODE_WARNING, they will have harder times to fix
their SQL bugs, that's not a good thing. I personally think this should be
fixed.
Previous Comments:
[2012-04-30 16:39:38] u...@php.net
The PDO warning is based on a static look-up table compiled into the PDO core.
That means, it is out of control of any PDO driver. A SQL code reported by a
driver is translated into whatever message the PDO core likes.
Any PDO driver is free to provide an internal callback to update the contents
of the return value of errorInfo(). Providing an internal callback is not
mandatory.
Due to the different source of the error message one must not expect error
messages to be equal. At the end of the day: this is PDO...
----
[2012-03-26 16:49:00] julien at palard dot fr
Description:
While using not emulated prepared statement against MySQL 5.5, warnings (using
ERRMODE_WARNING) are more verbose than errorInfo(). With prepared queries,
errorInfo return (string, NULL, NULL).
This fact is true with or without ERRMODE_WARNING.
And this fact is also true, but different while using standard queries :
What the warning give me :
{{{
[WARNING] PDO::query() [pdo.query]: SQLSTATE[23000]:
Integrity constraint violation: 1062 Duplicate entry '83-27
7727' for key 'UNIQUE'
}}}
What I got from errorInfo()[2] (Missing the "Integrity constraint violation:"
string, built client side from error code ?) :
{{{
Duplicate entry '83-277727' for key 'UNIQUE'
}}}
Test script:
---
errorInfo());
return $res;
}
}
$options = array(PDO::ATTR_PERSISTENT => FALSE,
PDO::ATTR_ERRMODE => PDO::ERRMODE_WARNING,
PDO::ATTR_EMULATE_PREPARES => FALSE,
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
PDO::ATTR_STATEMENT_CLASS => array('My_PDOStatement'));
$pdo = new PDO(...);
$stmt = $pdo->prepare("SELECT :a + :a");
$stmt->execute(array('a' => 1)); // Willingly generate 'Invalid parameter
number'
var_dump($stmt->fetchAll());
Expected result:
I Expect errorInfo() to return error messages.
Actual result:
--
errorInfo() in this specific case return (string, NULL, NULL).
--
Edit this bug report at https://bugs.php.net/bug.php?id=61516&edit=1
[PHP-BUG] Bug #61516 [NEW]: PDOStatement::errorInfo returning NULL for driver code and message
From:
Operating system: Linux 2.6.32-5-amd64
PHP version: 5.4.0
Package: PDO related
Bug Type: Bug
Bug description:PDOStatement::errorInfo returning NULL for driver code and
message
Description:
While using not emulated prepared statement against MySQL 5.5, warnings
(using ERRMODE_WARNING) are more verbose than errorInfo(). With prepared
queries, errorInfo return (string, NULL, NULL).
This fact is true with or without ERRMODE_WARNING.
And this fact is also true, but different while using standard queries :
What the warning give me :
{{{
[WARNING] PDO::query() [pdo.query]:
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry
'83-27
7727' for key 'UNIQUE'
}}}
What I got from errorInfo()[2] (Missing the "Integrity constraint
violation:" string, built client side from error code ?) :
{{{
Duplicate entry '83-277727' for key 'UNIQUE'
}}}
Test script:
---
errorInfo());
return $res;
}
}
$options = array(PDO::ATTR_PERSISTENT => FALSE,
PDO::ATTR_ERRMODE => PDO::ERRMODE_WARNING,
PDO::ATTR_EMULATE_PREPARES => FALSE,
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
PDO::ATTR_STATEMENT_CLASS => array('My_PDOStatement'));
$pdo = new PDO(...);
$stmt = $pdo->prepare("SELECT :a + :a");
$stmt->execute(array('a' => 1)); // Willingly generate 'Invalid parameter
number'
var_dump($stmt->fetchAll());
Expected result:
I Expect errorInfo() to return error messages.
Actual result:
--
errorInfo() in this specific case return (string, NULL, NULL).
--
Edit bug report at https://bugs.php.net/bug.php?id=61516&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61516&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61516&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61516&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61516&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61516&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61516&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61516&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61516&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61516&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61516&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61516&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61516&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61516&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61516&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61516&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61516&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61516&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61516&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61516&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61516&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61516&r=mysqlcfg
[PHP-BUG] Bug #61411 [NEW]: PDO Segfaults with PERSISTENT == TRUE && EMULATE_PREPARES == FALSE
From:
Operating system: Linux 2.6.32-5-amd64
PHP version: 5.4.0
Package: PDO related
Bug Type: Bug
Bug description:PDO Segfaults with PERSISTENT == TRUE && EMULATE_PREPARES ==
FALSE
Description:
PDO Segfaults or hangs when a statement is executed with both
ATTR_PERSISTENT =>
TRUE and ATTR_EMULATE_PREPARES => FALSE
The exact bug is actually :
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid
pointer:
0x7ff976ee84c8 ***
But from my tests yesterday I have seen a segfault and a double free, that
I
can't reproduce today, only the invalid pointer.
Playing with PERSISTENT and EMULATE_PREPARE with the given test script give
:
| ATTR_PERSISENT | ATTR_EMULATE_PREPARES | WORKS |
| FALSE | FALSE |YES |
| FALSE | TRUE |YES |
| TRUE | FALSE | free() invalid pointer |
| TRUE | TRUE |YES |
Configure command :
./configure' '--enable-fpm' '--prefix=/usr/local/php-5.4.0'
'--enable-mbstring'
'--enable-gd-native-ttf' '--enable-zip' '--with-mcrypt' '--with-openssl'
'--
with-gd' '--with-jpeg-dir=/usr/lib' '--with-freetype-dir' '--with-curl'
'--with-
pcre-regex' '--with-gettext' '--without-sqlite' '--without-sqlite3'
'--with-pdo-
mysql=mysqlnd' '--disable-rpath' '--disable-debug' '--disable-fileinfo'
'--
without-pdo-sqlite' '--disable-phar' '--disable-posix'
'--disable-tokenizer' '--
disable-xmlreader' '--disable-xmlwriter' '--without-pear'
Same bug reproduced in php 5.3.8 and php 5.3.10
Test script:
---
TRUE,
PDO::ATTR_EMULATE_PREPARES => FALSE);
$pdo = new PDO('mysql:host=sql;dbname=??;charset=utf8',
'??', '??', $options);
$statement = $pdo->prepare("SELECT count(*) from a_table");
$statement->execute();
foreach ($statement as $line)
var_dump($line);
Expected result:
I expect PHP not to segfault
Actual result:
--
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid
pointer:
0x7ff976ee84c8 ***
--
Edit bug report at https://bugs.php.net/bug.php?id=61411&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61411&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61411&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61411&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61411&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61411&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61411&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61411&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61411&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61411&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61411&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61411&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61411&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61411&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61411&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61411&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61411&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61411&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61411&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61411&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61411&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61411&r=mysqlcfg
[PHP-BUG] Bug #61292 [NEW]: Segfault while calling a method on an overloaded PDO object.
From:
Operating system: Linux 2.6.32-amd64
PHP version: 5.4.0
Package: PDO related
Bug Type: Bug
Bug description:Segfault while calling a method on an overloaded PDO object.
Description:
Just check the simple code in the "Test script", it lead to the segfault.
Seems that it only segfault when ATTR_PERSISTENT is set.
Test script:
---
TRUE);
parent::__construct("mysql:host=***;dbname=***;charset=utf8",
'***', '***', $options);
}
var $bar = array();
public function foo()
{
var_dump($this->bar);
}
}
(new Melty_Database_SQL)->foo();
Expected result:
No segfault !
Actual result:
--
Segfault !
--
Edit bug report at https://bugs.php.net/bug.php?id=61292&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61292&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61292&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61292&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61292&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61292&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61292&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61292&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61292&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61292&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61292&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61292&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61292&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61292&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61292&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61292&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61292&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61292&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61292&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61292&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61292&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61292&r=mysqlcfg
[PHP-BUG] Bug #60383 [NEW]: Segmentation Fault hard to reproduce
From:
Operating system: Debian
PHP version: 5.3.8
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Segmentation Fault hard to reproduce
Description:
When running php-fpm 5.3.8 with APC-3.1.9 for several random days, it start
to
systematically segfault, we can't
reproduce it for now without waiting it to happen.
Here is some gdb informations :
The segfault in zend_compile.c line 2972 :
Program received signal SIGSEGV, Segmentation fault.
0x00628c8d in do_bind_function (opline=0x7fe50eeb1398,
function_table=0x215ac30, compile_time=0 '\000') at
/usr/src/php-5.3.8/Zend/zend_compile.c:2972
2972(*function->op_array.refcount)++;
A stacktrace :
(gdb) bt
#0 0x00628c8d in do_bind_function (opline=0x7fe50eeb1398,
function_table=0x215ac30, compile_time=0 '\000')
at /usr/src/php-5.3.8/Zend/zend_compile.c:2972
#1 0x006665a5 in ZEND_DECLARE_FUNCTION_SPEC_HANDLER
(execute_data=0x2590548) at /usr/src/php-
5.3.8/Zend/zend_vm_execute.h:586
#2 0x00666378 in execute (op_array=0x267bf98) at /usr/src/php-
5.3.8/Zend/zend_vm_execute.h:107
#3 0x00637d2a in zend_call_function (fci=0x7fff3aa53fa0,
fci_cache=
) at /usr/src/php-
5.3.8/Zend/zend_execute_API.c:968
#4 0x005275f0 in zim_reflection_method_invokeArgs (ht=, return_value=0x233f5c0,
return_value_ptr=,
this_ptr=, return_value_used=) at
/usr/src/php-
5.3.8/ext/reflection/php_reflection.c:2750
#5 0x0068de5c in zend_do_fcall_common_helper_SPEC
(execute_data=0x258a778) at /usr/src/php-
5.3.8/Zend/zend_vm_execute.h:320
#6 0x00666378 in execute (op_array=0x2522480) at /usr/src/php-
5.3.8/Zend/zend_vm_execute.h:107
#7 0x006411ea in zend_execute_scripts (type=8, retval=, file_count=3) at /usr/src/php-
5.3.8/Zend/zend.c:1236
#8 0x005effee in php_execute_script (primary_file=) at /usr/src/php-
5.3.8/main/main.c:2284
#9 0x006cf132 in main (argc=, argv=) at /usr/src/php-
5.3.8/sapi/fpm/fpm/fpm_main.c:1902
Some information about what caused the segfault :
function seems a valid pointer :
(gdb) p function
$1 = (zend_function *) 0x6821d0
But refcount seems to point to an invalid address garbage ...
(gdb) p function->op_array.refcount
$2 = (zend_uint *) 0x6697eb0824748b48
That is out of memory :
(gdb) p *function->op_array.refcount
Cannot access memory at address 0x6697eb0824748b48
function also contains a lot of garbage :
(gdb) p *function
$3 = {type = 72 'H', common = {type = 72 'H', function_name =
0x1f0fc35d5bc031
, scope = 0x102444c748,
fn_flags = 360611840, prototype = 0x1446b60f2c7401f8, num_args =
1006954627,
required_num_args = 1219458817,
arg_info = 0xe80824748948f789,
pass_rest_by_reference = 52 '4', return_reference = 197 '\305'},
op_array =
{type = 72 'H',
function_name = 0x1f0fc35d5bc031 ,
scope = 0x102444c748, fn_flags =
360611840, prototype = 0x1446b60f2c7401f8,
num_args = 1006954627, required_num_args = 1219458817, arg_info =
0xe80824748948f789, pass_rest_by_reference = 52
'4', return_reference = 197 '\305',
done_pass_two = 253 '\375', refcount = 0x6697eb0824748b48, opcodes =
0x841f0f, last = 1394374, size = 2370359019,
vars = 0x481024548d482845,
last_var = -1991717239, size_var = 564586695, T = 2336817151,
brk_cont_array
= 0x2e66ff68e9c6, last_brk_cont =
8658703, current_brk_cont = 0,
try_catch_array = 0x6c8948e8245c8948, last_try_catch = -1991708636,
static_variables = 0x8b4838ec8348f824, start_op
= 0x50458b38778b482f,
backpatch_count = 106203976, this_var = 3531950088, filename =
0x428b00b8840f , line_start = 32015120,
line_end = 1116323973, doc_comment = 0xc7001542c6657510 , doc_comment_len
= 69698, early_binding = 2303197184,
reserved = {0x8b30658b44102454, 0x8d4826248d4e107d, 0x84eee8e6894c3e3c,
0x314247c8041fffb}}, internal_function =
{type = 72 'H',
function_name = 0x1f0fc35d5bc031 ,
scope = 0x102444c748, fn_flags =
360611840, prototype = 0x1446b60f2c7401f8,
num_args = 1006954627, required_num_args = 1219458817, arg_info =
0xe80824748948f789, pass_rest_by_reference = 52
'4', return_reference = 197 '\305',
handler = 0x6697eb0824748b48, module = 0x841f0f}}
I found that function is from a function_table so i search for the name of
the
searched function :
(gdb) p opline->op1.u.constant.value
$6 = {lval = 140621774571448, dval = 6.9476387872984637e-310, str = {val =
0x7fe50eebc7b8 "", len = 78}, ht =
0x7fe50eebc7b8, obj = {handle = 250333112,
handlers = 0x4e}}
Seems space too ...
You can query for more information (value of pointers, etc...) but I may
take
some days to provide them waiting for php
to enter this state again.
--
Edit bug report at https://bugs.php.net/bug.php?id=60383&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60383&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60383&r=trysnapshot53
[PHP-BUG] Req #60199 [NEW]: php-fpm does not log an error for "too many open files"
From: Operating system: All PHP version: Irrelevant Package: FPM related Bug Type: Feature/Change Request Bug description:php-fpm does not log an error for "too many open files" Description: When php-fpm hits a "too many open files", it returns a 404 and don't log anything, so typically for people using nginx they got a "No input file specified." that is hard to debug. I dropped an strace here : http://pastebin.com/PVCqF9cD I think that php-fpm should log something to let people diagnose why they open so much file and/or modify their rlimit. -- Edit bug report at https://bugs.php.net/bug.php?id=60199&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60199&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60199&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60199&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60199&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60199&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60199&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60199&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60199&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60199&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60199&r=support Expected behavior: https://bugs.php.net/fix.php?id=60199&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60199&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60199&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60199&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60199&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60199&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60199&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60199&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60199&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60199&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60199&r=mysqlcfg
