Conky uses since 1.10 a new config format.
It can be compiled with a support for the old format, but dunno if it's available with extra/conky.
So maybe you should adjust the conkyrc and look if it's still failing

It is not failing immediately, it crashes randomly while pulling RSS data with curl

You'll need to provide a backtrace with debug symbols for this to be meaningful to anyone.

The version in Extra will read the old format and convert it on the fly, but it has a *lot* of issues. Please do update to the new format just to help eliminate that variable.

I've updated config, problem is still there.
Logs
conky -d:

conky: desktop window (16000a7) is subwindow of root window (d9)
conky: window type - normal
conky: drawing to created window (0x4800001)
conky: drawing to double buffer
conky: Unknown setting 'border_margin'
conky: one or more $endif's are missing
[1] 31597 segmentation fault (core dumped) conky -d

dmesg:

[17815.581415] traps: conky[31606] general protection ip:7efc2c729243 sp:7efc1f7fda98 error:0 in libcurl.so.4.3.0[7efc2c6e7000+70000]

Could you show us a *minimal* conkyrc (as few lines as possible) that exhibits this issue? Preferably in the new format. A full backtrace would also be very helpful...

Okay, with the attached conkyrc I eventually get the attached backtrace.

Could you grab debug symbols? They're available in my repo:

http://repo.falconindy.com/x86_64/curl-debug-7.43.0-1-x86_64.pkg.tar.xz

Better backtrace.

Sure, Dave, I'm on it.

Here it is.

There's several calls from Curl_http to Curl_checkheaders. Could you inspect the values in the Curl_http frame to figure out which call this is and where the NULL/uninitialized value that we're crashing on, is?

Is this repeatable with an earlier version of curl? It probably needs reporting to curl upstream if there isn't some other obvious memory corruption on the conky side.

It fails exactly the same with curl-7.39 and segfaults immediately with curl-7.34. I'm not sure how to inspect the values in Curl_http, though. Somehow I cannot get GDB to find the extra information it needs for the shared library.

So Curl_raw_nequal gets called with apparently innocent arguments (for example, I might get, as signed integers, first=38258, second=-165631461, and max=11) and the segfault happens when it tries to read *first (to see if *first is NULL or not). Accessing *second is fine, but *first causes the segfault. I might be tempted to suspect a GCC bug but I really have no idea...

So what happens exactly is that, within the Curl_http function, there is a call to Curl_checkheaders(conn, "User-Agent:") where conn->data->set.headers is uninitalized. That Curl_checkheaders call then uses Curl_raw_nequal which apparently chokes on uninitialized data. If I do `conn->data->set.headers = NULL;` at the top of the Curl_http function, then the crash seems to be avoided. I'm not sure what the side effects might be, though, or if this is the proper place to initialize that "headers" structure.

I've posted this upstream: https://github.com/bagder/curl/issues/342

So removing the If-Modified-Since header conky normally sets prevents curl from segfaulting. That's in ccurl_thread.cc: `curl_slist_append(headers.h, ("If-Modified-Since: " + last_modified).c_str());`
That is a bit strange, though, that header looks fine to me...

A fix was found upstream; it was apparently conky's fault: https://github.com/bagder/curl/issues/342