php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #19301 curl_exec crashes
Submitted: 2002-09-09 01:39 UTC Modified: 2002-10-27 18:55 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: honza at honza dot info Assigned: jmoore (profile)
Status: Not a bug Package: cURL related
PHP Version: 4.2.3 OS: Windows XP Professional CZ
Private report: No CVE-ID: None
 [2002-09-09 01:39 UTC] honza at honza dot info
Hello,

I'm a newbie to PHP, so it may be something wrong on my side. But I checked the problem, reproduced it many times so here I send it.

I replicated the problem many times in Windows XP Professional CZ, which I use as my operating system. I also have a separate instalation of Windows 2000 Professional CZ SP2, which I use for my full time job, and I replicated the problem there as well. While there is a lot of software installed on my WinXP system, the Win2000 system was completely clean (I was reinstalling the system for new project), so there was just Win2000 Pro CZ SP2 and PHP 4.2.3 on the system, nothing more. The only difference was the crash dialog it produced: under Win2k it was the dialog "Error in program: php.exe generated errors and so Windows closed it. It is neccessary to restart the program. Generating error protocol. OK button", while WinXP give the dialog of "Error occured in php.exe application and it is necessary to close it. We are apologizing for caused problems. ... Report the problem to Microsoft ... Send the report button and Don't send button" (please note that I use the Czech localization of Windows and here I translated back the messages from the dialogs in Czech language in my Windows into English, so the original texts may differ).

What I did: I copied the example featured at curl_init function documentation to a file, and changed the url, so it is now:

<?php

$ch = curl_init ("http://www.ebay.com");
$fp = fopen ("output/result.txt", "w");

curl_setopt ($ch, CURLOPT_FILE, $fp);
curl_setopt ($ch, CURLOPT_HEADER, 0);

curl_exec ($ch);
curl_close ($ch);
fclose ($fp);
?>

This simple code crashes with dialogs mentioned above. It always crashes, I had no successfull run.

Note 1: Commenting the lines (using //) in the source I came to the result that the crashing function is curl_exec(). Other functions work OK. If I comment only the line with curl_exec() and nothing more, the script will successfully run.

Note 2: I uncommented the php_curl.dll in php.ini, the extension is allowed (I tried the script with the extension left commented, and then it fails on line with curl_init() function).

Note 3: The extension_dir in php.ini is set to proper location. I tried it set to wrong dir and it produced errors on curl_init() function.

Note 4: It crashes no matter if it is run from DOS-prompt using php.exe, php-cli.exe or via web server (IIS).

Note 5: When run through IIS the "output" directory has the write allowed, and the file "result.txt" is created. As curl_exec fails, the file "result.txt" is left of 0 lenght.

Note 6: Although I didn't see it mentioned in the install documentation for Windows, before getting into this crashing problem I got a report that "libeay32.dll cannot be loaded". Of course adding php-install-dir/dlls into PATH env variable helped. I think it would be good to add this into install documentation.

OK, that's all for now. Tomorrow I'll try it on different machines (although they will all be Windows, but simply up-to-date I tried it only on one computer, just different systems) and I'll report if it behaves the same in there as well.

Thanx. Honza

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-09-09 05:52 UTC] honza at honza dot info
OK, there are important news: I downloaded the older PHP 4.1.2 and checked it there, and it works. The example that crashed in 4.2.3 works without a problem in 4.1.2. Hope this information helps, now I'll keep 4.1.2 until it gets corrected.

Honza
 [2002-09-09 05:59 UTC] sniper@php.net
Just a thought..but did you have some older PHP installed in this machine before you installed 4.2.3?

If so, make sure you replace ALL the existing files with the ones found in the new version. Most important one being php4ts.dll 

 [2002-09-09 07:28 UTC] honza at honza dot info
Nope, PHP 4.3.2 was the first to get into the system. As I said, I even tested it on clean system (Win2000ProCZ) where nothing else got installed, not even web server (from W2000 i tried it only as php.exe executable), and it gave me the crash on a clean system as well.

Honza
 [2002-09-09 07:30 UTC] honza at honza dot info
Ooops, I wanted to write 4.2.3, not 4.3.2.

Honza
 [2002-09-09 07:38 UTC] sniper@php.net
This is propably some win32 issue since I can not reproduce this with PHP 4.2.3 / PHP 4.3.0-dev on Linux.

 [2002-09-12 03:03 UTC] kja at filanet dot dk
Same issue was reported against PHP 4.2.1 in bug 17782. I can see that bug has been thought to be solved as it wasn't reproducible on Linux. 
Apparenly not the case. It must be a Windows only issue with CURL.

The offending code is the functionality enabled with
curl_setopt ($ch, CURLOPT_FILE, $fp);
with that line enabled curl_exec() crashes (application error/GPF) both when running PHP from commandline and as module under Apache 1.3.26
Disabling above line with CURLOPT_FILE it works, but that is not very usefull in my case as I need CURLOPT_FILE :-)

