Bug 539809 - "longjmp causes uninitialized stack frame" in libcurl's alarmfunc running gwibber-daemon
Summary: "longjmp causes uninitialized stack frame" in libcurl's alarmfunc running gwi...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: curl
Version: 12
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:052f7ce420ae968399ae07f0204...
: 539907 553916 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-21 05:53 UTC by Jeffrey C. Ollie
Modified: 2010-01-09 17:25 UTC (History)
7 users (show)

Fixed In Version: 7.19.6-11.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-12-16 18:03:08 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (54.47 KB, text/plain)
2009-11-21 05:53 UTC, Jeffrey C. Ollie
no flags Details

Description Jeffrey C. Ollie 2009-11-21 05:53:03 UTC
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

Comment 1 Jeffrey C. Ollie 2009-11-21 05:53:06 UTC
Created attachment 372690 [details]
File: backtrace

Comment 2 Dave Malcolm 2009-11-21 14:46:42 UTC
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!

Comment 3 Jeffrey C. Ollie 2009-11-21 15:10:42 UTC
*** Bug 539907 has been marked as a duplicate of this bug. ***

Comment 4 Jeffrey C. Ollie 2009-11-21 15:16:17 UTC
[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.

Comment 5 Dave Malcolm 2009-12-15 23:16:22 UTC
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.

Comment 6 Kamil Dudka 2009-12-16 18:03:08 UTC
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.

Comment 7 Dave Malcolm 2010-01-09 17:25:47 UTC
*** Bug 553916 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.