abrt detected a crash. Attached file: backtrace cmdline: /usr/bin/python /usr/bin/gwibber-daemon component: python executable: /usr/bin/python kernel: 2.6.31.6-134.fc12.x86_64 package: python-2.6.2-2.fc12 rating: 3 reason: Process was terminated by signal 6
Created attachment 372690 [details] File: backtrace
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: debuginfo-install libcurl Please see http://fedoraproject.org/wiki/StackTraces for more information about stack traces Thanks!
*** Bug 539907 has been marked as a duplicate of this bug. ***
[jcollie@lt26923 ~]$ rpm -q gwibber gwibber-2.0.0-1.478bzr.fc12.noarch [jcollie@lt26923 ~]$ rpm -q libcurl libcurl-7.19.7-1.fc12.x86_64 [jcollie@lt26923 ~]$ rpm -q python-pycurl python-pycurl-7.19.0-4.fc12.x86_64 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. ***