#28980 [Bgs->Csd]: Certain PHP Scripts cause mod_php4 to duplicate buckets

2004-07-04 Thread joe at joe-lewis dot com
 ID:   28980
 User updated by:  joe at joe-lewis dot com
 Reported By:  joe at joe-lewis dot com
-Status:   Bogus
+Status:   Closed
 Bug Type: Apache2 related
 Operating System: FreeBSD 5.2-Release
 PHP Version:  4.3.7
 New Comment:

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.


Previous Comments:


[2004-07-04 18:44:36] [EMAIL PROTECTED]

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-01 05:40:31] 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
[Th

#28980 [NEW]: Certain PHP Scripts cause mod_php4 to duplicate buckets

2004-06-30 Thread joe at joe-lewis dot com
From: joe at joe-lewis dot com
Operating system: FreeBSD 5.2-Release
PHP version:  4.3.7
PHP Bug Type: Apache2 related
Bug description:  Certain PHP Scripts cause mod_php4 to duplicate buckets

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/ap

#17868 [Com]: Doesn't work two and more directives of PHP code on different OS

2003-05-29 Thread joe at joe-lewis dot com
 ID:   17868
 Comment by:   joe at joe-lewis dot com
 Reported By:  messiah at hotbox dot ru
 Status:   Closed
 Bug Type: Apache2 related
 Operating System: *
 PHP Version:  4.3.0-dev
 New Comment:

Is this apxs2 an apache configuration option or a php option?  I am
using apache 2.0.45, with php 4.3.1, and am still encountering the
error.  I have tried
  --with-apxs2handler=/usr/local/bin/apxs
and
  --with-apxs2filter=/usr/local/bin/apxs
in both PHP and Apache, with no successes.  In fact, now (though my
configuration is good), any PHP page is not executed or parsed, but
returned as type x-httpd-php, which is "somewhat" operational (i.e. it
has the right type, but the libphp4 module is not being called as
specified in my httpd.conf file).


Previous Comments:


[2003-02-13 09:40:43] lists at holsman dot net

RE: apache2 & php developers not working together.

I agree.
infact 2 apache2 developers spent a couple of hours and created a new
php/apache2 sapi interface, and It would be great if you could give it
a try and send some feedback

if you could try the --with-apxs2handler instead of --with-apxs2 this
might help. this uses the standard handler mechanism, and not the
filter API. 

look forward to hearding how it goes.
Ian



[2003-02-12 13:54:03] [EMAIL PROTECTED]

Both.



[2003-02-12 13:50:53] Darryl dot Friesen at usask dot ca

When you say "This bug has been fixed in CVS" do you mean 4.3.x-dev or
5.0.x-dev?



[2003-01-28 10:35:24] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.





[2003-01-21 13:11:16] mike_tharp at hermanmiller dot com

I have run accross this as well on IIS5 and Win2k so it isn't limited
to just Apache. 

Going back to PHP 4.2.3 resolves the issue but 4.3.0 will only
acknowledge the first include and then page halts loading when the
second is encountered.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17868

-- 
Edit this bug report at http://bugs.php.net/?id=17868&edit=1