Normally, the break instruction exception can be triggered in following conditions:
1. Hardcode interrupt request, like: __asm int 3 (ASM), System.Diagnostics.Debugger.Break (C#), DebugBreak() (WinAPI).
2. OS enable memory runtime check, like Application Verifier can trigger after heap corruption, memory overrun.
3. Compiler can have some configuration to decide what should be filled to the uninitialized memory block and end of function(blank area, after retun..). For example, Microsoft VC complier can fill 0xCC if enable /GZ. 0xCC is actually a opcode of __asm int 3. So if some error cause the application run into such block, will trigger a break point.
A quick summary of what Microsoft's compilers use for various bits of unowned/uninitialized memory when compiled for debug mode (support may vary by compiler version):
Value Name Description
------ -------- -------------------------
0xCD Clean Memory Allocated memory via malloc or new but never
written by the application.
0xDD Dead Memory Memory that has been released with delete or free.
Used to detect writing through dangling pointers.
0xFD Fence Memory Also known as "no mans land." This is used to wrap
the allocated memory (surrounding it with a fence)
and is used to detect indexing arrays out of
bounds or other accesses (especially writes) past
the end (or start) of an allocated block.
0xCC When the code is compiled with the /GZ option,
uninitialized variables are automatically assigned
to this value (at byte level).
// the following magic values are done by the OS, not the C runtime:
0xAB (Allocated Block?) Memory allocated by LocalAlloc().
0xBAADF00D Bad Food Memory allocated by LocalAlloc() with LMEM_FIXED,but
not yet written to.
0xFEEEFEEE OS fill heap memory, which was marked for usage,
but wasn't allocated by HeapAlloc() or LocalAlloc().
Or that memory just has been freed by HeapFree().
Disclaimer: the table is from some notes I have lying around - they may not be 100% correct (or coherent).
As others have noted, one of the key properties of these values is that is a pointer variable with one of these values is dereferenced, it will result in an access violation, since on a standard 32-bit Windows configuration, user mode addresses will not go higher than 0x7fffffff.
For the related issue, we can use Application Verifier to enable heap page, which can break after memory overrun, heap corruption.
]]>
]]>
--銆婅璇粖瑙?#183;瀛﹁岀涓銆?br>
鑻ヨ杈懼埌涓涓洰鏍囷紝蹇呴』寰叾鏍規湰錛屾牴鏈鑳界‘瀹氾紙鏈珛錛夛紝閭ｄ箞渚垮鏄撴壘鍑鴻В鍐崇殑鏂規硶錛堥亾鐢燂級銆傚緢澶氭椂鍊欏氨鏄繖鏍風殑閬撶悊錛岄亣鍒頒竴涓棶棰橈紝瑕佽拷絀跺埌搴曟墠鏄紝鏇翠綍鍐墊槸鎴戜滑鍋氭妧鏈殑錛岃寰楃涓嬈＄湅瑙佽繖涓?#8220;鏈珛閬撶敓”鐨勮瘝鐨勬椂鍊欐槸鍦ㄥ欐嵎緲昏瘧鐨勩奍nside C++ Object Model銆嬭繖涓槸浣滀負浠栫殑搴忚█鐨勬爣棰樼殑銆傚叾瀹炲綋浣犵湡鐨勪簡瑙ｅ緢澶氱粏鑺傜殑鏃跺欎綘鎵嶈兘鐪熸鐨勪綋浼氬埌鎶鏈殑欖呭姏錛岃屼笉鏄唬鐮佺殑濂撮毝錛?br>
Class Compare
{
public: bool operator (int iFrst, int iSecond) const
{ // Do some thing return false; // Or true
}
};// SortList(List& list, int iSize, const Compare& compareObj)SortList(list, 1000, com);濡備笂闈㈢殑鎵紺猴紝榪欎釜class鐨勯噸杞界殑operator()鏄劇劧灝辨槸甯︽湁inline鐨勫睘鎬т簡錛岃繖涓椂鍊欑紪璇戝櫒鑳藉仛鐨勬槸鍦ㄨ兘澶熺‘瀹氬璞＄被鍨嬬殑鏃跺欏鏋滆繖涓唬鐮佷笉鏄お澶э紙褰撶劧榪樿姹備綘鐨勭紪璇戝櫒鍐呰仈閫夐」瀹硅鐘舵?img src="http://m.shnenglu.com/CuteSoft_Client/CuteEditor/images/emsmilep.gif" align=absMiddle border=0>錛夐偅涔堝氨浼氬湪璋冪敤鐐瑰唴鑱斿睍寮銆備絾鏄鏋滄槸callback鍛紵鑲畾涓嶆槸錛屽洜涓轟粬鐢ㄥ埌浜嗗嚱鏁版寚閽堬紝鍗充嬌鏄繖涓嚱鏁板畾涔夋垚浜唅nline,榪欎釜鏃跺欎篃涓嶄細鍋氬唴鑱斿睍寮鐨勶紙榪欎釜鏃跺欎細鏈夌敓鎴愪竴涓被浼煎叏灞鐨勫嚱鏁頒唬鐮佸潡錛屽洖鎺夌殑鎸囬拡灝辨寚鍚戣繖涓潡錛岀紪璇戝櫒浼氱淮鎶よ繖涓唬鐮佸潡鐨勫敮涓鎬э級銆傛墍浠ワ紝濡傛灉瑕佹槸浠垮嚱鏁拌姹傜‘淇濆唴鑱斿睍寮鐨勪細錛岃鍞竴紜繚鐨勬槸錛屼唬鐮佷腑鐨勮皟鐢ㄧ偣搴旇鏄彲浠ョ‘瀹氱被鍨嬬殑錛岃兘澶熷仛鍐呰仈灞曞紑銆傜劧鍚庯紝榪欎釜浠垮嚱鏁板ぇ澶氭暟鎯呭喌涓嬫槸娌℃湁澶氭佷互鍙婄戶鎵夸即闅忓乏鍙崇殑錛屾墍浠ヨ繖涓猵erformance鏄緢閲嶈鐨勫尯鍒箣涓錛屽挨鍏舵槸鍦ㄤ綘闇瑕佸鐞嗗ぇ閲忕殑鍚岀被鏁版嵁鐨勬椂鍊欙紝姣斿涓婇潰鐨勮繖涓緥瀛愶紝濡傛灉iSize寰堝ぇ錛岀敋鑷蟲槸涓婁竾鐨勶紝閭ｄ箞榪欎釜鏃跺欑殑performance浼拌宸埆灝變細澶ぇ浜嗐備篃璁鎬綘鐨凜PU棰戠巼鏇撮珮錛屼絾鏄洿澶氱殑鏄彲鑳芥槸榪欎釜娌℃湁蹇呰鐨勬崯澶便傚懙鍛點?br>
灝忔彁紺猴細濡備綍鍒ゆ柇涓涓嚱鏁拌皟鐢ㄦ槸鍚﹁鍐呰仈灞曞紑錛?br>鏂規硶錛?.浣犲綋鐒跺彲浠ョ敓鎴愭眹緙栵紝鑷繁鍘葷湅銆?.浣犲彲浠ュ湪璋冪敤鐐硅緗柇鐐癸紝鐪嬬湅鑳戒笉鑳借窡榪涘幓錛燂紙鍐呰仈鐨刣ebug涓嶈兘璺熻繘鍘誨嚱鏁幫紝鑷沖皯鐩墠鎴戞墍鐭ラ亾鐨勭紪璇戝櫒鏄繖鏍風殑錛夈?.褰撶劧鏇村鐨勬椂鍊欏湪璋冪敤鐐硅緗柇鐐癸紝鐒跺悗鏌ョ湅姹囩紪浠ｇ爜鎵嶆槸鏈鏉冨▉鐨勶紝涔熸槸姣旇緝綆鍗曠殑鏂規硶銆?
]]>
]]>
]]>
]]>
]]>
浼犺涓紝鍑ゅ嚢鏄漢涓栭棿騫哥鐨勪嬌鑰咃紝姣忎簲鐧懼勾錛屽畠灝辮鑳岃礋鐫縐瘡浜庝漢涓栭棿鐨勬墍鏈変笉蹇拰浠囨仺鎭╂紝鎶曡韓浜庣唺鐔婄儓鐏腑鑷剼錛屼互鐢熷懡鍜岀編涓界殑緇堢粨鎹㈠彇浜轟笘鐨勭ゥ鍜屽拰騫哥銆傚悓鏍峰湪鑲変綋緇忓彈浜嗗法澶х殑鐥涜嫤鍜岃疆鍥炲悗瀹冧滑鎵嶈兘寰椾互鏇寸編濂界殑韜綋寰椾互閲嶇敓銆傝繖孌墊晠浜嬩互鍙婂畠鐨勬瘮鍠繪剰涔夛紝鍦ㄤ經緇忎腑錛岃縐頒負鈥?/span>娑呯鈥?/span>銆?銆婃秴紓愭棤鍚嶈銆嬩腑鐨勮杞藉涓嬶細鈥?鏃犲悕鏇幫細澶嚦浜虹┖媧炴棤璞★紝鑰屼竾鐗╂棤闈炴垜閫犮備細涓囩墿浠ユ垚宸辮咃紝鍏跺敮鍦ｄ漢涔庯紒浣曞垯錛?闈炵悊涓嶅湥錛岄潪鍦ｄ笉鐞嗭紝鐞嗚屼負鍦ｈ咃紝鍦ｄ漢涓嶅紓鐞嗕篃銆傛晠澶╁笣鏇幫細鑸嫢褰撲簬浣曟眰錛熷杽鍚夋洶錛氳埇鑻ヤ笉鍙簬鑹蹭腑姹傦紝浜︿笉紱諱簬鑹蹭腑姹傘傚張鏇幫細瑙佺紭璧蜂負瑙佹硶錛岃娉曚負瑙佷經錛屾柉鍒欑墿鎴戜笉寮備箣鏁堜篃銆傛墍浠ヨ嚦浜烘垻鐜勬満浜庢湭鍏嗭紝钘忓啣榪愪簬鍗沖寲錛屾誨叚鍚堜互闀滃績錛屼竴鍘繪潵浠ユ垚浣撱傚彜浠婇氾紝濮嬬粓閫氾紝絀鋒湰鏋佹湯錛岃帿涔嬩笌浜屻傛旦鐒跺ぇ鍧囷紝涔冩洶娑呯銆傜粡鏇幫細涓嶇璇告硶鑰屽緱娑呯銆傚張鏇幫細璇告硶鏃犺竟錛屾晠鑿╂彁鏃犺竟錛屼互鐭ユ秴紓愪箣閬擄紝瀛樹箮濡欏銆傚濂戜箣鑷達紝鏈箮鍐ヤ竴錛岀劧鍒欑墿涓嶅紓鎴戯紝鎴戜笉寮傜墿錛岀墿鎴戠巹浼氾紝褰掍箮鏃犳瀬錛岃繘涔嬪紬鍏堬紝閫涔嬪紬鍚庯紝宀傚緇堝浜庡叾闂村搲錛佸ぉ濂蟲洶錛氳嗗勾瑙ｈ劚錛屼害濡備綍涔呫?span lang="EN-US">鈥澛?/span>
緲昏瘧鎴愭垜浠幇鍦ㄧ殑璇█錛氭棤鍚嶈呰錛岃揪鍒頒竴瀹氬鐣岀殑浜哄繀鏈夌┖瀵傜伒鏄х殑浣撻獙錛屼綋楠屽埌絀哄錛屽氨涓嶄細鍦ㄦ剰涓栫晫涓囪薄鐨勪簨鐗╋紝涓囩墿鐢辨垜蹇冩祦鍑猴紝鎵т竾鐗╀笌鎴戝悎涓錛屽彧鏈夊湥浜鴻兘鍋氬埌錛佷負浠涔堣繖鏍瘋鍛紵鍥犱負涓嶆帉鎻¤繖涓湡鐞嗗氨涓嶈兘鎴愪負鍦ｄ漢錛屽弽涔嬶紝涓嶆槸鍦ｄ漢涔熶笉鑳界煡閬撹繖涓湡鐞嗭紝姝ｅ洜涓烘帉鎻′簡榪欎釜鐪熺悊鎵嶆垚涓哄湥浜猴紝鎵浠ュ湥浜轟笌鐪熺悊濂戝悎鏃犻棿錛屽嚒鏄湥浜洪兘涓嶈兘紱誨紑榪欎釜鐪熺悊錛佽繖姝ｅ鑸嫢瑙傜収鎵璇寸殑鑹插績涓嶄簩錛岀浉鍗崇浉紱伙紝絀哄嵆鏄壊錛岃壊鍗蟲槸絀虹殑涓嶄簩涔嬬悊銆備粠緙樿搗娉曠殑瑙掑害鏉ョ湅錛屼竾娉曚負絀猴紝絀轟負涓囨硶錛岃浣涘嵆瑙佹硶錛岃娉曞嵆瑙佺┖錛岃娉曟х┖錛屽嵆鎴愯浣涳紝鐗╂垜涓ゅ繕錛屼笉涓涓嶅紓銆傛墍浠ラ氳揪絀哄鐨勫湥浜烘繪槸鍕樼巹鏈轟簬鍏堝厗錛岄殣鏈潵浜庡彉鍖栵紝灝嗕笢鍗楄タ鍖椾笂涓嬪叚鍚堢粺鎽勪竴蹇冿紝榪囧幓鏈潵鍚屾垚涓浣撱傚彜鏉ヤ粖寰閮芥槸涓鏍鳳紝絀鋒湰鏋佹湯錛屾病鏈変簩鑷淬傚皢嫻╂旦鐒剁墿鎴戜竴蹇冿紝灝辨槸娑呯銆傝繖灝辨槸浣涚粡閲岃鐨?span lang="EN-US">鈥?/span>涓嶇璇告硶鑰屽緱娑呯鈥?/span>銆傚張鍥犱負璇告硶鏃犺竟錛屾晠姹傚緱瑙ｈ劚涔熸棤灝斤紝鐢辨槸鎺ㄧ煡錛屾秴紓愪箣閬撳湪浜庝繚鎸佸浼氬鐞嗕箣鈥?/span>濡欏鈥?/span>錛屾湁浜?span lang="EN-US">鈥?/span>濡欏鈥?/span>錛屼箖鐭ヤ竾娉曞啣鐒朵竴浣撶殑鐪熺悊銆備竾鐗╀笌鎴戞病鏈夋湰璐ㄧ殑宸埆錛屾垜涓庝竾鐗╁疄璐ㄤ竴鏍鳳紝鐗╀笌鎴戠巹濡欎細閫氾紝鏃犳瀬鏄畠浠渶鍚庡綊瀹褲傛秴紓愬氨鏄繘鑰屼笉鍓嶏紝閫鑰屼笉鍚庯紝鏃犲鏃犵粓錛岀粓濮嬩笉鍦ㄥ叾闂達紒澶╁コ璇達細鑰嗗勾錛堣垗鍒╁紬鈥斺?/span>寮曡呮敞錛夌殑瑙ｈ劚涔熸棤緇堝銆?
]]>
]]>