"Reprint" Linux signal processing and libcurl pits

Reprinted from Http://www.cnblogs.com/mumuxinfei/p/4363466.html Preface:There is a recent project that requires access to third-party services.  The service is accessed via HTTP, and for security and encryption, the other party provides an encrypted C/s + + library for processing parameters. In view of this, the C + + language is selected and Libcurl is used as the HTTP class library to write the service module. This laid the groundwork for the subsequent pit.

Summary of the situation:
The program uses the reactor model, the IO thread specializes in IO event read and write, and the requested dispatch distribution, and the backend pool is used for business synchronization operations. The use of Libcurl is also interspersed in multiple threads.
When the program function is complete, stress test it. After roughly 20 minutes, the program crash and out of the core.

　　

After gdb tuned the core, it found that the call stack on top of the epoll_wait was faulty.
According to experience, the spirit of who hit, who wipe the bottom of the principle of the thread and Epoll caller did a arduous, but difficult to troubleshoot. The following facts prove that this is a road of no return, Duang duang duang ...

Reverse speculation:
The initial troubleshooting did not work, and as a result, reverse thinking was used. Start with the SIGABRT 6 signal and see what happens to trigger the signal.
Repeated deletion of the pointer throws the error, as in the following example:
　　
Other memory operations, such as the use of wild pointers, cross over, often corresponding to the SIGSEGV 11.
As a result, looking for a suspected double delete case, the results are nothing.

Signal recognition:
There is only one truth, but where is it? Is that link wrong?
Inadvertently, swept down the stack again, found in vain <signal handler called>
　　
It appears that the epoll_wait thread is interrupted by the signal and executes the signal callback function (whose source indicates the libcurl.so.4) and SIGABRT 6 in the signal processing function.
Let us recall the processing of the signal.
The Raise function will send the signal to this thread. Other functions (such as kill, alarm) send a signal to the process, but the thread that executes the signal handler is not deterministic .
Now it's pretty close to the truth: a thread triggers the signal, and the epoll_wait thread executes the signal handler, but in this handler, it's an exception. It's not about epoll_wait, it doesn't matter with the caller.
Who is the function (black man)? Does it have anything to do with Libcurl?

To sweep through the clouds:
Through the search engine, found "Libcurl multi-threaded use precautions", "Libcurl multithreading crash Problems" these two articles.
The truth finally emerged, the original Libcurl timeout mechanism by default is through the signal sigalrm, setjmp/longjmp function to achieve, in the case of multithreading, will lead to program crash.
This official note also explains the exception information on the core stack.
The final solution is that the curlopt_nosignal is set to 1.

1	curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1L);

Summarize:
Party a abuse my times, I treat party a like first love. Although the Libcurl pit, but the understanding of the signal is more profound, the end is good. But the same business functions as the C + + and Java implementations, C + + coder need to know more details, raise the threshold at the same time, but also increase the difficulty of development and development time, it is a bit more than the candle. This article is not a language dispute.

"Reprint" Linux signal processing and libcurl pits