ID: 14637 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Apache2 related Operating System: Solaris 8/x86 PHP Version: 4.1.0 New Comment:
Apache/2.0.35 (Unix) mod_ssl/2.0.35 OpenSSL/0.9.6b DAV/2 PHP/4.2.0RC4 Rock on.. it works like a champ now. No SIGSEGV's or SIGBUS's on phpinfo() or any in-house script I've thrown at it. Before, just about any script would cause a httpd process to die. Thanks a million! Previous Comments: ------------------------------------------------------------------------ [2002-04-12 20:24:14] [EMAIL PROTECTED] Can you please try and see if PHP 4.2.0RC3 works any better: http://www.php.net/~derick/ ------------------------------------------------------------------------ [2002-04-10 13:43:57] [EMAIL PROTECTED] Okay.. here's some more info... APR_BRIGADE_CONCAT is #define'd in apache's srclib/apr-util/include/apr_buckets.h as a macro to APR_RING_CONCAT(&(a)->list, &(b)->list, apr_bucket, link) APR_RING_CONCAT itself is another macro to APR_RING_SPLICE_BEFORE and APR_RING_INIT, but that's another story.. Anyways... a "print saveto->list" in gdb reports: Cannot access memory at address 0x10 This address is always the same. Seems like something is screwing-up saveto->list? The wierd part is if I set a breakpoint on util_filter.c:562 and manually 'continue' each time, then it doesn't crash. As soon as I remove the breakpoint, it'll SIGSEGV. Almost seems like a race condition? ------------------------------------------------------------------------ [2002-04-10 13:23:07] [EMAIL PROTECTED] I'm having the same problem using CVS snapshots of both Apache 2 and PHP 4 from today. Test case: phpinfo(); (can't get much simpler than that). Solaris 8/Sparc + recommended patches gcc 2.95.4 prerelease (happens w/ gcc 2.95.3 also) Side note: This PHP snapshot works fine w/ Apache 1.x, and this Apache 2 snapshot works fine if I pull normal .html files. So it seems to be in the combo of Apache 2 + PHP 4. CFLAGS were: -O0 -w -g3 Program received signal SIGSEGV, Segmentation fault. 0xea304 in ap_save_brigade (f=0x2dcff8, saveto=0x2dbf24, b=0xffbef080, p=0x2db5c0) at util_filter.c:562 562 APR_BRIGADE_CONCAT(*saveto, *b); (gdb) bt #0 0xea304 in ap_save_brigade (f=0x2dcff8, saveto=0x2dbf24, b=0xffbef080, p=0x2db5c0) at util_filter.c:562 #1 0xfe318840 in php_output_filter (f=0x2dcff8, bb=0x2dd100) at /export/home/dmarques/php4/sapi/apache2filter/sapi_apache2.c:354 #2 0xea178 in ap_pass_brigade (next=0x2dcff8, bb=0x2dd100) at util_filter.c:534 #3 0xf821c in default_handler (r=0x2db5f8) at core.c:3247 #4 0xd1738 in ap_run_handler (r=0x2db5f8) at config.c:193 #5 0xd232c in ap_invoke_handler (r=0x2db5f8) at config.c:373 #6 0x86598 in ap_process_request (r=0x2db5f8) at http_request.c:261 #7 0x7e698 in ap_process_http_connection (c=0x2d5650) at http_core.c:291 #8 0xe5c78 in ap_run_process_connection (c=0x2d5650) at connection.c:85 #9 0xe622c in ap_process_connection (c=0x2d5650, csd=0x2d5580) at connection.c:207 #10 0xcecfc in child_main (child_num_arg=0) at prefork.c:671 #11 0xcee50 in make_child (s=0x202328, slot=0) at prefork.c:711 #12 0xcf020 in startup_children (number_to_start=2) at prefork.c:783 #13 0xcf710 in ap_mpm_run (_pconf=0x14f8b0, plog=0x1979d0, s=0x202328) at prefork.c:999 #14 0xd9854 in main (argc=2, argv=0xffbef7a4) at main.c:622 ------------------------------------------------------------------------ [2001-12-21 04:24:19] [EMAIL PROTECTED] Current HEAD of both httpd-2.0 and PHP4. Clean compile. % uname -a SunOS scotch.ucf.ics.uci.edu 5.8 Generic_108529-12 i86pc i386 i86pc './configure' \ '--with-apxs2=/pkg/apache-2.0-cvs/bin/apxs' \ '--with-pgsql=/pkg/postgresql-7.0.2' \ '--with-ispell=/pkg/ispell-3.1' \ '--with-zlib' \ '--with-ldap=/pkg/openldap-2.0.11' \ '--with-openssl=/pkg/openssl-0.9.6b' This is for a vhost site that I run, so I'm not really at liberty to provide the script. I can ask the user if I can pass along the script, but it isn't mine, so I don't really want to do it without authorization. Back trace: (gdb) bt #0 0x80f4423 in ap_save_brigade (f=0x86652f8, saveto=0x852e0a4, b=0xde405b3c, p=0x8536630) at util_filter.c:416 #1 0xdf597be1 in php_output_filter (f=0x86652f8, bb=0x8665448) at sapi_apache2.c:350 #2 0x80f433d in ap_pass_brigade (next=0x86652f8, bb=0x8665448) at util_filter.c:388 #3 0x80fca7e in default_handler (r=0x8536668) at core.c:2824 #4 0x80e62f0 in ap_run_handler (r=0x8536668) at config.c:185 #5 0x80e6a2e in ap_invoke_handler (r=0x8536668) at config.c:360 #6 0x80b0866 in ap_process_request (r=0x8536668) at http_request.c:292 #7 0x80ab8db in ap_process_http_connection (c=0x8910b68) at http_core.c:280 #8 0x80f2100 in ap_run_process_connection (c=0x8910b68) at connection.c:84 #9 0x80f24dc in ap_process_connection (c=0x8910b68) at connection.c:229 #10 0x80e3264 in process_socket (p=0x8910a48, sock=0x8910a80, my_child_num=1, my_thread_num=4) at worker.c:565 #11 0x80e37c1 in worker_thread (thd=0x8257c40, dummy=0x836fe18) at worker.c:782 #12 0xdfb49900 in dummy_worker (opaque=0x8257c40) at thread.c:122 (gdb) down #1 0xdf597be1 in php_output_filter (f=0x86652f8, bb=0x8665448) at sapi_apache2.c:350 350 ap_save_brigade(f, &ctx->bb, &bb, f->r->pool); (gdb) print *ctx $29 = {state = 761820026, bb = 0x2e312e33, f = 0x86652f8, post_len = 0, post_idx = 139649336, post_data = 0x852e0f8 ""} It looks like the ctx is getting corrupted somehow (or is it initially non-null?). I don't know enough about PHP4 and SAPI to track this down further. So, I'll file a bug report... I see that PHP4 is a little different than the rest of the Apache 2.0 modules in that it attempts to keep a unified context (i.e. SG(server_context)). This is somewhat different than other modules - as httpd-2.0 is providing a ctx on a per-request level (in f->ctx). It's not impossible to do it this way - mod_ssl has a similar connection-based context. But, it makes it harder to manage. Email me if you have any questions, Justin Erenkrantz [EMAIL PROTECTED] ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=14637&edit=1
