斷點擊中時，單元源代碼與代碼執行路徑不匹配

我正在調試使用Delphi 6 Pro與DSPACK代碼庫創建的DirectShow過濾器。當我設置的斷點在一個名爲BaseClass.pas的特定單元中命中時，我開始跟蹤，執行點跳轉到源代碼中的奇怪位置。這通常表示被跟蹤的源代碼與編譯到Delphi應用程序使用的其中一個包中的源代碼不匹配。奇怪的是，它只是BaseClass單元，因爲我追蹤了屬於DSPACK代碼庫的其他單元，並且它們沒有出現這個問題。我沒有使用運行時軟件包。斷點擊中時，單元源代碼與代碼執行路徑不匹配

我掃描了我的磁盤，發現只有一個修改日期等於上次構建程序的BaseClass.dcu副本。我沒有修改該單元或任何其他屬於DSPACK的源代碼。由於我的過濾器是主應用程序的一部分，因此它指示BaseClass.pas將受制於雙重使用情況，因爲它用於構建DSPACK組件包（dpk），並且也由我的主應用程序直接通過TBCSource對象引用我的過濾器從下降。請注意，我嘗試將單位PAS文件直接添加到我的項目中，但這並沒有解決任何問題。

我也回去重新打開了每個DSPACK包文件，並完成了重新構建。這些都沒有幫助。還有什麼我可以嘗試讓源與BaseClass單元的編譯圖像同步嗎？或者完全是一個不同的問題，如果是這樣，它是什麼，我該如何解決它？

來源

2011-10-28 Robert Oschler

有時出現這種情況時，代碼複製/從網頁或其他來源粘貼，併線不CR/LF對（#13#10或0x0D0A，標準適用於Windows）結束，但僅在LF（#10或0x0A結束，通常以* nix系統結尾的行）或CR（#13或0x0D，通常用於Mac OSX/iOS）。不正確的行結束符混淆了調試器 - 這是過去幾個Delphi版本的問題。

有時您可以通過使用文本編輯器（如記事本）打開源文件，做一個小的無意義更改（例如插入並刪除空白行）來解決此問題，然後保存該文件。

來源

2011-10-28 22:28:17

謝謝你提醒我。我只是嘗試了你的建議，不幸的是沒有改變。 –

我記得很久以前我寫了一個實用工具，專門用來清理任何*垃圾字符的Delphi文件，並確保所有行尾字符都是真正的CRLF對。我找到它並在BaseClass.pas上運行，錯誤消失。所以記事本保存/重新加載在某些情況下顯然是不夠的，但它是一個垃圾郵件字符問題。不幸的是，這讓我們失去了幾個小時，但很高興它已經修復了。 –

:)這就是爲什麼我說「有時」，而不是「你可以修復」。很高興我可以幫忙，即使它有點兒。 –

確保在重建它時，在開啓了「調試信息」的項目的編譯器選項中。實際上，調試中的大多數選項都應該在項目的編譯器選項中進行設置。

另外，如果您還沒有，請重新啓動Delphi。

來源

2011-10-28 19:29:12

好主意，但我再次檢查，調試信息確實是。 –

我有同樣的問題，並提出了類似的實用程序。修復。基本上，只要這樣的：

procedure adjustCRLF(filename : String); 
var 
    strList : TStringList; 
begin 
    strList := TStringList.Create; 
try 
    strList.LoadFromFile(filename); 
    strList.Text := AdjustLineBreaks(strList.Text); 
    strList.SaveToFile(filename); 
finally 
    strList.Free; 
end; 
end;

來源

2011-12-09 22:11:07 Jose

保存文件時，編輯器應該自動清理行尾！ – Shannon

還有另一種方式會發生這種情況：如果IDE錯誤地打開與另一個同名的源文件（但不同的，如早期版本），那麼所有的調試點會不正確，並且調試器甚至會允許您逐句通過不正確的文件。我見過Delphi 7做過一次。

來源

2015-01-21 01:17:24 SDL

斷點擊中時，單元源代碼與代碼執行路徑不匹配

回答

相關問題