本文介绍了错误:longjmp导致未初始化的堆栈帧的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个服务器应用程序,在dbus上创建一个总线,几分钟后运行我得到一个错误,我从来没有见过。

I have a server application that creates a Bus on the dbus and after some minutes of running I got an error that I have never seen before. Did you have an idea whats wrong?

*** longjmp causes uninitialized stack frame ***: /home/user/Workspace/DBus_Server/Debug/DBus_Server terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f8d8911c7f7]
/lib/x86_64-linux-gnu/libc.so.6(+0xf8789)[0x7f8d8911c789]
/lib/x86_64-linux-gnu/libc.so.6(__longjmp_chk+0x33)[0x7f8d8911c6f3]
/usr/lib/x86_64-linux-gnu/libcurl-nss.so.4(+0xd795)[0x7f8d88272795]
/lib/x86_64-linux-gnu/libc.so.6(+0x36420)[0x7f8d8905a420]
/lib/x86_64-linux-gnu/libc.so.6(__poll+0x53)[0x7f8d890f9773]
/usr/lib/libdbus-c++-1.so.0(_ZN4DBus15DefaultMainLoop8dispatchEv+0x161)[0x7f8d89b6b481]
/usr/lib/libdbus-c++-1.so.0(_ZN4DBus13BusDispatcher5enterEv+0x63)[0x7f8d89b6c293]
/home/user/Workspace/DBus_Server/Debug/DBus_Server[0x401333]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f8d8904530d]
/home/user/Workspace/DBus_Server/Debug/DBus_Server[0x4011c9]


推荐答案

如上所述,它是一个curl bug。我想我会在这里提供一个答案,将所有可用的问题信息集中在一起。

I ran into the same issue; as noted above, it is a curl bug. I thought I would put an answer up here to pull together all of the available information on the problem.

从:

某些平台上的问题显然是指至少在现代Linux系统上的崩溃。一些更深入的技术细节在上面的链接:

The "problems on some platforms" apparently refers to crashes on modern Linux systems at least. Some deeper technical details are at the link from the quote above:

问题是所有以下控制流在信号处理程序中有效地执行
。不仅有一个风险
libcurl可以调用异步处理程序不安全的函数(见信号(7))
在这段时间,但它可以调用一个用户回调函数
可以调用绝对任何东西。事实上,siglongjmp()本身不是在
的POSIX列表的异步安全函数,这是所有libcurl
信号处理程序调用!

The problem is that all the following control flow executes effectively inside the signal handler. Not only is there a risk that libcurl could call an async handler unsafe function (see signal(7)) during this time, but it could call a user callback function that could call absolutely anything. In fact, siglongjmp() itself is not on the POSIX list of async-safe functions, and that's all the libcurl signal handler calls!

有几种方法来解决这个问题,这取决于你是否构建libcurl,或者如果你遇到了由你的发行版或系统管理员提供的:

There are a couple ways to solve this problem, depending upon whether you built libcurl or if you're stuck with one that was provided by your distribution or system admin:


  • 如果无法重建libcurl,那么可以调用 curl_easy_setopt(curl,CURLOPT_NOSIGNAL,1)在您使用的所有curl句柄。 CURLOPT_NOSIGNAL 注释的文档:

  • If you can't rebuild libcurl, then you can call curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1) on all curl handles that you use. The documentation for CURLOPT_NOSIGNAL notes:

如果设置了此选项并且libcurl已使用标准
名称解析器构建,则名称解决需要
地方
。考虑使用c-ares支持来构建libcurl,以启用
异步DNS查找,这使得名称
的优秀超时可以无信号地解析。

If this option is set and libcurl has been built with the standard name resolver, timeouts will not occur while the name resolve takes place. Consider building libcurl with c-ares support to enable asynchronous DNS lookups, which enables nice timeouts for name resolves without signals.

DNS超时在大多数情况下显然是可取的,所以这不是一个完美的解决方案。如果您有能力在您的系统上重建libcurl,那么您可以...

DNS timeouts are obviously desirable to have in most cases, so this isn't a perfect fix. If you have the ability to rebuild libcurl on your system, then you can...

有一个异步DNS解析器库称为 curl能够用于名称解析。使用这个库是解决这个问题的首选方法(我想大多数Linux软件包都已经知道了这一点)。要启用c-ares支持,首先构建并安装库,然后将 - enable-ares 标志传递给curl的 configure 脚本。 。

There is an asynchronous DNS resolver library called c-ares that curl is capable of using for name resolution. Using this library is the preferred solution to the problem (and I would imagine most Linux packagers have figured this out by now). To enable c-ares support, first build and install the library, then pass the --enable-ares flag to curl's configure script before you build. Full instructions are here.

这篇关于错误:longjmp导致未初始化的堆栈帧的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

07-18 16:02
查看更多