2011-05-25 73 views
1

我在應用程序中發生了令人討厭的崩潰。 GDB總是將其追溯到__kernel_vsyscall()。在調試後,我無法在源代碼中找到任何可疑的東西。在禁用GCC優化後不會發生__kernel_vsyscall()崩潰

但是在GCC編譯器中隨機禁用一次'-O3'優化標誌似乎可以解決問題。我不確定這是否是崩潰的原因,或者如果編譯器在優化期間可能做了一些令人討厭的事情。任何評論或信息都會有所幫助。

在下面顯示的一些回溯中,在應用程序代碼中觀察到的唯一錯誤的事情是從MsgQ(buffLen)接收的緩衝區的長度。但源代碼確保通過MsgQ發送和接收的最大消息大小爲2048字節。無法追蹤msgrcv()調用返回的長度爲何以及何時可能已損壞。

CRASH 1:

  1. 0x00110416在__kernel_vsyscall()
  2. 在從/lib/libc.so.6
  3. 0x0034d31c在__vsyslog_chk(發送()0x00352391)從打開/lib/libc.so 0.6
  4. syslog中()從procType1Msg /lib/libc.so.6
  5. 0x0804f08f(MsgBuff = 0xbfc10275)
  6. 0x080498c5在procRcvdMsQBuf(buffLen = 13451518 0x0034d5b7 4,淺黃色= '值優化了')
  7. 主(的argc = 3,argv的= 0xbfc10b24)

CRASH 2:

  1. 0x00110416在__kernel_vsyscall()
  2. 0x00352391在發送( )從在從系統日誌()/lib/libc.so.6
  3. 0x0034d5b7 __vsyslog_chk()/lib/libc.so.6
  4. 0x0034d31c從/lib/libc.so.6
  5. 0x0806234b在dumpMsg(淺黃色= 0xbfe01832 「U \ 006 \」 X,N,#®ü\ 027 \ BI @ \ 024" ,LEN = 23)
  6. 在procType1Msg 0x0804e539(MsgBuff = 0xbfe01815)
  7. 0x0804956d在procRcvdMsQBuf(buffLen = 134515040,淺黃色= '值優化了')
  8. 主(的argc = 3,argv的= 0xbfe020c4)

CRASH 3:

  1. 0x00110416在__kernel_vsyscall()
  2. 0x003在msgrcv()53e3f從/lib/libc.so.6
  3. 0x080639b9在getMsgQBuffer(MSG_ID = 196611,PMSG = 0xbfa9d360,lMsgType = 0,piErrorNo = 0xbfa9d35c)
  4. 在主0x080497dd(的argc =在無法訪問存儲器地址0x30003)
+0

當你使用'-O2'時會發生什麼? – trojanfoe 2011-05-25 07:01:01

回答

1

我的猜測是你的代碼中某處存在內存損壞(可能是緩衝區溢出)。

當你使用3級優化進行編譯時,編譯器輸出的代碼是這樣的:緩衝區溢出寫入重要的東西(可能會損壞堆棧?),而且碰巧編譯器在沒有運行時編譯器產生的非優化代碼優化標誌是不同的,所以溢出運行其他的東西,並不會導致這種特定的症狀。這個錯誤可能還在那裏,它可能以其他方式表現出來,甚至根本不會 - 直到你改變了一些與非相關的東西,然後再次咬你。

__kernel_vsyscall()是一個簡單的glibc函數,每當你執行一個系統調用時都會在內部被調用。那裏沒有什麼重要的。

我的推薦:在valgrind下運行你的程序。它很可能會找到你的內存溢出。

+0

謝謝gby ...我也有同樣的懷疑,但由於資源限制,我們的代碼和它的運行時環境(它是一個通信堆棧)的窮舉性質,我無法嘗試內存檢查工具:(我也感覺內存損壞,如果是這樣的話,可能發生在代碼中的任何其他地方,而不是必須在碰撞點的跟蹤路徑中。讓我找一些時間和技巧來使用內存檢查工具,但現在看來我的僱主不是對崩潰感到困擾,但正如你所說,它仍然存在,並會再次咬傷:) – Piyush 2011-05-27 05:12:10