{"id":266,"date":"2023-08-18T18:04:54","date_gmt":"2023-08-18T10:04:54","guid":{"rendered":"http:\/\/blog.xjfvps.top\/index.php\/2023\/08\/18\/curl%e9%81%87%e5%88%b0longjmp-causes-uninitialized-stack-frame%e7%9a%84%e5%a4%84%e7%90%86%e5%8a%9e%e6%b3%95\/"},"modified":"2023-08-18T21:31:05","modified_gmt":"2023-08-18T13:31:05","slug":"curl%e9%81%87%e5%88%b0longjmp-causes-uninitialized-stack-frame%e7%9a%84%e5%a4%84%e7%90%86%e5%8a%9e%e6%b3%95","status":"publish","type":"post","link":"https:\/\/blog.fs.cloudns.biz\/index.php\/2023\/08\/18\/curl%e9%81%87%e5%88%b0longjmp-causes-uninitialized-stack-frame%e7%9a%84%e5%a4%84%e7%90%86%e5%8a%9e%e6%b3%95\/","title":{"rendered":"curl\u9047\u5230longjmp causes uninitialized stack frame\u7684\u5904\u7406\u529e\u6cd5"},"content":{"rendered":"

\u6458\u81ea http:\/\/stackoverflow.com\/questions\/9191668\/error-longjmp-causes-uninitialized-stack-frame<\/a><\/p>\n

 <\/p>\n

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.<\/p>\n

From the Red Hat bug report<\/a>:<\/p>\n

\n

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<\/a><\/p>\n<\/blockquote>\n

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:<\/p>\n

\n

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.<\/p>\n

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!<\/p>\n<\/blockquote>\n

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:<\/p>\n