On Sat, 24 Feb 2007, Pedro Larroy Tovar wrote:

> Core was generated by `./curl_fd_leak_test'.
> Program terminated with signal 11, Segmentation fault.
> #0 0xb7f06dd1 in Curl_setopt (data=0x13131313, option=CURLOPT_HTTPGET, param=0xbf90735c "dt\2200\r\005\b")
> at url.c:1014

You call this function with a bad first argument, clearly.

> #2 0x0804a18f in Curl_handles::process_handles (this=0xbf907420) at
> curl_fd_leak_test.cc:189

This is line 187 in the test file you sent us, and this is using a pointer in
a freed memory area.

curl_multi_info_read() returns a pointer that "will not survive calling
curl_multi_cleanup(3), curl_multi_remove_handle(3) or curl_easy_cleanup(3)."

In other words, on line 174 that 'msg' pointer points to freed memory. Hence
the 13131313 (which is libcurl's internal memory debug system's way of filling
areas just before it frees them).

> Is not possible to reuse the handler for doing a GET request after a HEAD
> request?

It is.

> Also, this program should be able to reproduce the fd leakage, since I only
> could avoid it with the commented out code that reinitializes the easy
> handler after GET is finished

I failed to build the test program though. I'm really not a C++ kind of guy...

curl_fd_leak_test.cc:5:32: error: boost/shared_ptr.hpp: No such file or
directory

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html