调用堆栈显示SIGBUS，这是什么意思 [英] call stack shows SIGBUS, what does that mean

问题描述

我的调用堆栈显示以下内容：

My call stack shows the following:

 --- 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）

Does that mean allocation failing means too much memory has been occupied? How can I check/monitor memory usage grow and shrink to find out where lies the problem in such cases? May I override allocate__t24__default_alloc_template2b0i0Ui i.e. __default_alloc_template<false, 0>::allocate(unsigned int) so that it calls custom allocate call?

推荐答案

调用堆栈显示SIGBUS，这是什么意思

call stack shows SIGBUS, what does that mean

显示调用堆栈的顶部可能会有所帮助，以便我们检查指针的对齐方式。了解导致 SIGBUS 的平台和说明也将有所帮助。

It would probably be helpful to show the top of the call stack so we can inspect alignment of pointers. It would also be helpful to know the platform and the instruction that caused the SIGBUS.

这是我的经验 SIGBUS 通常与未对齐的数据有关。在掉进兔子洞之前，尝试将 -xmemalign = 4i 或 -xmemalign = 8i 添加到 CFLAGS 和 CXXFLAGS 。

Its been my experience SIGBUS is often related to unaligned data. Before you go down a rabbit hole, try adding -xmemalign=4i or -xmemalign=8i to CFLAGS and CXXFLAGS.

我似乎记得Sparc的指示是可以更有效地处理更广泛的数据，但对对齐非常敏感。如果将 uint8_t * 转换为 uint32_t * 或 uint64_t * ，则必须对齐缓冲区 really ，因为默认情况下SunCC会生成更有效的移动。这是安德烈所说的严格混叠违规。 Sun不像x86，如果被骗，它也会 SIGBUS 。

I seem to recall Sparc's have an instruction that can operate more efficiently on wider data but its very sensitive to alignment. If you cast a uint8_t* to a uint32_t* or uint64_t*, then that buffer really needs to be aligned because SunCC will generate the more efficient move by default. This is the strict aliasing violation Andre speaks of. Sun is not like x86, and it will also SIGBUS if you cheated.

另请参见 B.2.111 -xmemalign = ab 。 Google -xmemalign = 4i 。麻烦的是，直到您忍受了这个问题并找到根底，您才不知道这就是您要寻找的东西。

Also see B.2.111 -xmemalign=ab in the Sun manual. There are also a lot of good hits for Google "-xmemalign=4i". The rub is, until you suffer the problem and get to the bottom of it, you don't know that's what you need to search for.

（我花了几个月的时间来追逐在一次自检中Sparc崩溃，这是由于不正确的转换和更宽的移动指令所致。 -xmemalign = 4i 为我修复了此问题。

(I spent months chasing one crash on a Sparc in a self test and it was due to a dirty cast and the wider move instruction. -xmemalign=4i fixed it for me).

这篇关于调用堆栈显示SIGBUS，这是什么意思的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！