Мы работаем на HPUX, а мой код написан на C++. Мы получаем
BUS_ADRALN — неверное выравнивание адреса
в нашем исполняемом файле при вызове функции. Что означает эта ошибка? Одна и та же функция работает много раз, а затем внезапно выдает дамп ядра. в GDB, когда я пытаюсь напечатать значения объекта, он говорит, что не в контексте. Есть подсказка, где проверить?
У вас проблема с выравниванием данных. Вероятно, это вызвано попыткой чтения или записи через неверный указатель.
Проблема выравнивания данных возникает, когда адрес, на который указывает указатель, не «выровнен» должным образом. Например, некоторые архитектуры (например, старый Cray 2) требуют, чтобы любая попытка чтения из памяти чего-либо, кроме одного символа, происходила только через указатель, в котором последние 3 бита значения указателя равны 0. Если какой-либо из последних 3 бита равны 1, аппаратное обеспечение сгенерирует ошибку выравнивания, что приведет к проблеме, которую вы видите.
Большинство архитектур далеко не так строги, и часто требуемое выравнивание зависит от конкретного типа, к которому осуществляется доступ. Например, для 32-битного целого числа может потребоваться, чтобы только последние 2 бита указателя были равны 0, а для 64-битного числа с плавающей запятой может потребоваться, чтобы последние 3 бита были равны 0.
Проблемы с выравниванием обычно вызываются теми же проблемами, что и SEGFAULT или ошибка сегментации. Обычно указатель, который не инициализирован. Но это может быть вызвано плохим распределителем памяти, который не возвращает указатели с правильным выравниванием, или результатом арифметических операций над указателем, когда он имеет неправильный тип.
Системная реализация malloc и/или operator new почти наверняка верна, иначе ваша программа рухнет раньше, чем сейчас. Поэтому я думаю, что плохой распределитель памяти — это наименее вероятное дерево, которое начнет лаять. Я бы сначала проверил неинициализированный указатель, а затем неверную арифметику указателя.
В качестве примечания: для архитектур x86 и x86_64 нет требований к выравниванию. Но из-за того, как работают строки кэша, а также по ряду других причин, для производительности часто бывает полезно выровнять ваши данные по границе, равной размеру сохраняемого типа данных (т. е. границе 4 байта для 32-битного целого числа).
Большинству процессоров (не x86 и друзьям ... паршивая овца в семье, лол) требуется, чтобы доступ к определенным элементам был выровнен по кратным байтам. т.е. если вы читаете целое число с адреса 0x04, это нормально, но если вы попытаетесь сделать то же самое с адреса 0x03, вы вызовете прерывание.
Это связано с тем, что проще реализовать оборудование для загрузки/сохранения, если оно всегда кратно размеру данных, с которыми вы работаете.
Поскольку HP-UX работает только на процессорах RISC, которые обычно имеют такие ограничения, вы должны увидеть здесь -> http://en.wikipedia.org/wiki/Data_structure_alignment#RISC.
На самом деле у HP-UX есть свой отличный форум на ITRC, и некоторые сотрудники HP очень ему помогают. Я только что просмотрел ту же тему, о которой вы спрашиваете, и вот некоторые результаты. Например, похожая проблема была фактически вызвана неверный входной параметр. Настоятельно советую сначала прочитать ответы на похожий вопрос и при необходимости разместить свой вопрос там.
Кстати, вполне вероятно, что вас попросят опубликовать результаты этих gdb команд:
(gdb) bt
(gdb) info reg
(gdb) disas $pc-16*8 $pc+16*4
Большинство этих проблем вызвано наличием нескольких вышестоящих зависимостей, связанных с разными версиями одной и той же библиотеки.
Например, и gnustl, и stlport предоставляют разные реализации стандартной библиотеки C++. Если вы скомпилируете и скомпонуете gnustl, в то время как одна из ваших зависимостей будет скомпилирована и скомпонована для stlport, то у каждого из вас будет своя реализация стандартных функций и классов. Когда ваша программа запущена, динамический компоновщик попытается разрешить все экспортированные символы и обнаружит известные символы с неправильным смещением, что приведет к сигналу BUS_ADRALN.
