php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #14637 Apache 2.0 filter and PHP 4 crash
Submitted: 2001-12-21 04:24 UTC Modified: 2002-04-15 14:26 UTC
Votes:6
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 Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: jerenkrantz at apache dot org
New email:
PHP Version: OS:

 

 [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 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
jerenkrantz@apache.org

Patches

Pull Requests

History

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] sniper@php.net 
Can you please try and see if PHP 4.2.0RC3 works any better:

http://www.php.net/~derick/
 [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] derick@php.net 
We close this as it's fixed.

Derick
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Jan 17 01:01:30 2025 UTC