I assume the developer responsible for php_curl.dll (or someone else) will be able to debug this on Windows?

From my point of view this issue is beginning to get a bit critical, so I wouldn't mind to see a quick solution....
 [2002-09-23 04:52 UTC] tomas dot rollo at grafton dot cz
It seems the bug doesn't affect only WinNT/2K/XP systems but it's also reproductible on Win98SE.
 [2002-09-24 08:41 UTC] daniel at haxx dot se
Could this be related to how Windows DLLs vs apps works?

In Windows, you can't open a file and pass the handle of that file to have it read from or written to in a DLL. They somehow don't allow that kind of data to be shared like that.

It seems as if it could be, the PHP code opens the file and passes the handle to the DLL that deals with it...

Just my thoughts. I might be completely wrong.
 [2002-09-24 09:23 UTC] wez@php.net
Could you try to reproduce this with a non-stable snapshot?
http://snaps.php.net/win32/php4-win32-latest.zip


 [2002-09-25 04:12 UTC] kja at filanet dot dk
Have just tried that on Win2K. The problem still exists, both when running php as standalone and sapi module under Apache 1.3.26
 [2002-09-25 04:19 UTC] jmoore@php.net
Ill have a look at this on friday and see if I can reproduce this and get a stack trace then hopefully fix it.

If anyone wants a play before hand then they are welcome to.

- James
 [2002-09-28 04:50 UTC] jmoore@php.net
OK just built Debug and Release versions of Curl (Curl-7.9.8) (NON-SSL) and the same of the PHP Extension from the latest CVS and cannot reproduce this bug in the latest versions. 

The crash no longer happens. Although it is reproduceable with PHP-4.2.3 which was downloadable from PHP.net. You can download the version I tested this with (Only got php_curl.dll & libcurl.dll accompanying it) from

http://www.phpuk.org/~james/latest-cvs-with-curl.zip.

Please let me know if the problem persists with you in this build.

- James


 [2002-09-30 04:32 UTC] kja at filanet dot dk
I just tried your latest-cvs-with-curl build and yes that is also working for me. 
However, the latest non-stable snapshot http://snaps.php.net/win32/php4-win32-latest.zip (dated 20020929) is still failing and I would have thought that was the same code as you tested, or is there just some latency from CVS to the latest non-stable builds?
 [2002-09-30 15:45 UTC] jmoore@php.net
mine was latest CVS on the date I posted it, it might be a bug in curl which is casuing the crash and the machine which is doing the snap shot builds is using an older version.

Ill find out and get that updated if that is the case.

CLosing this bug for now as it seems a tertary problem rather than a PHP one.

- James
 [2002-09-30 17:09 UTC] jmoore@php.net
reopening as snaps system uses latest release of curl.

- James
 [2002-09-30 17:21 UTC] edink@php.net
I've manged to get a backtrace using the latest CVS version:

It crashes in ext/curl/curl.c:313

NTDLL! 77f83941()
NTDLL! 77f838c6()
curl_write(char * 0x011607d9, unsigned int 0x00000001, unsigned int 0x0000048b, void * 0x00dcd248) line 313 + 25 bytes
PHP_CURL! Curl_client_write + 54 bytes
PHP_CURL! Curl_readwrite + 3191 bytes
PHP_CURL! Curl_perform + 1135 bytes
PHP_CURL! Curl_perform + 120 bytes
PHP_CURL! curl_easy_perform + 33 bytes
zif_curl_exec(int 0x00dcc190, _zval_struct * 0x00db2780, _zval_struct * 0x0012fe04, int 0x00001000, void * * * 0x7ffdf000) line 921 + 11 bytes
zend_execute_scripts(int 0x00000008, void * * * 0x00db2780, _zval_struct * * 0x00000000, int 0x00000003) line 834 + 34 bytes
php_execute_script(_zend_file_handle * 0x0012ff48, void * * * 0x00db2780) line 1537 + 27 bytes
main(int 0x00000003, char * * 0x00db4f78) line 1055 + 17 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e8d326()

 [2002-10-27 18:55 UTC] sterling@php.net
not a php bug...
 [2002-10-28 04:29 UTC] kja at filanet dot dk
Sterling, just a little curious: What made you conclude "not a php bug"?
From the stack trace it looked like it was a call from php that caused the OS to choke. Sure, that could just be another Win "feature", but what is then the change between php 4.1.2 and 4.2.x that have caused this?
Thanks!
 [2003-06-29 06:04 UTC] DCC_CAMPBELL at YAHOO dot COM
Just curious, was this ever resolved?  I am currently working on install phpmysearch utility on my site under windows XP, Apache 2.0.39, PHP 4.2.2.  When I attempt to utilize the search builder (spider), Apache crashes.  I believe it is related to the call from PHP to Curl but I am unsure.  When I get the 'send error to microsoft' if I check detail it specifies a NTDLL.DLL.  Rather odd.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Sat Dec 07 12:01:23 2019 UTC