Ошибка Гнома: Не удается найти DIE

Question

У меня много проблем с отладкой ошибки сегментации в проекте C ++ в XCode 4.

Я получаю segfault только при сборке с опцией компилятора "LLVM 2.0" и использую оптимизацию -O3. Из того, что я понимаю, возможности отладки ограничены, когда используется оптимизация, но вот выходные данные отладки, которые я получаю после запуска в Xcode с включенным gdb:

warning: Got an error handling event: "Dwarf Error: Cannot find DIE at 0x3be2 referenced from DIE at 0x11d [in module /Users/imran/Library/Developer/Xcode/DerivedData/cgo-hczcifktgscxjigfphieegbpxxsq/Build/Products/Debug/cgo]".
No memory available to program now: unsafe to call malloc

Я не могу заставить GDB дать мне какую-либо полезную информацию после этого (например, след), но я не уверен, что действительно знаю, как правильно ее использовать. Когда я пытаюсь использовать отладчик "LLDB", Xcode просто падает (это было обычной темой с тех пор, как я начал его использовать).

Моя программа детерминирована, но когда я пытаюсь изолировать проблему с помощью операторов print, поведение меняется. Например, если я добавлю cout << "hello"; в какой-то момент, segfault исчезнет. Другие операторы печати приводят к тому, что моя программа перестает работать в другой итерации своего основного цикла. И естественно, когда я вставляю достаточно выражений print, чтобы предположительно точно определить код, вызывающий сбой, segfault, кажется, происходит после одной строки, но перед следующей (т.е. нигде).

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

Я попытался выполнить профилирование с помощью инструмента "Утечки" в Инструментах, но он не обнаружил никаких утечек.

Любой совет? Я не очень разбираюсь в отладке, так что на самом деле все может помочь.

РЕДАКТИРОВАТЬ: Решено. При определенных входных данных моя программа будет пытаться прочитать после конца массива.

Answer 1

Не думаю, что есть достаточно информации, чтобы помочь вам с проблемой DWARF. Я недостаточно знаком с этим набором инструментов, чтобы понять, насколько он надежен.

Ваши симптомы сбоя, однако, пахнут очень похоже на повреждение кучи. Я не знаю, какой распределитель использует OSX по умолчанию, но обычные оптимизации хранят метаданные встроенными в объекты и / или пропускают список свободных мест через пустые объекты, что делает их очень чувствительными к переполнению буфера в куче. Освобождение объекта дважды или использование висячего указателя (указатель, который был освобожден, но чье пространство может теперь использоваться другим распределением) также может вызвать на первый взгляд недетерминированный и трудно отслеживаемый ошибки, так как компоновка кучи, вероятно, изменится между пробеги. Операторы печати также используют распределитель, что означает, что изменение операторов печати может измениться, когда и где возникнет проблема.

Инструмент, который может оказаться полезным для определения того, является ли это проблемой кучи или чем-то не связанным, является заменой кучи под названием DieHard моим советником (http://prisms.cs.umass.edu/emery/index.php?page=download-diehard). Я полагаю, что он будет основан на OSX, и вы можете связать его в вашу программу, используя LD_PRELOAD=/path/to/libdiehard.so для замены распределителя по умолчанию во время выполнения. Его единственная цель - противостоять ошибкам памяти и повреждению кучи, поэтому, если ваше приложение действительно работает с ним, вам, вероятно, нужно искать.