我的调用堆栈显示如下:
--- 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)以便它调用自定义分配调用？
最佳答案
call stack shows SIGBUS, what does that mean
显示调用堆栈的顶部可能会有所帮助，这样我们就可以检查指针的对齐情况。了解导致 SIGBUS 的平台和指令也很有帮助。 .
这是我的经验SIGBUS通常与未对齐的数据有关。在你进入兔子洞之前，尝试添加 -xmemalign=4i或 -xmemalign=8i至 CFLAGS和 CXXFLAGS .
我似乎记得 Sparc 有一条指令可以更有效地处理更宽的数据，但它对对齐非常敏感。如果你投 uint8_t*到 uint32_t*或 uint64_t* ，那么缓冲区真的需要对齐，因为默认情况下 SunCC 将生成更有效的移动。这就是 Andre 所说的严格的混叠违规。 Sun不像x86，它也会SIGBUS如果你作弊。
另见 B.2.111 -xmemalign=ab在 Sun 手册中。 Google "-xmemalign=4i"也有很多好评.问题是，在您遇到问题并深入了解之前，您不知道这就是您需要搜索的内容。
(我花了几个月的时间在自测中追查 Sparc 上的一次崩溃，这是由于脏 Actor 和更广泛的移动指令。-xmemalign=4i 为我修复了它)。
关于c++ - 调用堆栈显示 SIGBUS，这是什么意思，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45880782/