abrt detected a crash.
Attached file: backtrace
cmdline: /usr/bin/python /usr/bin/gwibber-daemon
reason: Process was terminated by signal 6
Created attachment 372690 [details]
Thanks for filing this bug report.
How reproducible is this bug? Is there any output if you run it from a terminal?
Which version of libcurl and gwibber-daemon do you have installed? (do we ship gwibber-daemon in Fedora?)
Looking at the backtrace, it appears that thread 1 aborted; perhaps with the message:
longjmp causes uninitialized stack frame
from __fortify_fail (see frame 3), inside libcurl.
Unfortunately, that stack trace is not very useful in determining the cause of the crash, because it is only a partial symbolic stack trace. In order to get a more full symbolic stack trace, the appropriate debuginfo package needs to be installed. In order to accomplish this, you can run the command:
Please see http://fedoraproject.org/wiki/StackTraces for more information about stack traces
*** Bug 539907 has been marked as a duplicate of this bug. ***
[jcollie@lt26923 ~]$ rpm -q gwibber
[jcollie@lt26923 ~]$ rpm -q libcurl
[jcollie@lt26923 ~]$ rpm -q python-pycurl
Ian Weller recently built a new version of GWibber, I pulled it out of Koji so that I could test it out.
The backtrace has only happened once so far. I added the debuginfo packages for curl and refreshed the backtrace, except abrt opened up a new bug (539907) instead of attaching the new backtrace to this bugreport.
Looking at attachment 372750 [details] to bug 539907:
- in frame #6 of thread #1, alarmfunc of hostip.c is called from within the GTK main loop.
- looking at: http://curl.haxx.se/cvs.cgi/curl/lib/hostip.c?revision=1.221&view=markup this calls: siglongjmp(curl_jmpenv, 1); which appears to be doing a long jump back into Curl_resolv_timeout; the code has a dire warning about "This effectively causes the remainder of the application to run within a signal handler which is nonportable and could lead to problems."
- within frame #5 we actually invoke a "fortified" implementation of longjmp, which detects a problem, and kills the process with an "abort" signal (signal 6)
I'm not familiar with this code; reassiging from "python" to "curl" in the hope of more insight.
Thanks for digging it up! You are completely right. The issue is sort of known bug:
$ grep -A10 ^1.4 /usr/share/doc/curl-7.19.7/TODO
1.4 signal-based resolver timeouts
libcurl built without an asynchronous resolver library uses alarm() to time
out DNS lookups. When a timeout occurs, this causes libcurl to jump from the
signal handler back into the library with a sigsetjmp, which effectively
causes libcurl to continue running within the signal handler. This is
non-portable and could cause problems on some platforms. A discussion on the
problem is available at http://curl.haxx.se/mail/lib-2008-09/0197.html
Also, alarm() provides timeout resolution only to the nearest second. alarm
ought to be replaced by setitimer on systems that support it.
However there is not much I can do with the bug. If I disable the alarm, there will be no timeout for name resolving, thus some applications may stop working. The proper way to address the bug is switching curl to c-ares for name resolving and it has already happen for Fedora 13. I am not going to do the same for stable Fedora as there are still some open questions about the IPv6 support.
*** Bug 553916 has been marked as a duplicate of this bug. ***