Как отладить / сообщить о «обнаруженном нарушении доступа - продолжайте с осторожностью»

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 рвало. Как я узнаю, где это? Есть ли способ заглянуть глубже в вершину стека? functionToTest - это функция, которая вызывает другие функции и так далее. Я пытаюсь выделить проблему, чтобы сообщить о ней, но не знаю как.

Answer 1

Я получил эту ошибку перед жаркой модуля памяти на моем Windows 2008 R2 64-битной коробке.Я выполнял задачу с интенсивным использованием памяти, используя пакет rgeos;интенсивное использование памяти, поскольку этот пакет страдает от утечки памяти в библиотеке GEOS C, к которой он подключен.Несмотря на попытки устранить утечку, она все еще сохраняется.

Я предполагаю, что я получил эту ошибку как из-за сбоя модуля памяти, так и из-за интенсивного истощения памяти, вызванного этой утечкой памяти.

Я должен отметить, что модуль памяти теперь удален, и я выполняю идентичные анализы с этим все еще утечкой памяти, и с тех пор я никогда не получал ошибку.

Пожалуйста, рассмотрите возможность того, чтоэто аппаратная проблема, и ваш код каким-то образом ее стимулирует.Ключевым признаком этого может быть то, что это иногда работает ... но не обязательно, поскольку память может быть пагубной в моем опыте.

Вы можете предпринять следующие шаги, чтобы исключить / исключить эту возможность:

1. Запустите процедуру оскорбления и наблюдайте за использованием памяти, используя Resource Monitor или другое эквивалентное программное обеспечение.Является ли он необычно высоким для процесса R?

2. Использование options(error=recover) и добавление в код некоторого итератора, который может отмечать ход цикла, который предположительно находится в работе.Он каждый раз падает на одну и ту же точку или отличается?Если он отличается для идентичных условий, это говорит о случайности аппаратной ошибки.

3. Если эти шаги указывают на что-то случайное, то примите меры для проверки состояния памяти.На StackExchange SuperUser .

ведутся многочисленные обсуждения.

Answer 2

?traceback
?browser

За исключением того, что для ошибок R. Интересно, вы получаете сообщение, генерируемое ОС, и для этой возможности вы определенно не предоставили достаточно информации, чтобы кто-нибудь мог вам помочь.