如何调试/报告“捕获的访问冲突 - 继续小心”

Question

得到了可怕的消息（它取代了死亡的蓝屏=）。堆栈跟踪中的第二个到顶部项是do.call（...）调用，它会自动打印。堆栈的顶部似乎是截止的，因为我只能看到数据：

 ...1018L, 1018L, 1018L, 1018L, 1018L, 1018L, 1018L,     1018L, 1018L, 1018L, 1018L, 1018L, 1018L, 1018L, 1018L, 1018L,     1018L, 1018L, 1018L, 1018L, 1018L, 1018L, 1018L, 1018L)))
     2: do.call(functionToTest, c(thisTestCaseParameters, fixedParameterValues))

traceback没有提供比do.call调用更多的信息

所以functionToTest中的某些东西必须是puked。我怎么弄清楚它在哪里？有没有办法深入了解堆栈的顶部？ functionToTest是一个调用其他函数的函数，依此类推。我试图找出问题，以便我可以报告，但我不知道如何。

Answer 1

我在Windows 2008 R2 64位盒子上煎炸内存模块之前收到此错误。我正在使用rgeos包执行内存密集型任务;内存密集，因为此程序包在其所连接的GEOS C库中遭受内存泄漏。尽管试图修复泄漏，它仍然存在。

我猜我收到了这个错误，因为内存模块出现故障以及此内存泄漏造成的内存消耗严重。

我应该注意，内存模块现已被删除，我使用这个仍然存在内存泄漏的包执行相同的分析，但我从未收到错误。

请考虑这是硬件问题的可能性，并且您的代码以某种方式刺激它。一个关键的迹象是，它有时会起作用......但不一定因为记忆在我的经历中可能是有害的。

您可以采取以下步骤来排除/统治这种可能性：

1. 使用资源监视器或其他等效软件运行违规程序并观察内存使用情况。 R过程是否异常高？

2. 使用options(error=recover)并在代码中添加一些迭代器，以便标记可能正在运行的循环的进度。它每次都会在同一点崩溃，还是会有所不同？如果它在相同的条件下不同，则表明硬件错误的随机性。

3. 如果这些步骤表示随机，则采取措施检查您的记忆健康状况。有关如何在StackExchange SuperUser上执行此操作的讨论很多。

Answer 2

?traceback
?browser

除了R错误。我想知道你是否收到了操作系统生成的消息，而且对于这种可能性，你绝对没有提供足够的信息让任何人都能提供帮助。