Bug 539809

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. ***