Bug #62129 [Com]: rfc1867 crashes php even though turned off
Edit report at https://bugs.php.net/bug.php?id=62129edit=1
ID: 62129
Comment by: gxd305 at gmail dot com
Reported by:truth at proposaltech dot com
Summary:rfc1867 crashes php even though turned off
Status: Assigned
Type: Bug
Package:Session related
Operating System: CentOS
PHP Version:5.4.3
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
we should reset php_rfc1867_callback and php_session_rfc1867_orig_callback to
null in MSHUTDOWN while changing them in MINIT.
with this patch
php-5.4.11-session-reset-global-var-in-shutdown
our php works fine in the production.
of course, it's not the fundamental solution
Previous Comments:
[2013-01-19 13:49:03] gxd305 at gmail dot com
i'm sorry for the last comment for the wrong analysis.
it should be php_rfc1867_callback reserve the old value (
php_session_rfc1867_callback) after reload, and make
php_session_rfc1867_callback be called recursively.
[2013-01-19 11:26:34] gxd305 at gmail dot com
the other extensions have the similar problems if not set the global var to
null in mshutdown after reload.
php_session_rfc1867_orig_callback reserve the last value after reload, instead
of the default value nullã
such as ice-php has the same problem, not set the global vars to null in
mshutdown.
if i set the global vars ' default value explicitly or set the global vars to
null in mshutdown, the problem goes away.
[2012-05-24 20:48:14] truth at proposaltech dot com
Here is a the relevant portion of the backtrace from the seg fault:
#104648 0x006cd5b8 in php_session_rfc1867_callback (event=0,
event_data=0x7fffb2b8f950, extra=value optimized out)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104649 0x006cd5b8 in php_session_rfc1867_callback (event=0,
event_data=0x7fffb2b8f950, extra=value optimized out)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104650 0x00473841 in rfc1867_post_handler (
content_type_dup=value optimized out, arg=0x11535e8)
at /cns/build/php-5.4.3/main/rfc1867.c:773
#104651 0x00471372 in sapi_handle_post (arg=value optimized out)
at /cns/build/php-5.4.3/main/SAPI.c:182
#104652 0x0067efd8 in mbstr_treat_data (arg=0, str=0x0,
destArray=value optimized out)
at /cns/build/php-5.4.3/ext/mbstring/mb_gpc.c:98
#104653 0x00475e9e in php_auto_globals_create_post (
name=0x12a6a60 _POST, name_len=5)
at /cns/build/php-5.4.3/main/php_variables.c:682
#104654 0x0049aa4b in zend_auto_global_init (auto_global=0x110e800)
at /cns/build/php-5.4.3/Zend/zend_compile.c:
#104655 0x004ca974 in zend_hash_apply (ht=0x111bf20,
apply_func=0x49aa30 zend_auto_global_init)
at /cns/build/php-5.4.3/Zend/zend_hash.c:716
#104656 0x004772bb in php_hash_environment ()
at /cns/build/php-5.4.3/main/php_variables.c:642
#104657 0x004697f5 in php_request_startup ()
at /cns/build/php-5.4.3/main/main.c:1568
#104658 0x0056084f in apache_php_module_main (r=value optimized out,
display_source_mode=0) at /cns/build/php-5.4.3/sapi/apache/sapi_apache.c:33
#104659 0x00461c00 in send_php ()
#104660 0x00461c48 in send_parsed_php ()
#104661 0x0085f773 in ap_invoke_handler ()
#104662 0x00878d90 in process_request_internal ()
#104663 0x00878df3 in ap_process_request ()
#104664 0x0086e46f in child_main ()
#104665 0x0086e728 in make_child ()
#104666 0x0086e7e9 in startup_children ()
#104667 0x0086effb in standalone_main ()
#104668 0x0086f8cc in main ()
I don't know much about internals, but I'll try to translate the
above based on function names and values I saw in the debugger.
While activating auto_globals, the _POST auto_global had a
callback to be called: php_auto_globals_create_post().
That used the mbstring extension, which for the case of
PARSE_POST, relies on sapi_handle_post().
sapi_handle_post() used rfc1867_post_handler()
because the sapi_globals.request_info.post_entry had
an rfc1867 post_handler:
print *sapi_globals.request_info.post_entry
$7 = {content_type = 0x8c4bc9 multipart/form-data, content_type_len = 19,
post_reader = 0, post_handler = 0x473590 rfc1867_post_handler}
I don't know why that post_handler value was set to
rfc1867_post_handler given that my php.ini includes
session.upload_progress.enabled = off
Similarly, I don't know why php_rfc1867_callback was
non-null given my php.ini setting.
Once the php_rfc1867_callback() was called, everything
died quickly. That callback calls the orig_callback
(if non-null) and the orig_callback was the same
Bug #62129 [Com]: rfc1867 crashes php even though turned off
Edit report at https://bugs.php.net/bug.php?id=62129edit=1
ID: 62129
Comment by: gxd305 at gmail dot com
Reported by:truth at proposaltech dot com
Summary:rfc1867 crashes php even though turned off
Status: Assigned
Type: Bug
Package:Session related
Operating System: CentOS
PHP Version:5.4.3
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
the other extensions have the similar problems if not set the global var to
null in mshutdown after reload.
php_session_rfc1867_orig_callback reserve the last value after reload, instead
of the default value nullã
such as ice-php has the same problem, not set the global vars to null in
mshutdown.
if i set the global vars ' default value explicitly or set the global vars to
null in mshutdown, the problem goes away.
Previous Comments:
[2012-05-24 20:48:14] truth at proposaltech dot com
Here is a the relevant portion of the backtrace from the seg fault:
#104648 0x006cd5b8 in php_session_rfc1867_callback (event=0,
event_data=0x7fffb2b8f950, extra=value optimized out)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104649 0x006cd5b8 in php_session_rfc1867_callback (event=0,
event_data=0x7fffb2b8f950, extra=value optimized out)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104650 0x00473841 in rfc1867_post_handler (
content_type_dup=value optimized out, arg=0x11535e8)
at /cns/build/php-5.4.3/main/rfc1867.c:773
#104651 0x00471372 in sapi_handle_post (arg=value optimized out)
at /cns/build/php-5.4.3/main/SAPI.c:182
#104652 0x0067efd8 in mbstr_treat_data (arg=0, str=0x0,
destArray=value optimized out)
at /cns/build/php-5.4.3/ext/mbstring/mb_gpc.c:98
#104653 0x00475e9e in php_auto_globals_create_post (
name=0x12a6a60 _POST, name_len=5)
at /cns/build/php-5.4.3/main/php_variables.c:682
#104654 0x0049aa4b in zend_auto_global_init (auto_global=0x110e800)
at /cns/build/php-5.4.3/Zend/zend_compile.c:
#104655 0x004ca974 in zend_hash_apply (ht=0x111bf20,
apply_func=0x49aa30 zend_auto_global_init)
at /cns/build/php-5.4.3/Zend/zend_hash.c:716
#104656 0x004772bb in php_hash_environment ()
at /cns/build/php-5.4.3/main/php_variables.c:642
#104657 0x004697f5 in php_request_startup ()
at /cns/build/php-5.4.3/main/main.c:1568
#104658 0x0056084f in apache_php_module_main (r=value optimized out,
display_source_mode=0) at /cns/build/php-5.4.3/sapi/apache/sapi_apache.c:33
#104659 0x00461c00 in send_php ()
#104660 0x00461c48 in send_parsed_php ()
#104661 0x0085f773 in ap_invoke_handler ()
#104662 0x00878d90 in process_request_internal ()
#104663 0x00878df3 in ap_process_request ()
#104664 0x0086e46f in child_main ()
#104665 0x0086e728 in make_child ()
#104666 0x0086e7e9 in startup_children ()
#104667 0x0086effb in standalone_main ()
#104668 0x0086f8cc in main ()
I don't know much about internals, but I'll try to translate the
above based on function names and values I saw in the debugger.
While activating auto_globals, the _POST auto_global had a
callback to be called: php_auto_globals_create_post().
That used the mbstring extension, which for the case of
PARSE_POST, relies on sapi_handle_post().
sapi_handle_post() used rfc1867_post_handler()
because the sapi_globals.request_info.post_entry had
an rfc1867 post_handler:
print *sapi_globals.request_info.post_entry
$7 = {content_type = 0x8c4bc9 multipart/form-data, content_type_len = 19,
post_reader = 0, post_handler = 0x473590 rfc1867_post_handler}
I don't know why that post_handler value was set to
rfc1867_post_handler given that my php.ini includes
session.upload_progress.enabled = off
Similarly, I don't know why php_rfc1867_callback was
non-null given my php.ini setting.
Once the php_rfc1867_callback() was called, everything
died quickly. That callback calls the orig_callback
(if non-null) and the orig_callback was the same as
the php_session_rfc1867_callback - endless recursion.
Perhaps the real killer is the following lines from
session.c (~line 2195):
php_session_rfc1867_orig_callback = php_rfc1867_callback;
php_rfc1867_callback = php_session_rfc1867_callback;
I don't think those lines should be called if I have
session.upload_progress.enabled = off
in my php.ini. Setting php_rfc1867_callback seems
to be what cause rfc1867 code to be called. Setting
php_session_rfc1867_orig_callback to php_rfc1867_callback
(which is php_session_rfc1867_callback) leads to the
endless recursion.
Sorry I don't have a fix.
Thanks very much for continuing to improve php!!!
[2012-05-24 01
Bug #62129 [Com]: rfc1867 crashes php even though turned off
Edit report at https://bugs.php.net/bug.php?id=62129edit=1
ID: 62129
Comment by: gxd305 at gmail dot com
Reported by:truth at proposaltech dot com
Summary:rfc1867 crashes php even though turned off
Status: Assigned
Type: Bug
Package:Session related
Operating System: CentOS
PHP Version:5.4.3
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
i'm sorry for the last comment for the wrong analysis.
it should be php_rfc1867_callback reserve the old value (
php_session_rfc1867_callback) after reload, and make
php_session_rfc1867_callback be called recursively.
Previous Comments:
[2013-01-19 11:26:34] gxd305 at gmail dot com
the other extensions have the similar problems if not set the global var to
null in mshutdown after reload.
php_session_rfc1867_orig_callback reserve the last value after reload, instead
of the default value nullã
such as ice-php has the same problem, not set the global vars to null in
mshutdown.
if i set the global vars ' default value explicitly or set the global vars to
null in mshutdown, the problem goes away.
[2012-05-24 20:48:14] truth at proposaltech dot com
Here is a the relevant portion of the backtrace from the seg fault:
#104648 0x006cd5b8 in php_session_rfc1867_callback (event=0,
event_data=0x7fffb2b8f950, extra=value optimized out)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104649 0x006cd5b8 in php_session_rfc1867_callback (event=0,
event_data=0x7fffb2b8f950, extra=value optimized out)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104650 0x00473841 in rfc1867_post_handler (
content_type_dup=value optimized out, arg=0x11535e8)
at /cns/build/php-5.4.3/main/rfc1867.c:773
#104651 0x00471372 in sapi_handle_post (arg=value optimized out)
at /cns/build/php-5.4.3/main/SAPI.c:182
#104652 0x0067efd8 in mbstr_treat_data (arg=0, str=0x0,
destArray=value optimized out)
at /cns/build/php-5.4.3/ext/mbstring/mb_gpc.c:98
#104653 0x00475e9e in php_auto_globals_create_post (
name=0x12a6a60 _POST, name_len=5)
at /cns/build/php-5.4.3/main/php_variables.c:682
#104654 0x0049aa4b in zend_auto_global_init (auto_global=0x110e800)
at /cns/build/php-5.4.3/Zend/zend_compile.c:
#104655 0x004ca974 in zend_hash_apply (ht=0x111bf20,
apply_func=0x49aa30 zend_auto_global_init)
at /cns/build/php-5.4.3/Zend/zend_hash.c:716
#104656 0x004772bb in php_hash_environment ()
at /cns/build/php-5.4.3/main/php_variables.c:642
#104657 0x004697f5 in php_request_startup ()
at /cns/build/php-5.4.3/main/main.c:1568
#104658 0x0056084f in apache_php_module_main (r=value optimized out,
display_source_mode=0) at /cns/build/php-5.4.3/sapi/apache/sapi_apache.c:33
#104659 0x00461c00 in send_php ()
#104660 0x00461c48 in send_parsed_php ()
#104661 0x0085f773 in ap_invoke_handler ()
#104662 0x00878d90 in process_request_internal ()
#104663 0x00878df3 in ap_process_request ()
#104664 0x0086e46f in child_main ()
#104665 0x0086e728 in make_child ()
#104666 0x0086e7e9 in startup_children ()
#104667 0x0086effb in standalone_main ()
#104668 0x0086f8cc in main ()
I don't know much about internals, but I'll try to translate the
above based on function names and values I saw in the debugger.
While activating auto_globals, the _POST auto_global had a
callback to be called: php_auto_globals_create_post().
That used the mbstring extension, which for the case of
PARSE_POST, relies on sapi_handle_post().
sapi_handle_post() used rfc1867_post_handler()
because the sapi_globals.request_info.post_entry had
an rfc1867 post_handler:
print *sapi_globals.request_info.post_entry
$7 = {content_type = 0x8c4bc9 multipart/form-data, content_type_len = 19,
post_reader = 0, post_handler = 0x473590 rfc1867_post_handler}
I don't know why that post_handler value was set to
rfc1867_post_handler given that my php.ini includes
session.upload_progress.enabled = off
Similarly, I don't know why php_rfc1867_callback was
non-null given my php.ini setting.
Once the php_rfc1867_callback() was called, everything
died quickly. That callback calls the orig_callback
(if non-null) and the orig_callback was the same as
the php_session_rfc1867_callback - endless recursion.
Perhaps the real killer is the following lines from
session.c (~line 2195):
php_session_rfc1867_orig_callback = php_rfc1867_callback;
php_rfc1867_callback = php_session_rfc1867_callback;
I don't think those lines should be called if I have
session.upload_progress.enabled = off
in my php.ini. Setting php_rfc1867_callback seems
