我見過的最奇怪的事情：ESI寄存器賦值

後立即得到了一個無效值我們在Windows 7中的C寫++多線程運行的服務器進程。我們只是一個簡單的任務得到了一個隨機崩潰，請參見下面的說明：我見過的最奇怪的事情：ESI寄存器賦值

--- some function without the source: 
0136E0F0 mov   eax,dword ptr [esp+8] 
0136E0F4 mov   edx,dword ptr [esp+0Ch] 
0136E0F8 push  esi 
0136E0F9 mov   esi,dword ptr [ecx+10h]   << read a member variable to esi 
0136E0FC add   dword ptr [ecx+esi*8+30h],eax << access violation here! 
... 
...

奇怪的是，當碰撞發生，[ECX + 10H]的值爲0，但ESI是非零值無效！然後最後一條指令嘗試寫入無效內存！（我們從崩潰轉儲文件中檢查它們）。 這意味着，在ECX的對象是有效的，但寄存器已損壞！也許我錯了，但是操作系統將在切換線程時保留所有寄存器，對吧？

所以我的問題是，真正發生在這裏，以及如何解決它？

非常感謝。

來源

2012-06-07 crazybie

不會崩潰發生的每一次或僅在一定的條件下，即：如果通過這個代碼在調試步驟，它表明ESI被損壞？你是正確的操作系統的上下文切換寄存器保存，但是，假設你正在用戶區運行沒有任何可能導致不穩定的操作系統的可變更改。 – Necrolis

感謝您的關注。撞車事件是隨機發生的，我們不知道是以何種條件重現的，這是現在最大的問題。（另一個是我們沒有源代碼）。這段代碼應該是正確的，因爲它是一個在其他地方經常使用的通用函數。我們可以通過啓動崩潰轉儲文件（但在崩潰之前[ecx + 10h]爲0）在調試器中看到esi已損壞。 – crazybie

這些「不可能」的錯誤有一個相當普遍的原因：硬件故障。 CPU可能會失敗或太熱。

這種情況比人們想象的要多得多。硬件不工作或不工作。它可以主要工作，除了1e10機會中的一種情況。

來源

2012-06-07 12:49:21 usr

感謝您的回答。但實際上這發生了很多次。有時會出現太多例外情況，有時會出現太多連接。我們已經在很多機器上安裝了這臺服務器，並且他們都有這個崩潰。因爲它是關鍵服務器的一部分，所以我們真的很頭疼。 – crazybie

什麼的代碼其他片是與ECX + 10H數據搞亂？

有大量的MOV之間的範圍從內存到ESI，和ESI的以後使用，對於內存已經改變。然後它看起來好像esi應該有一個很好的價值。

試想一下，在不同的線程或中斷插手裝上去有效的ECX + 10H，0（？），從該位置讀取之後。

來源

2012-11-08 18:19:33

我見過的最奇怪的事情：ESI寄存器賦值

回答

相關問題