2009-12-15 23:02:20| 分類： 疑難雜癥
HEAP: Free Heap block ×××modified at ×××after it was freed
問題很嚴重！第一次出現(xiàn)異常提示時，程序依然繼續(xù)運行；若干次之后，程序異常中斷，函數(shù)調(diào)用棧不能提供足夠的有效信息。
看起來似乎是內(nèi)存重復(fù)釋放的問題，其實不然！因為程序是在若干次循環(huán)后才出現(xiàn)這一問題，如果是重復(fù)釋放，應(yīng)該是第一次循環(huán)就會出現(xiàn)這個問題。
剛才我在路上仔細想了一下，覺得是由于內(nèi)存溢出導致的，而不是重復(fù)釋放內(nèi)存。其實，這類似于ShellCode的原理，即越界訪問。由于程序是在Debug模式下運行，Debug模式下，內(nèi)存不是緊湊排列的，所以，雖然有越界訪問，但不會立刻導致程序崩潰。
如果這一推斷正確，那么，release模式下，程序應(yīng)該崩潰！但是結(jié)果令我大失所望。
2009.12.16
之前認為這是filter隊列阻塞所致。而我改用線程處理，問題依舊，于是，我認為這是內(nèi)存溢出，而不是隊列滿了的緣故。
我使用了幾種偵測內(nèi)存溢出的方法檢測代碼，發(fā)現(xiàn)并沒有內(nèi)存溢出，一切正常。于是，我再次想到隊列阻塞。
問題重現(xiàn)：
為了證實這一判斷，我在Transform中加入如下代碼：
Sleep(1000);
return NOERROR;
Filter Graph大約每秒傳遞10個數(shù)據(jù)塊，如果我強制性地Sleep，造成人為性的隊列阻塞，應(yīng)該是可以再現(xiàn)上面的問題的！
而事實正是如此！十幾秒之后，同樣的問題出現(xiàn)了！
由此可以斷定，這個問題是隊列阻塞所致。由于隊列是由DirectShow來管理的，所以，這里要分析和處理的話，還是比較困難的，需要重載相關(guān)的類。只能是提升壓縮效率了。
(###)
