今天運氣不錯，解決了兩個非常棘手的bug，這乙個是關於libcurl的。?
12
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#0 0x4001e416 in __kernel_vsyscall ()
#1 0x40491941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x40494e42 in abort () at abort.c:92
#3 0x404c9305 in __libc_message (do_abort=2,
fmt=0x4059f36a "*** %s ***: %s terminated\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#4 0x4054c970 in __fortify_fail (msg=)
at fortify_fail.c:32
#5 0x4054c8da in ____longjmp_chk ()
at ../sysdeps/unix/sysv/linux/i386/____longjmp_chk.s:76
#6 0x4054c849 in __longjmp_chk (env=, val=1)
at ../setjmp/longjmp.c:40
#7 0x4020dd08 in alarmfunc () from /usr/lib/libcurl-gnutls.so.4
#8
#9 0x4001e416 in __kernel_vsyscall ()
#10 0x4004b930 in sem_wait@glibc_2.0 ()
at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/sem_wait.s:318
#11 0x400fa7ac in peekmessageex (pmsg=0xbffff0b8, hwnd=134580240,
imsgfiltermin=0, imsgfiltermax=0, bwait=1, uremovemsg=1) at message.c:628
#12 0x0804b45f in getmessage (this=0xbffff104)
at /usr/local/include/minigui/window.h:1935
#15 0x08049f4c in main (args=1, argv=0xbffff274) at main.cc:56
簡單說明一下，就是主迴圈在執行sem_wait時，被乙個訊號打斷，然後導致整個程式的崩潰。問題的關鍵就在那個alarmfunc ()，是libcurl打斷了我的迴圈。
解決方法很簡單，把curlopt_nosignal設為1就行了，這樣libcurl將不會產生任何訊號：
多執行緒環境下的shared ptr
多個執行緒讀寫同乙個shared ptr物件需要加鎖 注意分清shared ptr物件與shared ptr管理的物件 mutexlock mutex shared ptr globalptr void read void write 上面的read 和write 在臨界區之外都沒有再訪問globa...
多執行緒環境下進行DEBUG
工具使用的是idea 1.debug模式下斷點的作用方式有兩種，all表示遇到斷點時，所有執行緒都會停滯在當前狀態中 並未掛起，依然都是可執行狀態 其他執行緒都無法繼續執行。當過掉這個斷點時，所有執行緒會同時開始爭搶cpu資源，這時是無法保證當前執行緒優先執行的。thread表示只中斷當前執行此行 ...
解決使用 libcurl 遇到的多執行緒崩潰問題
使用 curl 訪問 http 鏈結時，用 easy handle，阻塞方式訪問時發現會每個訪問啟動乙個執行緒去進行dns 想減少這種消耗，故此採用了 sh curl share init curl share setopt sh,curlshopt share,curl lock data dns...