我正在使用VS2013構建針對2010編譯器的Windows 7（我們已經遷移了我們的開發環境，但不是所有項目）。程序狀態和調試器不同意
我真的不知道如何表徵這個問題，或者我會谷歌它。我有一個指向字節緩衝區的指針，它是我們的有線協議（代碼基礎早於Google及其協議緩衝區）。我們有標題，表示一個id和一個類型;將指針轉換爲適當的類型，您可以訪問數據，並且數據是動態大小的，例如字符串字段，長度。這一切都不應該是令人驚訝的，如果不是有點老派...
但我所看到的是我有代碼檢查字段ID - 它不應該是零。但條件是打擊，當我檢查調試器中的元素時，緩衝區內容和指針位置都是正確的 - 該字段不爲零。
所以我的問題給你：
1）如何將能夠更好地表達這個問題，所以我可以谷歌？
2）你以前見過這個嗎？有任何想法嗎？
找到。一個很難看的分號終止了這個條件;我每次都碰到身體。更好的指針算術糾正了進一步的堆損壞，「realloc（buff，size）」應該是「buff = realloc（buff，size）」。
這是一個長鏡頭，但是，當項目不正確時我已經看到它。您可以嘗試清理解決方案並重新構建它。
不幸的是，這是定期行使。我一直在尋找這個好幾天。 –
有幾個（的組合）的問題可以像這樣呈現。
在生產設置中失敗的代碼，但在調試時逐步完成的代碼。在這種情況下失敗的真正罪魁禍首，通常是一些其他不相關的代碼濫用指針（並覆蓋它不應該的內存）。事情是，開發人員得到一個錯誤報告，然後用調試器遍歷代碼。除了使用調試器的事實之外，另一個區別是生產代碼是用某種形式的「完全」優化編譯的，而代碼是在沒有優化（並且具有符號輸出）的情況下重新編譯以供調試器使用。這改變了程序中數據（甚至代碼）的內存佈局。有問題的代碼仍在騷擾指針，但內存中的其他內容正在被覆蓋。這意味着調試時症狀消失。對此的唯一解決方法是仔細檢查在報告崩潰之前執行的其他代碼。
另一種可能性是構建過程已經搞亂了，並且包含了陳舊舊bug的函數的過時實現。嘗試做一個「乾淨」和「建立」。
第三種可能性是代碼在調試和生產設置中執行不同的操作。例如，在#ifdef DEBUG ... #endif中包含的代碼僅在調試時纔有效。這種代碼通常用於產生「調試輸出」。它也會導致程序中內存佈局的改變，從而影響指針誤用的症狀。
在你描述的場景中，類型轉換也可能是無效的。當將char指針投射到指向X的指針時，隱含地認爲X具有特定大小是相當常見的。問題是（除了char類型）所有類型的大小都是實現定義的。當代碼使用不同的編譯器重新編譯時，這種不匹配（例如程序編寫流和解釋它假定差異大小的程序）是潛在的罪魁禍首。 [這並不能解釋在調試和生產環境中出現和消失的症狀，但是可以看出一個潛在的原因]。
要調試生產代碼，開發人員可以啓動生產代碼，附加調試器，添加所需的任何中斷點，然後讓代碼運行，直到出現問題。通過這種方式，可以調試具有優化的生產代碼。 – StarPilot
這是事實，Starpilot。但是，通常，在使用調試器時，開發人員通常使用爲調試而構建的代碼，因爲有用的信息可用於生產可執行文件中不存在的調試版本。而且，「事情變得有趣」的地方總是在觸發問題的代碼之後的某個執行點。開發人員經常等到事情「變得有趣」並且從那裏開始前進，沒有意識到他們需要向真正的罪犯回擊。 – Peter
此代碼尚未達到生產，我沒有在發佈版本中嘗試過。協議緩衝區代碼大於30歲，因此這是我要調查的最後一個罪魁禍首。我同意這可能是一些內存佈局問題。 –
沒有代碼，沒有cookie。 – leppie
您正在使用構建於vs2010上的obj/exe文件在vs2013中進行調試？ –
觀察變量。在GDB中，您可以簡單地「觀看」。你會看到有人正在改變價值。 – CyberGuy