開發平台(Platform): (Ex: VC++, GCC, Linux, ...)
Linux C

檢查malloc,free

105行=> write(sock, "Error Code1", 10);是不是要改成11? 我不知道這會不會有影響...

謝謝k大的指錯..應該是12

先看看 info_insert() 和 cost_power() 最後是不是少了什麼事.新版的做過頭, 兩函式中的 res 反而是多做的事了 XD

不好意思，新版已更正上傳!!不過換valgrind跑很慢了.. 遲遲跑不出結果!按了ctrl+C後，只出現2個錯誤.. XD

valgrind 慢是正常的, 一般平均會慢個數倍至十數倍

139其實就是所謂的萬用錯誤sig 11吧你的code有stack堆積的問題嗎？在某些特殊情況下stack炸掉是回sig 11(不過我忘了其他情況回的是啥)

sig 11 => SIGSEGV, SEGV => segmentation violation. 見標題.去 wikipedia 查一下, 會有相關說明.

我不認為查Sig11有幫助。這錯誤其實含擴大多數記憶體讀寫的疑難雜症(所以我才說叫做萬用錯誤 因為大概錯誤裡面95%都會丟Sig.11). 這範圍太大了，不過我還是建議看一下是不是stack炸掉，這是少數valgrind看不出的問題

樓上所述 stack炸掉 是指 stack overflow 或是什麼?原PO有附程式碼,要不要幫忙看看,哪裏可能發生怎樣的問題?若是 stack overflow 而 segfault, 我使用valgrind測試的結果,會得到一句 Stack overflow in... can't grow stack... 的訊息上述測試使用 ubuntu 12.04.2 LTS, valgrind-3.7.0 .

謝謝y大和K大的熱心協助，目前我已將原程式和執行緒有關的部份都先拿掉了，打算用core dump搭配gdb看看結果，今日下午會再將精簡的程式碼附上，並將測試結果PO上來，謝謝大家:D

那就是stack炸掉沒錯。簡單的說，最常見的原因是local變數開太多 超出stack的範圍。另外還有一個隱含的可能性就是濫用alloc()。我很樂意幫忙debug 但是我現在手邊沒linux機器 XD... 只能從大家的feedback, code跟sig 11去猜是不是stack用盡造成overflow而已喔你是刻意產生stack overflow去看結果喔 我誤會了 =P發現少打一個字...是alloca()

看到原PO上一段的推文, 忽然想到 mysql client library 也可能不是編成thread-safe. 可以試著叫用 mysql_thread_safe() 看看當然原PO程式很多error-handling都沒做完整,也可能因此出問題.另外gdb也是可以處理thread.之前若有core dump情況又是如何?

之前的程式沒有用core dump，並不曉得結果 XDK大您好，local變數設定太多!? 不過函數內的變數用完不是就釋放了嘛...以小弟的程式來說..local變數數量應當是還行吧!? 不過我也的確不曉得stack的容量應該不能超過多少XD

stack上限容量可以用編譯器設定,一般預設大概是1~20MB左右

謝謝E大 明白了 :D

執行過一段時間，可能是too many file, 或 no memory

謝謝大家，問題已找到，估計是程式邏輯不好。沒做例外處理。^^

前面我有提到error-handling不完整.正想問你debug的情況如何:P