ID: 12018 Updated by: stas Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: cURL related Operating System: Debian (2.4.5) PHP Version: 4.0.6 Assigned To: stas New Comment: Fix committed to the CVS Previous Comments: ------------------------------------------------------------------------ [2001-07-17 07:13:24] [EMAIL PROTECTED] I think I know what's the problem. ------------------------------------------------------------------------ [2001-07-15 19:17:50] [EMAIL PROTECTED] After a few patches from Sterling (thanks), I no longer see the memory leak messages in the apache error log, and all the curl_exec() calls seem to work okay. But: The setting of CURLOPT_HEADER is treated oddly. Specifically, when you ask for no HTTP header, it returns one. When you do ask for one, it returns one, with each line duplicated. To see what I mean go here: http://devel.easydns.com/~cmv/curltest/phpnet.php?header=0 http://devel.easydns.com/~cmv/curltest/phpnet.php?header=1 The value of $header is passed to curl_setopt($ch, CURLOPT_HEADER, $header). You can see the duplicatation. Sterling has emailed me that he won't be able to look at this for a week or more ... so I'm hoping one of the other developers who is familiar with this extension can take a quick boo and see if it's an easy fix. My C is limited, but I'm wondering if an extra condition is needed to the if statement on line 378 of curl.c ... something like: int get_header; curl_easy_getinfo(ch->cp, option, &get_header); if (get_header && ch->handlers->write->method == PHP_CURL_RETURN) { ... - Colin ------------------------------------------------------------------------ [2001-07-10 11:49:33] [EMAIL PROTECTED] Okay, I recompile PHP with --enable-debug, so I could get a backtrace. Now the problem goes away. :/ This is good for me, but must indicate something weird in the cURL implementation, no? - Colin ------------------------------------------------------------------------ [2001-07-10 11:45:56] [EMAIL PROTECTED] Every script I have that uses cURL never makes it past the curl_exec() line. Apache just seems to die at that point. Apache error log shows: [Tue Jul 10 11:43:40 2001] [notice] child pid 27769 exit signal Segmentation fault (11) [Tue Jul 10 11:43:40 2001] [notice] child pid 27768 exit signal Segmentation fault (11) This is with PHP-4.0.6 Release, and cURL 7.8 final, on Debian (2.4.5-pre3). cURL is configured: configure --with-ssl PHP is: ./configure \ --with-mysql=/usr/local \ --with-apxs=/usr/local/apache/bin/apxs \ --enable-track-vars \ --disable-magic-quotes \ --disable-debug \ --enable-ftp \ --with-gettext \ --with-xml \ --with-dom \ --enable-wddx \ --with-curl \ --with-pgsql \ --with-zlib \ --enable-versioning \ --enable-sockets \ --with-openssl \ --with-snmp \ --with-mcrypt I was able to determine the following: I have one script that cURL-posts to another URL on the same server, and that script then cURL-posts to a URL outside. In this case, the first script dies. I have another script that directly cURL-posts to the outside URL. This script works fine. So it only seems to die if there are 2 cURL processes running on the same server simultaneously (?). This would explain the 2 segfaults in the Apache log. Let me know what other info I can give to help track down the problem. - Colin ------------------------------------------------------------------------ Edit this bug report at http://bugs.php.net/?id=12018&edit=1 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
