zamzll的专栏

引发:使用项目的ipc时发现不能向主线程抛apc消息,后编写测试代码经反复测试发现测试代码也无法发送:主线程:子线程:下面的内核调试记录对本次问题查找本无益处,但还是花费了大量时间,需要记录: 因为apc为内核支持的功能,所以有幸可以从wrk代码找到原因,在找到问题前隐约的怀疑是向上抛出消息的时候出了问题,所以首先想到的是确认内核态的apc分发到底是不是在子线程: 记录:反复实验后发现,子线程的

一处内存泄漏： 稳定性测试抛出了内存泄漏问题，内存在24小时内从150M涨至350M 上测试机排查： ！heap -l 发现大量28字节，18字节左右的小内存泄漏db看一下泄漏内容 大量的内存地址指向swmanager\0 这个字符串，代码中搜索swmanager” 发现有10几处使用裸的字符串。 咨询对应的研发RD发现其中关于tips逻辑引用最频繁: 该处为在

1,定义一个宏函数,使得,func(x) = x-1?     最简单的, 如果x = 2则 #define func(x) 1特化出来x,令#define func_helper_2 1#define func(x) func_helper_##x这样在x=2时就成立了.推广到其他数字只需定义:#define func_helper_2 1#define func_h

nsis的固实(solid)压缩问题由解压框而来解压框显示的逻辑是这样的1,运行第一步是进行crc校验,校验的过程大约4kb的步长读取exe文件,并做crc校验,每一次校验检查当前校验时间是否已经超过了1s,超过则展现解压框2,压缩文件时固实算法是,将所有文件按照如下格式 |FileSize|FileContent|FileSize2|FileContent2|... 将所有文件拼

原因:一开始想查找由于ipc初始化顺序的问题导致tray卡死的原因,但恰好遇到主进程弹出退出确认框后也卡死了,于是开始查找原因.首先是跟踪代码,发现消息循环是活着的,但整个消息循环只能取到timer和paint消息,使用消息工具抓窗口,可以看到也可以取到GetItemText等消息.(一般来讲这时已经可以定位是由于attachthreadinput的原因了,但这时候我还不知道);