FAQ
Hi Stas,

We've just found one more critical problem in 5.4.

Apache/PHP crashes in case of error on startup, when
display_startup_errors=1. It's probably related to new output API.

I afraid it may affect many php users.

#0 0x00007ff4509cb471 in php_apache_sapi_header_handler
(sapi_header=0x7fff9176cda0, op=SAPI_HEADER_ADD,
sapi_headers=0x7ff450f037b0)
at /php-5.4.0RC6/sapi/apache2handler/sapi_apache2.c:124
#1 0x00007ff450811414 in sapi_header_add_op (op=SAPI_HEADER_ADD,
sapi_header=0x7fff9176cda0) at /php-5.4.0RC6/main/SAPI.c:618
#2 0x00007ff450811e33 in sapi_send_headers () at
/php-5.4.0RC6/main/SAPI.c:835
#3 0x00007ff450791b10 in php_header () at
/php-5.4.0RC6/ext/standard/head.c:68
#4 0x00007ff45081d44c in php_output_op (op=0, str=0x7ff45779bac8
"\nWarning: Module 'Phar' already loaded in Unknown on line 0\n", len=60)
at /php-5.4.0RC6/main/output.c:1020
#5 0x00007ff45081b993 in php_output_write (str=0x7ff45779bac8
"\nWarning: Module 'Phar' already loaded in Unknown on line 0\n", len=60)
at /php-5.4.0RC6/main/output.c:201
#6 0x00007ff450802c55 in php_printf (format=0x7ff450c1d669 "%s\n%s: %s
in %s on line %d\n%s") at /php-5.4.0RC6/main/main.c:673
#7 0x00007ff45080410c in php_error_cb (type=32,
error_filename=0x7ff450c32a0b "Unknown", error_lineno=0,
format=0x7ff450c33132 "Module '%s' already loaded",
args=0x7fff9176d200) at /php-5.4.0RC6/main/main.c:1089
#8 0x00007ff45089267d in zend_error (type=32, format=0x7ff450c33132
"Module '%s' already loaded") at /php-5.4.0RC6/Zend/zend.c:1082
#9 0x00007ff45089aac8 in zend_register_module_ex
(module=0x7ff44649de00) at /php-5.4.0RC6/Zend/zend_API.c:1832
#10 0x00007ff45077da51 in php_load_extension (filename=0x7ff45779b008
"phar.so", type=1, start_now=0)
at /php-5.4.0RC6/ext/standard/dl.c:237
#11 0x00007ff45080ed28 in php_load_php_extension_cb (arg=0x195cd40) at
/php-5.4.0RC6/main/php_ini.c:351
#12 0x00007ff450883763 in zend_llist_apply (l=0x7ff450ef6c78,
func=0x7ff45080ed06 <php_load_php_extension_cb>)
at /php-5.4.0RC6/Zend/zend_llist.c:193
#13 0x00007ff45080f98b in php_ini_register_extensions () at
/php-5.4.0RC6/main/php_ini.c:710
#14 0x00007ff45080624c in php_module_startup (sf=0x7ff450ec0240,
additional_modules=0x7ff450ec0380, num_additional_modules=1)
at /php-5.4.0RC6/main/main.c:2193
#15 0x00007ff4509cbd54 in php_apache2_startup
(sapi_module=0x7ff450ec0240) at
/php-5.4.0RC6/sapi/apache2handler/sapi_apache2.c:348
#16 0x00007ff4509cbf08 in php_apache_server_startup (pconf=0x17c8168,
plog=0x17fc308, ptemp=0x17d01a8, s=0x17ce968)
at /php-5.4.0RC6/sapi/apache2handler/sapi_apache2.c:457
#17 0x0000000000438d84 in ap_run_post_config ()
#18 0x0000000000425bbc in main ()

In 5.3 SAPI functions were not called for startup errors.

I'm not going to fix it myself.

Thanks. Dmitry.

