先上**
客戶端**如下：
#include
#include
#include
#include
#include
void str_cli(file *stream, int fd);
int main(int argc, char* argv)
int socket_fd[5];
int i;
for(i = 0; i < 5; i++)
}str_cli(stdin, socket_fd[0]);
return 0;
}void str_cli(file *stream, int fd)
}
伺服器端**如下：
#include
#include
#include
#include
#include
#include
#include
#include
#include
void str_echo(int fd);
void sig_chld(int signal);
int main()
else
}pid_t child_pid;
if ((child_pid = fork()) == 0)
close(connect_fd);}}
void str_echo(int fd)
else}}
void sig_chld(int signal)
程式的預期功能是:
客戶端從標準輸入讀入一行，傳送到伺服器，伺服器接受到訊息一行，將該訊息回送到客戶端，客戶端將接受到回送訊息顯示在標準輸出上。
bug特徵:
第一次開啟客戶端，輸入字元，不能正確回顯,訊息阻塞在read部分，不關閉服務端，重啟客戶端，工具就能正常工作。
bug分析：
服務端程式的
if ((connect_fd =
accept(listen_fd, (struct sockaddr *) &client_addr, &client_addr_length)
< 0))
括號加錯了位置。第一次開啟客戶端程式的時候，connect_fd被錯誤的賦值為1，導致其accept、read、write都在標準輸入上進行。但是執行到
close(connect_fd);的時候，標準輸入被關閉，當關閉客戶端程式再次開啟的時候，accept返回的的結果是當前最小fd,該fd為0，0<0的結果為0，陰差陽錯，connect_fd被賦予了正確的fd,所以第二次，程式就能正常工作。所以初學者看上去詭異的bug就出現了。感謝文卿大牛啊。
經驗教訓:
如果按照程式設計規範進行，就能避免很多著由看似不起眼的小問題出現的bug.....程式設計規範！！！！
loadrunner 乙個詭異問題
最近使用loadrunner壓測乙個專案的時候,發現tps波動巨大 且平均值較低。使用jmeter壓測則沒有這個問題。經過多方排查發現乙個讓人極度費解的原因 原指令碼 指令碼其他 web submit data aaa action 此處為密文鏈結 事務判斷邏輯等 tps圖如下 修改後的 指令碼其他...
記錄乙個詭異的函式呼叫返回錯誤的指標bug
include test.h void main typedef struct s s s s array 10 include test.h s get struct s 在大型程式中，複雜的makefile可能會通過上面這種project 即能夠編譯成功 但是在執行過程中printf語句會cru...
乙個sqlite應用詭異的問題
今天從應用層面解決了乙個詭異的問題。某程式，在伺服器a上跑速度很快，幾乎能將cpu乙個核的資源佔滿。而在伺服器b上跑很慢，慢了將近10倍 而且cpu使用率很低。伺服器a和b都是同樣的系統，幾乎相同型號的伺服器。通過各種排查原因，未果。最後還是認為是程式的問題。最終問題發生原因鎖定在乙個sqlite庫...