昨天我在除錯一些程式，在重新啟動偵錯程式後，我看見status標籤一直卡在初始化。之後便崩潰
重現步驟：
- 載入一些偵錯程式
- 保持單步一段時間
- 按下重新開始
- 重複直到bug出現
現象：
- 標籤卡在初始化
- 標籤卡在暫停
在獲得穩定的重現後，我開始尋找這為什麼發生。taskthread看起來是正確的，但由於wakeup函式可能失敗，我在releasesemaphore上放置了乙個斷言，這應該能出發taskthreadl:
template
void taskthread_::wakeup(args... _args)
struct debugstruct
;template
taskthread_::taskthread_(f fn,
size_t minsleeptimems, debugstruct* debug) : fn(fn), minsleeptimems(minsleeptimems)
initializecriticalsection(&this->access);
this->thread = std::thread([this, debug]
);}
void guisetdebugstateasync(dbgstate state)
但是，當我再次檢查檢查控制代碼檢視，0x640不再是訊號量的控制代碼，而是乙個對映檔案
方法很簡單
1. 掛鉤closehandle api
1. 吧當前的訊號量控制代碼儲存到乙個全域性變數中
1. 如果過控制代碼已經被釋放就崩潰
static debugstruct* g_debug = nullptr;
typedef bool(winapi* closehandle)(handle hobject);
static closehandle fpclosehandle = nullptr;
static bool winapi closehandlehook(handle hobject)
static
void dohook()
但是為什麼訊號量控制代碼回合之前的乙個檔案控制代碼相同呢，答案就在以下事件
load_dll_debug_event 從鍊錶中獲取檔案控制代碼
load_dll_debug_event 立即關閉之前的檔案控制代碼在除錯會話
當偵錯程式第一次中斷並且訊號量被用之前的檔案控制代碼（現在被關閉了）建立，taskthread的靜態初始化器被呼叫
這一切都運轉正常，知道forceclose方法被呼叫並且來自於load_dll_debug_event檔案控制代碼再次被關閉
taskthread中斷
mysql控制代碼 MySQL與控制代碼 MySQL
bitscn.com 1.環境 os win 2003 server x86 db mysql 5.1.30 community log 2.問題 mysql server占用的控制代碼數過大，使用過程消費控制代碼速度比釋放速度來的快，部分其他應用申請不到控制代碼，導致不可用。2.1.handle ...
初探UAF漏洞 2016 HCTF fheap
ctf wiki 剛學堆，學到了uaf use after free 漏洞，uaf本質是free後，並沒有把指標指向null，導致free後，指標還可被使用。用2016 hctf fheap來說明一下。題目也在參考鏈結裡。看到這個程式實現了3個功能，add note,delete not,print...
控制代碼類與繼承
前一小節 容器與繼承 提到過 對於容器，如果定義為基類型別，那麼則不能通過容器訪問派生類新增的成員 如果定義為派生類型別，一般不能用它承載基類的物件，即使利用型別轉化強行承載，則基類物件可以訪問沒有意義的派生類成員，這樣做是很危險的。對這個問題的解決辦法，是使用容器儲存基類的指標。在c 中，這類問題...