ID: 14637
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache2 related
Operating System: Solaris 8/x86
PHP Version: 4.1.0
New Comment:
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?
Previous Comments:
------------------------------------------------------------------------
[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
