解释访问冲突异常？

Question

我们有一个围绕 VB/C++ 代码构建的自定义应用程序。 此代码将运行数天、数周、数月，而不会引发异常错误。

我正在尝试详细了解如何引发此错误，以及如何解释（如果可以）在引发异常时列出的错误。我已经搜索了一些信息并阅读了 Microsoft 提供的错误描述，但我仍然坚持解决在蓝月亮中发生的事情的任务。没有已知的与软件的交互会导致这种情况，并且似乎是随机发生的。

第一个异常是根本原因吗？一直到堆栈调用吗？谁能提供有关如何阅读这些代码的任何见解，以便我可以解释我实际需要查看的位置。

有关阅读异常或对其进行任何使用以及排除故障的任何信息或指导都会有所帮助。下面的测试是在引发事件时从 Windows 日志中复制的。

提前感谢您的帮助。

Application: Epic.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.AccessViolationException [![enter image description here][1]][1]
at MemMap.ComBuf.IsCharAvailable(Int32) 
at HMI.frmPmacStat.RefreshTimer_Elapsed(System.Object, System.Timers.ElapsedEventArgs) 
at System.Timers.Timer.MyTimerCallback(System.Object) 
at System.Threading.TimerQueueTimer.CallCallbackInContext(System.Object) 
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, 
System.Threading.ContextCallback, System.Object, Boolean) 
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, 
System.Threading.ContextCallback, System.Object, Boolean) 
at System.Threading.TimerQueueTimer.CallCallback() 
at System.Threading.TimerQueueTimer.Fire() 
at System.Threading.TimerQueue.FireQueuedTimerCompletion(System.Object) 
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() 
at System.Threading.ThreadPoolWorkQueue.Dispatch() 
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

Answer 1

由于执行 throw 表达式，c++ 运行时环境会抛出异常，还有其他类型的错误是由操作系统或硬件捕获您的指令引起的。对内存的无效访问通常不会由 c++ 中的代码抛出，而是评估试图访问无效地址处内存的表达式的副作用，导致操作系统向进程发出信号，通常会杀死它。因为它在 C++ 之外，它往往是特定于平台的，但典型的错误是：

• 读取空指针
• 使用指向已删除对象的指针
• 超出数组的有效元素范围
• 在 STL 容器中使用无效的迭代器

一般来说，您可以在运行时测试 null 和数组边界，以便在问题发生之前检测到问题。使用悬空指针更难追踪，因为从删除到误用该指针之间的时间可能很长，而且如果没有内存调试器（例如 valgrind），很难找到它发生的原因。使用智能指针而不是原始指针可以帮助缓解内存管理不善的问题，并有助于避免此类错误。

无效的迭代器是一般悬空指针问题的子集，但也很常见，值得一提。了解您的容器以及哪些操作使它们无效至关重要，并且一些实现可以在“调试模式”下编译，这有助于检测无效迭代器的使用。

Answer 2

正如其他人所指出的，如果不深入研究代码和运行测试（自动或手动），这种类型的错误很难识别。您可以拉出并仍然复制它的系统组件越多越好。分而治之是你的朋友。

除此之外，这一切都取决于解决此问题对您的重要性以及您愿意付出多少努力。至少有三类工具可以帮助解决此类间歇性问题：

1. 在应用程序运行时跟踪潜在错误的应用程序监视器。这些往往会显着减慢您的程序（减慢 10 倍或更多）。示例包括：
   1. 微软的Application Verifier
   2. 开源跨平台Dr. Memory
   3. 谷歌的Crashpad。与前两个程序不同，这个程序需要检测您的代码。它也（据称 - 没有尝试过）更容易与 Backtrace's commercial integration for analyzing Crashpad output 等助手一起使用
   4. Google 的Sanitizers - 免费，有些内置于 gcc 和 clang。还有一个Windows port of Address Sanitizer，但粗略一看，可能有点二等公民。
   5. 如果你可以在 Linux 上运行和重现它，你可以使用valgrind； rr（参见this CppCast ep）是gdb 的免费扩展，可以记录和重放您的程序，以便您可以记录崩溃的调试会话，然后单步执行以查看问题所在；和/或 UndoDB 和 Undo 软件的朋友，这是一个更复杂的商业产品，如 rr。
2. 代码的静态分析。这是一组用于查找代码中常见错误的工具。它通常具有较低的信噪比，因此如果您在现有的大型项目上运行它（最好从一开始就使用这些东西开始一个项目），那么有很多小事情需要挖掘。也就是说，许多警告是无价的。例子：
   1. 大多数编译器都内置了此功能的子集。如果您使用的是 Visual Studio，请将 /W4 /WX 添加到 C++ 代码的编译标志中以强制发出最大警告，然后修复所有警告。对于 gcc 和 clang，添加 '-Wall -Wpedantic -Werror` 以强制不发出警告。
   2. PVS-Studio（商业）
   3. PC-Lint（商业）
3. 如果您可以检测代码以编写日志消息，Debugview++ 之类的内容可能会有所帮助。

如果您正在进行多线程处理，事情会变得更加困难，看起来您确实这样做了，因为不确定性变得更难跟踪，引入了新的可能错误类别，并且上述一些工具不会运行良好（例如，我认为 rr 只是单线程的）。除了像 Visual Studio 这样的完整 IDE，您还需要使用 Intel 的 Inspector（以前的 Intel Thread Checker），或者在 Linux、Valgrind 的 Helgrind 和 DRD 和 ThreadSanitizer（在上面的消毒剂中，但也仅限 Linux AFAIK）。但希望这份清单能给你一个开始的地方。