Search Discussions

  • Yoram bar haim at Jan 25, 2012 at 4:12 pm
    the main difference is php_sprintf
    in 5.3 it calls OG(php_body_write) which points to php_default_output_func at
    tha point.
    in 5.4 it calls php_output_write, which writes output via SAPI.
    On Wednesday, January 25, 2012 05:07:15 PM Dmitry Stogov wrote:
    Hi Stas,

    We've just found one more critical problem in 5.4.

    Apache/PHP crashes in case of error on startup, when
    display_startup_errors=1. It's probably related to new output API.

    I afraid it may affect many php users.

    #0 0x00007ff4509cb471 in php_apache_sapi_header_handler
    (sapi_header=0x7fff9176cda0, op=SAPI_HEADER_ADD,
    sapi_headers=0x7ff450f037b0)
    at /php-5.4.0RC6/sapi/apache2handler/sapi_apache2.c:124
    #1 0x00007ff450811414 in sapi_header_add_op (op=SAPI_HEADER_ADD,
    sapi_header=0x7fff9176cda0) at /php-5.4.0RC6/main/SAPI.c:618
    #2 0x00007ff450811e33 in sapi_send_headers () at
    /php-5.4.0RC6/main/SAPI.c:835
    #3 0x00007ff450791b10 in php_header () at
    /php-5.4.0RC6/ext/standard/head.c:68
    #4 0x00007ff45081d44c in php_output_op (op=0, str=0x7ff45779bac8
    "\nWarning: Module 'Phar' already loaded in Unknown on line 0\n", len=60)
    at /php-5.4.0RC6/main/output.c:1020
    #5 0x00007ff45081b993 in php_output_write (str=0x7ff45779bac8
    "\nWarning: Module 'Phar' already loaded in Unknown on line 0\n", len=60)
    at /php-5.4.0RC6/main/output.c:201
    #6 0x00007ff450802c55 in php_printf (format=0x7ff450c1d669 "%s\n%s: %s
    in %s on line %d\n%s") at /php-5.4.0RC6/main/main.c:673
    #7 0x00007ff45080410c in php_error_cb (type=32,
    error_filename=0x7ff450c32a0b "Unknown", error_lineno=0,
    format=0x7ff450c33132 "Module '%s' already loaded",
    args=0x7fff9176d200) at /php-5.4.0RC6/main/main.c:1089
    #8 0x00007ff45089267d in zend_error (type=32, format=0x7ff450c33132
    "Module '%s' already loaded") at /php-5.4.0RC6/Zend/zend.c:1082
    #9 0x00007ff45089aac8 in zend_register_module_ex
    (module=0x7ff44649de00) at /php-5.4.0RC6/Zend/zend_API.c:1832
    #10 0x00007ff45077da51 in php_load_extension (filename=0x7ff45779b008
    "phar.so", type=1, start_now=0)
    at /php-5.4.0RC6/ext/standard/dl.c:237
    #11 0x00007ff45080ed28 in php_load_php_extension_cb (arg=0x195cd40) at
    /php-5.4.0RC6/main/php_ini.c:351
    #12 0x00007ff450883763 in zend_llist_apply (l=0x7ff450ef6c78,
    func=0x7ff45080ed06 <php_load_php_extension_cb>)
    at /php-5.4.0RC6/Zend/zend_llist.c:193
    #13 0x00007ff45080f98b in php_ini_register_extensions () at
    /php-5.4.0RC6/main/php_ini.c:710
    #14 0x00007ff45080624c in php_module_startup (sf=0x7ff450ec0240,
    additional_modules=0x7ff450ec0380, num_additional_modules=1)
    at /php-5.4.0RC6/main/main.c:2193
    #15 0x00007ff4509cbd54 in php_apache2_startup
    (sapi_module=0x7ff450ec0240) at
    /php-5.4.0RC6/sapi/apache2handler/sapi_apache2.c:348
    #16 0x00007ff4509cbf08 in php_apache_server_startup (pconf=0x17c8168,
    plog=0x17fc308, ptemp=0x17d01a8, s=0x17ce968)
    at /php-5.4.0RC6/sapi/apache2handler/sapi_apache2.c:457
    #17 0x0000000000438d84 in ap_run_post_config ()
    #18 0x0000000000425bbc in main ()

    In 5.3 SAPI functions were not called for startup errors.

    I'm not going to fix it myself.

    Thanks. Dmitry.
  • Michael Wallner at Jan 25, 2012 at 5:03 pm

    On Wed, 25 Jan 2012 19:07:15 +0400, Dmitry Stogov wrote:

    Hi Stas,

    We've just found one more critical problem in 5.4.

    Apache/PHP crashes in case of error on startup, when
    display_startup_errors=1. It's probably related to new output API.

    I afraid it may affect many php users. ...
    In 5.3 SAPI functions were not called for startup errors.
    Thank you, I'm already looking into it.

    Regards,
    Mike
  • Stas Malyshev at Jan 25, 2012 at 5:13 pm
    Hi!
    We've just found one more critical problem in 5.4.

    Apache/PHP crashes in case of error on startup, when
    display_startup_errors=1. It's probably related to new output API.

    I afraid it may affect many php users.
    OK, thanks. Looks like we'd be needing another RC then. Let's fix this
    one and the __FILE__ crash in that case.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Michael Wallner at Jan 25, 2012 at 5:24 pm

    On Wed, 25 Jan 2012 09:13:43 -0800, Stas Malyshev wrote:

    Hi!
    We've just found one more critical problem in 5.4.

    Apache/PHP crashes in case of error on startup, when
    display_startup_errors=1. It's probably related to new output API.

    I afraid it may affect many php users.
    OK, thanks. Looks like we'd be needing another RC then. Let's fix this
    one and the __FILE__ crash in that case.
    Fix committed.

    Sorry & regards,
    Mike
  • Lior Kaplan at Jan 30, 2012 at 3:02 pm

    On Wed, 25 Jan 2012 09:13:43 -0800, Stas Malyshev wrote:
    Hi!
    We've just found one more critical problem in 5.4.

    Apache/PHP crashes in case of error on startup, when
    display_startup_errors=1. It's probably related to new output API.

    I afraid it may affect many php users.
    OK, thanks. Looks like we'd be needing another RC then. Let's fix this
    one and the __FILE__ crash in that case.
    Fix committed.
    The fix does work (thanks), but introduces another problem with scripts
    without output in FastCGI. The problem is that the headers aren't sent
    when there's no output from the script. If the script does produce an
    output then the headers are sent.

    should be reproducible with this simple script:

    <?php
    header("Location: http://www.google.com");

    Kaplan
    Zend Technologies Ltd.
  • Stas Malyshev at Jan 30, 2012 at 10:50 pm
    Hi!
    should be reproducible with this simple script:

    <?php
    header("Location: http://www.google.com");
    Could you check with a recent checkout? Looks like the last patch from
    Michael fixed that (at least it works for me).
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Yoram bar haim at Jan 30, 2012 at 3:29 pm
    I Debugged the issue described here by lior.
    the problem is :
    in php_request_shutdown() we call
    sapi_send_headers() after
    php_output_deactivate().

    at this point,
    in main/output.c,
    OG(flags) & PHP_OUTPUT_ACTIVATED is false so
    php_output_write_unbuffered() calls
    php_output_stderr() instead of
    sapi_module handler.

    the following patch solves the issue but It might be a wrong solution (because
    other thins are dependent on this order) so I'm not suggesting it as fix.

    --- main/main.c.orig 2012-01-30 17:25:44.000000000 +0200
    +++ main/main.c 2012-01-30 17:09:05.000000000 +0200
    @@ -1738,12 +1738,13 @@
    } else {
    php_output_end_all(TSRMLS_C);
    }
    + sapi_send_headers(TSRMLS_C);
    php_output_deactivate(TSRMLS_C);
    } zend_end_try();

    /* 4. Send the set HTTP headers (note: This must be done AFTER
    php_output_discard_all() / php_output_end_all() !!) */
    zend_try {
    - sapi_send_headers(TSRMLS_C);
    +/* sapi_send_headers(TSRMLS_C); */
    } zend_end_try();

    /* 5. Reset max_execution_time (no longer executing php code after
    response sent) */
  • Dmitry Stogov at Jan 30, 2012 at 3:42 pm
    Hi Mike,

    I confirm the bug. In case of empty output HTTP headers are sent to
    stdout or stderr instead of FastCGI stream.

    To reproduce I configured nginx to use PHP FastCGI server on UNIX
    socket, then launched (sapi/cgi/php-cgi -b /tmp/fcgi-php5) and performed
    several request to empty PHP file. The HTTP headers were printed in
    console running PHP.

    [dmitry@tpl2 CGI-DEBUG]$ sapi/cgi/php-cgi -b /tmp/fcgi-php5
    X-Powered-By: PHP/5.4.0RC7-dev
    Content-type: text/html

    X-Powered-By: PHP/5.4.0RC7-dev
    Content-type: text/html

    I afraid Yoram's patch is too radical and may have side effects.
    Mike, could you please think about a safer way of fixing.

    Thanks. Dmitry.

    On 01/30/2012 07:29 PM, yoram bar haim wrote:
    I Debugged the issue described here by lior.
    the problem is :
    in php_request_shutdown() we call
    sapi_send_headers() after
    php_output_deactivate().

    at this point,
    in main/output.c,
    OG(flags)& PHP_OUTPUT_ACTIVATED is false so
    php_output_write_unbuffered() calls
    php_output_stderr() instead of
    sapi_module handler.

    the following patch solves the issue but It might be a wrong solution (because
    other thins are dependent on this order) so I'm not suggesting it as fix.

    --- main/main.c.orig 2012-01-30 17:25:44.000000000 +0200
    +++ main/main.c 2012-01-30 17:09:05.000000000 +0200
    @@ -1738,12 +1738,13 @@
    } else {
    php_output_end_all(TSRMLS_C);
    }
    + sapi_send_headers(TSRMLS_C);
    php_output_deactivate(TSRMLS_C);
    } zend_end_try();

    /* 4. Send the set HTTP headers (note: This must be done AFTER
    php_output_discard_all() / php_output_end_all() !!) */
    zend_try {
    - sapi_send_headers(TSRMLS_C);
    +/* sapi_send_headers(TSRMLS_C); */
    } zend_end_try();

    /* 5. Reset max_execution_time (no longer executing php code after
    response sent) */
  • Yoram bar haim at Jan 30, 2012 at 3:47 pm
    As I sayed, my patch was not suggusted as fix, Dmitry is write about possible
    side effetcs, it was added only to prove that the problem is what we think it
    is.
    On Monday, January 30, 2012 05:42:11 PM Dmitry Stogov wrote:
    Hi Mike,

    I confirm the bug. In case of empty output HTTP headers are sent to
    stdout or stderr instead of FastCGI stream.

    To reproduce I configured nginx to use PHP FastCGI server on UNIX
    socket, then launched (sapi/cgi/php-cgi -b /tmp/fcgi-php5) and performed
    several request to empty PHP file. The HTTP headers were printed in
    console running PHP.

    [dmitry@tpl2 CGI-DEBUG]$ sapi/cgi/php-cgi -b /tmp/fcgi-php5
    X-Powered-By: PHP/5.4.0RC7-dev
    Content-type: text/html

    X-Powered-By: PHP/5.4.0RC7-dev
    Content-type: text/html

    I afraid Yoram's patch is too radical and may have side effects.
    Mike, could you please think about a safer way of fixing.

    Thanks. Dmitry.
    On 01/30/2012 07:29 PM, yoram bar haim wrote:
    I Debugged the issue described here by lior.
    the problem is :
    in php_request_shutdown() we call

    sapi_send_headers() after
    php_output_deactivate().

    at this point,
    in main/output.c,
    OG(flags)& PHP_OUTPUT_ACTIVATED is false so

    php_output_write_unbuffered() calls

    php_output_stderr() instead of
    sapi_module handler.

    the following patch solves the issue but It might be a wrong solution
    (because other thins are dependent on this order) so I'm not suggesting
    it as fix.

    --- main/main.c.orig 2012-01-30 17:25:44.000000000 +0200
    +++ main/main.c 2012-01-30 17:09:05.000000000 +0200
    @@ -1738,12 +1738,13 @@

    } else {

    php_output_end_all(TSRMLS_C);

    }

    + sapi_send_headers(TSRMLS_C);

    php_output_deactivate(TSRMLS_C);

    } zend_end_try();

    /* 4. Send the set HTTP headers (note: This must be done AFTER

    php_output_discard_all() / php_output_end_all() !!) */

    zend_try {

    - sapi_send_headers(TSRMLS_C);
    +/* sapi_send_headers(TSRMLS_C); */

    } zend_end_try();

    /* 5. Reset max_execution_time (no longer executing php code
    after

    response sent) */

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJan 25, '12 at 3:07p
activeJan 30, '12 at 10:50p
posts10
users5
websitephp.net

People

Translate

site design / logo © 2019 Grokbase