得到了可怕的消息（它取代了死亡的蓝屏=）。堆栈跟踪中的第二个到顶部项是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是一个调用其他函数的函数，依此类推。我试图找出问题，以便我可以报告，但我不知道如何。
答案 0 :(得分：1)
我在Windows 2008 R2 64位盒子上煎炸内存模块之前收到此错误。我正在使用rgeos包执行内存密集型任务;内存密集，因为此程序包在其所连接的GEOS C库中遭受内存泄漏。尽管试图修复泄漏，它仍然存在。
我猜我收到了这个错误，因为内存模块出现故障以及此内存泄漏造成的内存消耗严重。
我应该注意，内存模块现已被删除，我使用这个仍然存在内存泄漏的包执行相同的分析，但我从未收到错误。
请考虑这是硬件问题的可能性，并且您的代码以某种方式刺激它。一个关键的迹象是，它有时会起作用......但不一定因为记忆在我的经历中可能是有害的。
您可以采取以下步骤来排除/统治这种可能性：
使用资源监视器或其他等效软件运行违规程序并观察内存使用情况。 R过程是否异常高？
使用options(error=recover)并在代码中添加一些迭代器，以便标记可能正在运行的循环的进度。它每次都会在同一点崩溃，还是会有所不同？如果它在相同的条件下不同，则表明硬件错误的随机性。
如果这些步骤表示随机，则采取措施检查您的记忆健康状况。有关如何在StackExchange SuperUser上执行此操作的讨论很多。
答案 1 :(得分：0)
?traceback
?browser
除了R错误。我想知道你是否收到了操作系统生成的消息，而且对于这种可能性，你绝对没有提供足够的信息让任何人都能提供帮助。