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

go to bug id or search bugs for

Bug #28980 Certain PHP Scripts cause mod_php4 to duplicate buckets
Submitted: 2004-07-01 05:40 UTC Modified: 2004-07-08 01:26 UTC
From: joe at joe-lewis dot com Assigned:
Status: Not a bug Package: Apache2 related
PHP Version: 4.3.7 OS: FreeBSD 5.2-Release
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2004-07-01 05:40 UTC] joe at joe-lewis dot com 
Description:
------------
Using Apache 2.0.49 running under FreeBSD 5.2-Release :

I've used both the BSD Port (4.3.6) and the source code (4.3.6 and 4.3.7) in an attempt to isolate the issue.  However, each form has performed in the same manner.

I set up three scripts :  the first is a simple phpinfo() script, the second is a feedback script for sending E-Mail, and the third is a simple database script for managing automobile mileage.

If I do not run a third party module I have written, all three modules work fine (no extra output filters).  If I run a third party module (designed to wrap a template around the resulting HTML), the first two fail but the last works.  It appears that certain functions (which I have been unable to isolate) fail in the following manner :

My module begins to recieve duplicate buckets.  When it recieves a bucket, the bucket first returns a POOL bucket type.  It is followed by an unknown bucket type :

[Thu Jun 24 13:43:26 2004] [error] [client 207.173.156.19] mod_template: get_title() reading type name \x18\x10\n\b\x18\x80\x16\b\x18\xe0\x0e\b\x1c\x10\n\bxB\x16\b

However, the bucket brigade contains a series of buckets that appear to be exactly as preceding buckets when the problem occurs - causing my module to continue to copy and parse duplicates - this causes Apache 2.0 to produce the error message in the logs :

httpd in malloc(): error: allocation failed
[Wed Jun 23 18:42:01 2004] [notice] child pid 15011 exit signal Abort
(6)

The above should be assumed to occur because of the large memory growth.  gdb output is :My module begins to recieve duplicate buckets.  When it recieves a bucket, the bucket first returns a POOL bucket type.  It is followed by an unknown bucket type :

[Thu Jun 24 13:43:26 2004] [error] [client 207.173.156.19] mod_template: get_title() reading type name \x18\x10\n\b\x18\x80\x16\b\x18\xe0\x0e\b\x1c\x10\n\bxB\x16\b

It appears that either the mod_php4 is multiplying buckets or linking the tail of the brigade to a precedubg bucket, causing an endless loop on the bucket chain.

Reproduce code:
---------------
My module begins to recieve duplicate buckets.  When it recieves a bucket, the bucket first returns a POOL bucket type.  It is followed by an unknown bucket type :

[Thu Jun 24 13:43:26 2004] [error] [client 207.173.156.19] mod_template: get_title() reading type name \x18\x10\n\b\x18\x80\x16\b\x18\xe0\x0e\b\x1c\x10\n\bxB\x16\b

However, the bucket brigade contains a series of buckets that appear to be exactly as preceding buckets when the problem occurs - causing my module to continue to copy and parse duplicates - this causes Apache 2.0 to produce the error message in the logs :

httpd in malloc(): error: allocation failed

The above should be assumed to occur because of the large memory growth.  gdb output is :

Expected result:
----------------
There should NEVER occur duplicate buckets in using the Apache 2.0.49, or any Apache bucket filters. 

Actual result:
--------------
** APACHE LOG FROM 3RD PARTY MODULE **

If desired, I will rebuild the 3rd party module to print the contents of the bucket, (done before), but that fills my log files way too quickly.  On the following POOL type buckets, the buckets are repeated until the memory is consumed by the 3rd party module reading the duplicate buckets, and the POOL type bucket contents are exactly the same.  The current log data is :

[Thu Jun 24 13:43:26 2004] [error] [client 207.173.156.19] mod_template: get_title() reading type name POOL
[Thu Jun 24 13:43:26 2004] [error] [client 207.173.156.19] mod_template: get_title() reading type name \x18\x10\n\b\x18\x80\x16\b\x18\xe0\x0e\b\x1c\x10\n\bxB\x16\b
[Thu Jun 24 13:43:26 2004] [error] [client 207.173.156.19] mod_template: get_title() reading type name POOL
[Thu Jun 24 13:43:26 2004] [error] [client 207.173.156.19] mod_template: get_title() reading type name \x18\x10\n\b\x18\x80\x16\b\x18\xe0\x0e\b\x1c\x10\n\bxB\x16\b
[Thu Jun 24 13:43:26 2004] [error] [client 207.173.156.19] mod_template: get_title() reading type name POOL
[Thu Jun 24 13:43:26 2004] [error] [client 207.173.156.19] mod_template: get_title() reading type name \x18\x10\n\b\x18\x80\x16\b\x18\xe0\x0e\b\x1c\x10\n\bxB\x16\b
httpd in malloc(): error: allocation failed
[Wed Jun 23 18:42:01 2004] [notice] child pid 15011 exit signal Abort
(6)

