#32919 [Sus]: Curl/Openssl: random crashes with fsockopen("ssl://.."..) under heavy load

ID: 32919 User updated by: justincouto at msn dot com Reported By: justincouto at msn dot com Status: Suspended Bug Type: IIS related Operating System: Windows 2003 Server PHP Version: 5.0.4 New Comment: I solved this problem myself. It works perfectly in a production environment. I had to eliminate curl by writing a replacement class to post programatically. I also had to work around using ssl via php. I ended up writing a ASP.Net wrapper for my secure posts. It works great. If your are interested in my services let me know. Previous Comments: ------------------------------------------------------------------------ [2005-08-01 12:14:21] jack at krazyboyz dot co dot za We are experiencing this bug on a different version of php (4.3.9) but upgrading seems won't fix it. Is there any work being done to fix this issue??, its pretty critical.. It looks like its dependent on the current load of the IIS server where it causes the access violation when there is heavy load on the system when opening an fsock socket via ssl. ------------------------------------------------------------------------ [2005-06-22 10:31:54] sniper@php.net Curl and openssl work just fine, as long as you don't use IIS.. ------------------------------------------------------------------------ [2005-06-03 18:00:36] justincouto at msn dot com I have already been working with the Zend people, and I helped them discover a bug in the Win Enabler for PHP5. Consequently, they removed support for PHP5 in the WinEnabler until they have time to fix the bug, which apparetly won't be anytime soon. This problem is deffinately a threading issue with Curl and OpenSSl. I came up with a work-around that allowed me to drop-out the OpenSSL module. I do this by connection to a local ASP.NET script and let it hanlde the requests. It works perfect now and is stable. I do use the MySQLi module and it handles threading just fine. Those of you running windows and php, you will not be able to use Curl or Open SSL. ------------------------------------------------------------------------ [2005-06-03 15:30:06] wez@php.net This sounds like a threading related crash; we don't have the resources to debug it, so if the latest snapshots don't solve the problem for you, you should go with fastcgi. The fastcgi core of the WinEnabler *is* compatible with PHP 5, and that's the part you need. Hopefully the Zend folks will guide you through setting it up with PHP 5. ------------------------------------------------------------------------ [2005-05-11 03:28:50] justincouto at msn dot com I have done more work on trying to figure out the source of this bug. I realized that it seemed to be happening in in all the places that we were using the Curl module for Posting to web services. As a result, I wrote a php socket class to replace curl. The new class eliminated the problem in all places except where it needs to use the OpenSSL module. It seems as if both Curl and the Openssl module have issues. I can reproduce the problem. It occurs with using a socket as follows: $handle = fsockopen($this->host, $this->port, $errno, $errstr, $timeout = 30); I have deffinately narrowed the issue to this line of code. The host and port are set as follows $this->host = "ssl://somehost.com"; $this->port = 443; The reason I know it is the ssl part of the connection is becuse I can use the class to connect to non ssl connection at the same time the access violation is happening. The access violation only occurs on a heavly load (when lots of requests through a secure fsockopen) It seems if it could have something to do with the openssl threading. I also think this because the CLI or CGI version won't reporduce this issue. Please advise. If you know of any other way to do a secure socket connection that doesn't use openssl or curl, it would be helpful for me to get a qucik fix. Thanks, ------------------------------------------------------------------------ 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/32919 -- Edit this bug report at http://bugs.php.net/?id=32919&edit=1