त्रुटि: longjmp अनियमित स्टैक फ्रेम का कारण बनता है

Question

मेरे पास एक सर्वर एप्लिकेशन है जो डीबीस पर बस बनाता है और कुछ मिनटों के बाद मुझे एक त्रुटि मिली जो मैंने पहले कभी नहीं देखी है। क्या आपको पता था कि क्या गलत है?

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

मैं एक ही मुद्दे में भाग गया; जैसा ऊपर बताया गया है, यह एक कर्ल बग है। मैंने सोचा कि मैं समस्या पर उपलब्ध सभी जानकारी एकत्र करने के लिए यहां एक जवाब दूंगा।

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

  डीएनएस समय समाप्ति जाहिर है ज्यादातर मामलों में है करने के लिए वांछित हैं, तो यह एक आदर्श ठीक नहीं है। आप अपने सिस्टम पर libcurl के पुनर्निर्माण करने की क्षमता है, तो आप कर सकते हैं ...

• है, तो वहाँ एक अतुल्यकालिक DNS रिसोल्वर c-ares कि कर्ल नाम समाधान के लिए उपयोग करने में सक्षम है कहा जाता है पुस्तकालय है। इस पुस्तकालय का उपयोग समस्या का पसंदीदा समाधान है (और मुझे लगता है कि अधिकांश लिनक्स पैकेजर्स ने अब तक इसका पता लगाया है)। सी-एरेस समर्थन को सक्षम करने के लिए, पहले लाइब्रेरी का निर्माण और स्थापित करें, फिर --enable-ares फ़्लैग को बनाने से पहले कर्ल की configure स्क्रिप्ट को पास करें। Full instructions are here।

Answer 2

यह डेबियन changelog जहां पिरोया DNS रिसोल्वर लागू किया गया है के अनुसार कर्ल 7.32.0 में तय किया जाना चाहिए। डेबियन पैकेज अस्थिर है और here पाया जा सकता है।

उबंटू के लिए 12.04 -> 13.04 आप this PPA का उपयोग कर सकते हैं।

sudo apt-add-repository ppa:jaywink/curldebian 
sudo apt-get update && sudo apt-get upgrade 

उबंटू 13.10 में कर्ल 7.32 शामिल है इसलिए इस समस्या को नहीं होना चाहिए।