curl / Mailing Lists / curl-library / Single Mail


Re: Segmentation fault in Curl_expire_clear()

From: Daniel Stenberg <>
Date: Thu, 15 Dec 2016 23:04:39 +0100 (CET)

On Wed, 14 Dec 2016, Theo van Klaveren wrote:

> I am seeing an intermittent (2-3 times a week) segfault inside libcurl code,
> and it is frequent enough that it is becoming a real problem. I'm having
> problems finding the root cause so any help would be appreciated.
> A bit of context: This is an application that is responsible for
> fetching data from multiple sources via HTTP and uploading the results
> to a central server via HTTPS.

No FTP or some other "ping-pong" protocol involved? It looks like the
Curl_close() that calls the function that crashes is done for the

> It looks like something in Curl's state has become corrupted somewhere:
> (gdb) list
> 3021 /* flush the timeout list too */
> 3022 while(list->size > 0)
> <--- crash is here
> 3023 Curl_llist_remove(list, list->tail, NULL);
> (gdb) print list
> $9 = (struct curl_llist *) 0x0

This means (nowp->tv_sec || nowp->tv_usec) first evaluated true and yet
data->state.timeoutlist is NULL. That looks like a situation that shouldn't

> The code that calls libcurl is pretty much a copy-paste of libcurl example
> code, but I can post a (slightly redacted) version if it's needed.

Can you use that code against a public URL and experience a crash like this?

> Any help in tracking down this segfault would be greatly appreciated!

In addition to Jay's suggestion, maybe just running the application with
valgrind could be a first test to see if it detects and wrongdoings.

List admin:
Received on 2016-12-15