Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#45569 - [conky] crashes due to libcurl

Attached to Project: Arch Linux
Opened by Nickolay (neothefox) - Monday, 06 July 2015, 10:39 GMT
Last edited by Gaetan Bisson (vesath) - Saturday, 11 July 2015, 19:20 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Conky crashes soon after start (1.10.0-2), something related to libcurl (7.43.0-1).

Dmesg output:
[ 434.149234] conky[1549]: segfault at 400000000 ip 00007fa969078243 sp 00007fa943ffea98 error 4 in[7fa969036000+70000]

Steps to reproduce:
Just start conky with this conkyrc -, and wait.
This task depends upon

Closed by  Gaetan Bisson (vesath)
Saturday, 11 July 2015, 19:20 GMT
Reason for closing:  Fixed
Additional comments about closing:  conky-1.10.0-3 in [extra]
Comment by Lex Black (TrialnError) - Monday, 06 July 2015, 11:38 GMT
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
Comment by Nickolay (neothefox) - Monday, 06 July 2015, 11:44 GMT
It is not failing immediately, it crashes randomly while pulling RSS data with curl
Comment by Dave Reisner (falconindy) - Monday, 06 July 2015, 13:38 GMT
You'll need to provide a backtrace with debug symbols for this to be meaningful to anyone.
Comment by Doug Newgard (Scimmia) - Monday, 06 July 2015, 14:15 GMT
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.
Comment by Nickolay (neothefox) - Tuesday, 07 July 2015, 08:39 GMT
I've updated config, problem is still there.
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


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

Comment by Gaetan Bisson (vesath) - Tuesday, 07 July 2015, 17:31 GMT
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...
Comment by Gaetan Bisson (vesath) - Tuesday, 07 July 2015, 17:39 GMT
Okay, with the attached conkyrc I eventually get the attached backtrace.
   conkyrc (0.2 KiB)
   bt (1 KiB)
Comment by Dave Reisner (falconindy) - Tuesday, 07 July 2015, 17:42 GMT
Could you grab debug symbols? They're available in my repo:
Comment by Gaetan Bisson (vesath) - Tuesday, 07 July 2015, 17:44 GMT
Better backtrace.
   bt (1.7 KiB)
Comment by Gaetan Bisson (vesath) - Tuesday, 07 July 2015, 17:45 GMT
Sure, Dave, I'm on it.
Comment by Gaetan Bisson (vesath) - Tuesday, 07 July 2015, 17:53 GMT
Here it is.
   bt (1.8 KiB)
Comment by Dave Reisner (falconindy) - Wednesday, 08 July 2015, 15:18 GMT
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.
Comment by Gaetan Bisson (vesath) - Thursday, 09 July 2015, 03:00 GMT
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.
Comment by Gaetan Bisson (vesath) - Friday, 10 July 2015, 05:23 GMT
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...
Comment by Gaetan Bisson (vesath) - Friday, 10 July 2015, 06:40 GMT
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:
Comment by Gaetan Bisson (vesath) - Saturday, 11 July 2015, 02:40 GMT
So removing the If-Modified-Since header conky normally sets prevents curl from segfaulting. That's in `curl_slist_append(headers.h, ("If-Modified-Since: " + last_modified).c_str());`
That is a bit strange, though, that header looks fine to me...
Comment by Gaetan Bisson (vesath) - Saturday, 11 July 2015, 19:20 GMT
A fix was found upstream; it was apparently conky's fault: