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

go to bug id or search bugs for

Bug #58528 Requests not removed from multi stack when fatal errors occur
Submitted: 2009-01-29 15:28 UTC Modified: 2009-02-12 11:51 UTC
From: james82 at gmail dot com Assigned: mike (profile)
Status: Closed Package: pecl_http (PECL)
PHP Version: 5.2.5 OS: CentOS 5
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: james82 at gmail dot com
New email:
PHP Version: OS:

 

 [2009-01-29 15:28 UTC] james82 at gmail dot com 
Description:
------------
If a fatal error occurs in a fastcgi application after we 
have initialized a request pool and attached a request to 
it, the request will never be detached from the multi pool. 
This results in subsequent requests failing with the 
exception "Could not attach HttpRequest object(#172) to the 
HttpRequestPool: Invalid easy handle".

One way to fix this would be to update pecl_http to properly 
detach requests from the multi pool when a fatal error is 
thrown. This could be achieved via a RSHUTDOWN handler, I 
believe.



Reproduce code:
---------------
$pool = new HttpRequestPool();
$pool->attach(new HttpRequest("http://localhost"));
throw new FatalError("Break pecl_http");
# NOTE: FatalError class does not exist, so above code throws a Fatal error due to the syntax error



Expected result:
----------------
The application should throw the following exception every 
time: "PHP Fatal error:  
Class 'FatalError' not found"



Actual result:
--------------
The first time the above application is run via fastcgi, the 
correct error is thrown: 
"PHP Fatal error:  Class 'FatalError' not found". However, 
in subsequent requests, a 
different error is thrown: "HttpRequestPoolException : Could 
not attach HttpRequest 
object(#172) to the HttpRequestPool: Invalid easy handle".

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-02-11 11:21 UTC] mike@php.net 
Cannot reproduce.  Do you override HttpRequestPool::__destruct()?
 [2009-02-11 13:28 UTC] james82 at gmail dot com 
Hi Mike,

I don't override __destruct. The above script is enough to reproduce the bug. I am using CentOS 5 / 64-bit. Do you have persistent connections enabled?

To make the issue easier to reproduce, use the following settings:
  1. Setup PHP to have only one thread.
  2. Make sure that persistent connections are enabled.
  3. Access the fatal error script (shown above) via FastCGI 10-100 times. It does not matter what fatal error is thrown as long as a fatal error is thrown.
  4. Before long, the FastCGI script starts throwing "Invalid easy handle" errors when you try to attach the HttpRequest to the HttpRequestPool.

NOTE: If persistent connections are disabled, this problem does not occur. So I suspect the issue here has to do with some cleanup that needs to be done regarding persistent connections.
 [2009-02-12 11:50 UTC] mike@php.net 
This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.
 [2009-02-12 11:51 UTC] mike@php.net 
This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 18 17:01:28 2024 UTC