cURL / Mailing Lists / curl-library / Single Mail


Fwd: Segfault when downloading multiple sftp files in parallel

From: Gou Lingfeng <>
Date: Wed, 29 Jun 2016 17:21:55 +0800

I'm using the newest release (7.49.1).

Overall procedure:
1. create a curl_multi handle.
2. create 4 curl_easy handles and add them to the curl_multi handle.
3. run till all are downloaded.
4. remove the 4 curl_easy handles.
5. create and add 2 curl_easy handles.
6. run till all are downloaded.
7. remove the 2 curl_easy handles.
8. goto step 5.

In step 3, 4 connections are created (and not closed in step 4).
In step 6, 2 connections are reused, with the other 2 left alone.
Connections that are not used for a long time might get pruned.
Just before the segfault, in step 6, three things happen (in function
  A. ``setup_connection_internals`` (line 6039) calls
``conn->handler->setup_connection`` and allocates ``data->req.protop``.
  B. ``prune_dead_connections`` (line 6116) sees dead connections and
``conn->handler->disconnect`` deallocates ``data->req.protop``.
  C. A cached (not dead) connection is reused and ``data->req.protop`` is

My guess is that connections and session handles highly depend on one
another (connection and disconnection need session data), but connection
reusing needs some independence of connections.

---------- Forwarded message ----------
From: Daniel Stenberg <>
Date: Wed, Jun 29, 2016 at 2:38 AM
Subject: Re: Segfault when downloading multiple sftp files in parallel
To: the curl tool <>

On Tue, 28 Jun 2016, Gou Lingfeng wrote:

Free proto 0x7fffbc0422c0 0x7fffbc036270 0x7fffbc07bad0
> * Closing connection 6
> * Connection 7 seems to be dead!
> Free proto 0x7fffbc040770 0x7fffbc036270 (nil)
> * Closing connection 7
> * Found bundle for host 0x7fffbc03f7f0 [serially]
> * Re-using existing connection! (#5) with host
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffca9fe700 (LWP 3328)]
> ssh_getworkingpath (homedir=0x7fffbc0795b0 "/home/goulf", path=path_at_entr
> y=0x0,
> conn=0x7fffbc0414f0, conn=0x7fffbc0414f0) at ssh.c:470
> 470 *path = real_path;
> You can see that ``0x7fffbc07bad0`` is freed (twice).

I can see that in your debug output, yes, but I can't figure out how that
came to be. Can you?

Can you reproduce this problem? What libcurl version is this?

(and btw, libcurl and development talk is usually better kept on the
curl-library mailing list)

List admin:

List admin:
Received on 2016-06-29