curl - 错误:longjmp导致未初始化的堆栈帧

Question

我有一个服务器应用程序，该应用程序在dbus上创建了总线，运行了几分钟后，出现了从未见过的错误。你有什么主意吗

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

Answer 1

我遇到了同样的问题；如上所述，这是一个 curl 错误。我以为我会在这里给出答案，以汇总有关该问题的所有可用信息。

从the Red Hat bug report:

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

显然，“某些平台上的问题”至少是指现代Linux系统上的崩溃。上面引用的链接中提供了一些更详细的技术细节:

There's a problem with the way libcurl currently handles the SIGALRM signal. It installs a handler for SIGALRM to force a synchronous DNS resolve to time out after a specified time, which is the only way to abort such a resolve in some cases. Just before the the DNS resolve takes place it initializes a longjmp pointer so when the signal comes in the signal handler just does a siglongjmp, control continues from that saved location and the function returns an error code.

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还是坚持使用发行版或系统管理员提供的库:

如果无法重建libcurl，则可以在使用的所有curl句柄上调用curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1)。 CURLOPT_NOSIGNAL的文档说明:

Pass a long. If it is 1, libcurl will not use any functions that install signal handlers or any functions that cause signals to be sent to the process. This option is mainly here to allow multi-threaded unix applications to still set/use all timeout options etc, without risking getting signals. (Added in 7.10)

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，则可以...

有一个名为c-ares的异步DNS解析器库，curl可以使用它来进行名称解析。使用该库是解决该问题的首选解决方案(我想现在大多数Linux打包程序都已经弄清楚了)。要启用c-ares支持，请先构建并安装该库，然后在构建之前将--enable-ares标志传递给curl的configure脚本。 Full instructions are here。