Delphi DLL线程随机Access Violation问题排查求助

核心定位方向 #

从你的测试场景来看，问题仅在主程序主线程调用DLL的Push方法 + DLL使用TThread的组合下触发，其他场景正常，说明问题出在跨模块内存边界、回调的调用约定/上下文，或TThread在DLL中的生命周期管理这几个交叉点上。

针对性排查与修复方案 #

1. 回调相关问题排查 #

你怀疑回调是诱因的方向是对的，重点检查以下几点：

• 调用约定一致性：主程序与DLL中声明回调函数时，必须显式指定相同的调用约定（如stdcall或cdecl）。Delphi默认的register约定是寄存器优化的，跨模块调用会破坏栈平衡，直接导致随机AV。
• 跨模块内存管理：如果回调中操作了主程序的对象或内存，必须确保DLL与主程序共享同一内存管理器——两者都要在单元列表最顶部引用ShareMem单元，否则跨模块分配/释放内存会触发访问错误。
• 回调生命周期：确认DLL在调用回调时，主程序侧的回调函数/对象未被提前释放。可以在主程序中保持回调对象的强引用，直到DLL完全停止调用后再释放。

2. TThread在DLL中的坑点修复 #

Delphi的TThread依赖RTL实现，在DLL中使用时需注意：

• 线程对象的边界隔离：DLL中的TThread对象必须完全在DLL内部创建、启动、终止和释放，禁止主程序直接操作该对象——主程序与DLL的RTL实例可能不同，跨模块操作对象内存会导致AV。
• 避免依赖主程序消息循环：TThread.Synchronize方法依赖主程序的消息循环完成同步，如果主程序是控制台程序或消息循环异常，会导致同步失败甚至AV。建议用原生Windows事件（TEvent）或临界区手动实现同步，替代Synchronize。
• DLL卸载时的线程清理：在DLL的finalization块或DllMain的DLL_PROCESS_DETACH分支中，必须确保所有线程已终止并释放资源，否则主程序卸载DLL时，运行中的线程会访问已释放的内存空间。

3. 同步锁的正确性校验 #

你已尝试TRTLCriticalSection，但需确认：

• 临界区的生命周期管理：在DLL初始化时调用InitializeCriticalSection，卸载时调用DeleteCriticalSection，禁止重复初始化或遗漏销毁。
• 全路径同步覆盖：所有对队列的操作（Push、Pop、长度读取等）必须包裹在临界区中，包括DLL线程内部的队列读取操作——队列的内部状态（如节点指针、计数）随时可能被主线程修改，遗漏同步会导致数据结构损坏。
• 避免嵌套死锁：梳理回调与DLL方法的调用链，禁止在已进入临界区的代码中再次请求同一临界区，也避免回调中触发其他需要锁的DLL操作。

4. 队列容器的内存边界检查 #

如果使用Delphi自带容器（如TQueue）或自定义队列：

• 容器的模块内生命周期：队列必须在DLL内部创建和销毁，禁止主程序创建容器后传入DLL使用——跨模块的容器操作会因为内存管理器不共享导致AV。
• 消息对象的内存归属：动态分配的消息对象，必须在同一模块内完成分配与释放（DLL分配的由DLL释放，主程序分配的由主程序释放），或通过ShareMem统一管理跨模块内存。

AV报错示例分析 #

以常见报错Access violation at address 00401234 in module 'MyApp.exe'. Read of address 00000000为例：

• 读取0地址：通常是回调指针被置为nil，或者回调关联的对象已被释放。
• 读取无效非0地址：大概率是跨模块内存访问错误，或队列内部结构因同步缺失被破坏。

快速验证步骤 #

1. 临时移除回调逻辑，测试主线程调用Push是否仍触发AV——若不再触发，直接定位到回调问题。
2. 将DLL中的TThread替换为原生Windows线程（CreateThread），排除TThread的RTL兼容性问题。
3. 开启FastMM内存检测（DLL与主程序均开启），通过内存泄漏/越界提示精准定位问题。

内容的提问来源于stack exchange，提问作者Nick