|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #14637 Apache 2.0 filter and PHP 4 crash
Submitted: 2001-12-21 04:24 UTC Modified: 2002-04-15 14:26 UTC
Avg. Score:5.0 ± 0.0
Reproduced:4 of 4 (100.0%)
Same Version:2 (50.0%)
Same OS:0 (0.0%)
From: jerenkrantz at apache dot org Assigned:
Status: Closed Package: Apache2 related
PHP Version: 4.1.0 OS: Solaris 8/x86
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
17 + 47 = ?
Subscribe to this entry?

 [2001-12-21 04:24 UTC] jerenkrantz at apache dot org
Current HEAD of both httpd-2.0 and PHP4.  Clean compile.

% uname -a                                           
SunOS 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' \

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


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-04-10 13:23 UTC] jailbird at alcatraz dot fdf dot net
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
 [2002-04-10 13:43 UTC] jailbird at alcatraz dot fdf dot net
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-12 20:24 UTC]
Can you please try and see if PHP 4.2.0RC3 works any better:

 [2002-04-15 14:05 UTC] jailbird at alcatraz dot fdf dot net
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!
 [2002-04-15 14:26 UTC]
We close this as it's fixed.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri May 24 19:01:29 2024 UTC