** BACKTRACE **

#0  0x282cfd4f in kill () from /lib/libc.so.5
#1  0x282c47f8 in raise () from /lib/libc.so.5
#2  0x2833cf02 in abort () from /lib/libc.so.5
#3  0x2833b67e in tcflow () from /lib/libc.so.5
#4  0x2833bf1b in tcflow () from /lib/libc.so.5
#5  0x2833c2d6 in malloc () from /lib/libc.so.5
#6  0x2824f3db in allocator_alloc () from /usr/local/lib/apache2/libapr-0.so.9
#7  0x2824e350 in apr_palloc () from /usr/local/lib/apache2/libapr-0.so.9
#8  0x2823f46a in apr_pstrndup () from /usr/local/lib/apache2/libapr-0.so.9
#9  0x2855a52a in mod_template_get_title ()
   from /usr/local/libexec/apache2/mod_template.so
#10 0x2855a820 in template_wrapper ()
   from /usr/local/libexec/apache2/mod_template.so
#11 0x0807281c in ap_pass_brigade ()
#12 0x284f219c in lockname () from /usr/local/libexec/apache2/libphp4.so
#13 0x284b7630 in lockname () from /usr/local/libexec/apache2/libphp4.so
#14 0x284b69ea in lockname () from /usr/local/libexec/apache2/libphp4.so
#15 0x284b83b6 in lockname () from /usr/local/libexec/apache2/libphp4.so
#16 0x284b75ec in lockname () from /usr/local/libexec/apache2/libphp4.so
#17 0x284b69ea in lockname () from /usr/local/libexec/apache2/libphp4.so
#18 0x284b83b6 in lockname () from /usr/local/libexec/apache2/libphp4.so
#19 0x284b75ec in lockname () from /usr/local/libexec/apache2/libphp4.so
#20 0x284b6252 in lockname () from /usr/local/libexec/apache2/libphp4.so
#21 0x284a7dab in lockname () from /usr/local/libexec/apache2/libphp4.so
#22 0x284e16d6 in lockname () from /usr/local/libexec/apache2/libphp4.so
#23 0x284a7f11 in lockname () from /usr/local/libexec/apache2/libphp4.so
#24 0x28464bfb in lockname () from /usr/local/libexec/apache2/libphp4.so
#25 0x28465e5d in lockname () from /usr/local/libexec/apache2/libphp4.so
#26 0x284ed070 in lockname () from /usr/local/libexec/apache2/libphp4.so
#27 0x284db837 in lockname () from /usr/local/libexec/apache2/libphp4.so
#28 0x284a46c7 in lockname () from /usr/local/libexec/apache2/libphp4.so
#29 0x284f334b in lockname () from /usr/local/libexec/apache2/libphp4.so
#30 0x08065619 in ap_run_handler ()
#31 0x08065c94 in ap_invoke_handler ()
#32 0x08062459 in ap_process_request ()
#33 0x0805d347 in ap_process_http_connection ()
#34 0x0806fbc9 in ap_run_process_connection ()
#35 0x0806ff1e in ap_process_connection ()
#36 0x08063c33 in child_main ()
#37 0x08063d0c in make_child ()
#38 0x08063e52 in startup_children ()
#39 0x08064252 in ap_mpm_run ()
#40 0x0806b1b3 in main ()
#41 0x0805ce42 in _start ()

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-07-04 18:44 UTC] iliaa@php.net 
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

Unless this can be replicated with native Apache 2 modules 
this is not a PHP bugs.
 [2004-07-05 01:12 UTC] joe at joe-lewis dot com 
Wow.  What a closing response :

"Unless this can be replicated with native Apache 2 modules 
this is not a PHP bugs"

I know no-one (yes, I am a programmer) writes perfect code, but programmers should atleast realize there are problems.  I guess I just won't submit my patch because "it works for me" so it must not be needed by the rest of the world.

Thanks anyway.
 [2004-07-08 01:26 UTC] rasmus@php.net 
Leave this one as bogus.  In case anybody stumbles across this one in the bug db, the answer from Joe Orton:

You'd expect to get output like that if you don't stop iterating over the brigade when reaching the APR_BRIGADE_SENTINEL(bb); the sentinel pointer isn't a real bucket, so dereferencing it's ->type pointer would be expected to lead to garbage like the above.

Does that explain what's happening?  Each brigade which is filtered does not necessarily contain an EOS; the PHP handler for instance will indeed pass brigades containing a single POOL bucket up through the filter chain.

joe
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat May 04 21:01:32 2024 UTC