php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #18697 HTTPS POST crashing
Submitted: 2002-08-02 03:21 UTC Modified: 2002-10-27 18:57 UTC
From: glen at designsolution dot co dot uk Assigned:
Status: Not a bug Package: cURL related
PHP Version: 4.2.3 OS: Linux
Private report: No CVE-ID: None
 [2002-08-02 03:21 UTC] glen at designsolution dot co dot uk
I'm afraid this bug may be quite tricky to track down, but here goes:

This script:

$ch = curl_init();

curl_setopt( $ch, CURLOPT_URL, 'http://www.foo.com/test.php' );
curl_setopt( $ch, CURLOPT_FAILONERROR, 1 );
curl_setopt( $ch, CURLOPT_FOLLOWLOCATION, 1 );
curl_setopt( $ch, CURLOPT_TIMEOUT, 3 );	// times out after 4s
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );
curl_setopt( $ch, CURLOPT_POST, 1 );
curl_setopt( $ch, CURLOPT_POSTFIELDS, 'postvar1=php&postvar2=is&postvar3=great' );

$result = curl_exec( $ch );
curl_close( $ch );

echo "result = '$result'";

will work 9 out of 10 times with no problem at all.  However, occasionally it will crash Apache.  The line in the error log says 'child pid 2154 exit signal Segmentation fault (11)' and the browser will report 'The document contains no data'.

I will attempt to get a backtrace if this will help.

Here is my configure line:

 './configure' '--with-apxs=/usr/sbin/apxs' '--with-mysql=/usr/' '--with-gd=/usr/local' '--with-png-dir=/usr/local' '--with-zlib-dir=/usr' '--with-jpeg-dir=/usr/local' '--with-crack=../cracklib-2.7' '--with-curl=/usr/local' '--with-mcrypt=/usr/local' '--with-pspell=/usr/local'

My phpinfo reports curl support as:

libcurl 7.9.6 (SSL 0.9.3)

Thanks,

Glen





Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-08-02 19:05 UTC] sniper@php.net
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version 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.
Thank you for the report, and for helping us make PHP better.


..and update your CURL..

 [2002-09-09 03:31 UTC] glen at designsolution dot co dot uk
This is still happening with 4.2.3.  However, it only seems to occur when posting to HTTPS URL's.  I am using libcurl 7.9.8 (SSL 0.9.3)
 [2002-09-09 05:29 UTC] glen at designsolution dot co dot uk
I also have Zend Optimizer v2.0.0 installed - maybe this could be causing problems?
 [2002-09-09 05:31 UTC] derick@php.net
Well, just try it without...

Derick
 [2002-09-09 05:35 UTC] sniper@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.


 [2002-09-26 19:51 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2002-10-12 02:10 UTC] glen at designsolution dot co dot uk
For your information, this is with libcurl 7.9.8 (OpenSSL 0.9.6).  The crashes occur when POSTing to a https URL.  curl works fine from the command line.

Here is the backtrace output from gdb:

Starting program: /usr/sbin/httpd -X
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x4048e813 in RAND_add () from /usr/local/lib/libcurl.so.2
Cannot access memory at address 0x4000
 [2002-10-12 02:21 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


 [2002-10-12 03:05 UTC] glen at designsolution dot co dot uk
Tried CVS snapshop but got exactly the same crash:

(gdb) run -X
Starting program: /usr/sbin/httpd -X
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x40512813 in RAND_add () from /usr/local/lib/libcurl.so.2
Cannot access memory at address 0x4000
 [2002-10-12 09:46 UTC] sniper@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

As you can see, the bug is in curl itself.

 [2002-10-12 09:46 UTC] sniper@php.net
Compile curl also with debug symbols enabled..

 [2002-10-14 02:47 UTC] glen at designsolution dot co dot uk
Because this PHP/curl is on a production server with 200 websites, it's not that easy to get a chance to re-compile stuff without breaking scripts.

I will re-compile curl with debug symbols at some point over the next few days.

For your information:  a curl HTTPS POST works fine from the command line.
 [2002-10-15 06:25 UTC] daniel at haxx dot se
Being main libcurl author, I'd like to second sniper's request. Please rebuild libcurl with debug symbols and try again.

libcurl doesn't use the RAND_add() function itself, why that particular info unfortunately doesn't help in giving any clues here.
 [2002-10-27 18:57 UTC] sterling@php.net
my guess is that this is a symbol conflict with another library, either way, the backtrace indicates its not a PHP/cURL bug...
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 20:01:30 2024 UTC