我試過使用GDB和Valgrind,但我似乎無法找出問題所在。 有趣的是,程序在正常執行和GDB期間崩潰,但不是Valgrid。malloc內存損壞,打開
爲了幫助您跟隨代碼,繼承人程序的基本點: 通過套接字和UDP與服務器通信傳輸文件,並處理一些基本的數據包丟失。
我不會共享服務器的代碼,因爲我知道問題不在那裏。 可能會讓一些人感到困惑的一點是,我正在使用數字生成器自己實現數據包丟失。現在它並沒有做任何事情,除了讓程序使用另一個recvfrom。
爲了引導您完成程序輸出,客戶端會告訴服務器它想要什麼文件,服務器會告訴客戶端文件將發送多大,然後以塊(一次10個字符)。
輸出顯示發送了哪些塊,接收了多少個字符以及連接字符串是什麼。
從我所知道的文件傳輸成功,它只是我用來寫收到的文件,給我麻煩的打字電話。不知道這是否與我的malloc調用或不。
這裏是源代碼:
pastebin.com/Z79hvw6L
下面是從CLI執行的輸出,和(似乎GDB不提供任何更多信息)Valgrind的:
注意CLI給出了一個malloc內存損壞錯誤,Valgrind沒有。
CLI:http://pastebin.com/qdTKMCD2
的valgrind:http://pastebin.com/8inRygnU
感謝您的幫助!
增加了GDB回溯導致
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6b961)[0x19a961]
/lib/i386-linux-gnu/libc.so.6(+0x6e15d)[0x19d15d]
/lib/i386-linux-gnu/libc.so.6(__libc_malloc+0x63)[0x19ef53]
/lib/i386-linux-gnu/libc.so.6(+0x5c2b8)[0x18b2b8]
/lib/i386-linux-gnu/libc.so.6(fopen+0x2c)[0x18b38c]
/home/---/client[0x8048dc2]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x145e37]
/home/---/client[0x8048871]
也許這可以給別人的洞察力,以什麼部分程序的錯誤是嗎?
一般而言,如果您無法在帖子的上下文中發佈相關來源子集,則不會收到很多回復。 – Joe
你爲什麼不在valgrind的崩潰位置發佈回溯?我敢打賭,如果你得到了回溯,那麼在損壞的內存(崩潰點)上設置一個內存觀察點會引發你的問題。 – dbeer
你是什麼意思喬?我認爲問題出在哪裏? – user974703