стек вызовов показывает SIGBUS, что это значит
Мой стек вызовов показывает следующее:
--- called from signal handler with signal 10 (SIGBUS) ---
001301b8 allocate__t24__default_alloc_template2b0i0Ui (20, 20, 309940, 36, fc55
1a00, 0) + a4
0011dcb8 __nw__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc
_template2b0i0_3RepUiUi (10, 10, 7773e8, 0, 0, 0) + 14
0011dcf8 create__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_all
oc_template2b0i0_3RepUi (a, a, 7773e8, a, 0, 0) + 24
0011e0bc replace__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_allo
c_template2b0i0UiUiPCcUi (fbcff5c0, 0, ffffffff, fcbf55e2, a, 80808080) + 114
00133ef0 assign__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc
_template2b0i0PCcUi (fbcff5c0, fcbf55e2, a, ffffffff, ffffffff, 20) + 24
00132c78 assign__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc
_template2b0i0PCc (fbcff5c0, fcbf55e2, 15b0, 15d0, 16f0, 0) + 24
0012f970 __t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_templ
ate2b0i0PCc (fbcff5c0, fcbf55e2, fcbf55d8, fbcff70e, 10, e00) + 28
001f7e0c getFiles__7ListDirb (fbcff8e4, 0, 241000, 0, 4e61a0, ff11f478) + 144
. . .
Означает ли это, что при выделении памяти происходит слишком много памяти?
Как я могу проверить / увеличить объем используемой памяти, чтобы определить, в чем заключается проблема в таких случаях?
Могу ли я переопределить allocate__t24__default_alloc_template2b0i0Ui то есть __default_alloc_template<false, 0>::allocate(unsigned int) чтобы он вызывал обычай выделять вызов?
Решение
стек вызовов показывает SIGBUS, что это значит
Вероятно, было бы полезно показать верхнюю часть стека вызовов, чтобы мы могли проверить выравнивание указателей. Также было бы полезно узнать платформу и инструкцию, которая вызвала SIGBUS,
Это был мой опыт SIGBUS часто связано с невыровненными данными. Прежде чем спуститься в кроличью нору, попробуйте добавить -xmemalign=4i или же -xmemalign=8i в CFLAGS а также CXXFLAGS,
Кажется, я помню, что у Sparc есть инструкция, которая может работать более эффективно на более широких данных, но очень чувствительна к выравниванию. Если вы бросите uint8_t* к uint32_t* или же uint64_t*тогда этот буфер действительно необходимо выровнять, потому что SunCC по умолчанию будет генерировать более эффективный ход. Это строгое нарушение алиасинга, о котором говорит Андре. Солнце не похоже на x86, и оно тоже будет SIGBUS если ты обманул.
Также см B.2.111 -xmemalign = ab в руководстве Солнца. Есть также много хороших хитов для Google «-xmemalign = 4i». Проблема в том, что до тех пор, пока вы не столкнетесь с проблемой и не доберетесь до ее сути, вы не знаете, что вам нужно искать.
(Я провел месяцы, гоняясь за одной аварией на Sparc, в ходе самопроверки, и это было из-за грязного броска и более широкой инструкции по перемещению. -xmemalign=4i исправил это для меня).
Другие решения
Других решений пока нет …