“BUS_ADRALN - 无效地址对齐”是什么意思错误意味着?

发布于 2024-09-09 23:06:11 字数 206 浏览 9 评论 0原文

我们使用的是 HPUX,我的代码是 C++ 的。 我们正在得到

BUS_ADRALN - 无效地址对齐

BUS_ADRALN -函数调用时可执行文件中的 。这个错误是什么意思? 相同的功能运行了很多次,然后突然出现核心转储。 在 GDB 中,当我尝试打印对象值时,它说不在上下文中。 有线索可以去哪里检查吗?

We are on HPUX and my code is in C++.
We are getting

BUS_ADRALN - Invalid address alignment

in our executable on a function call. What does this error means?
Same function is working many times then suddenly its giving core dump.
in GDB when I try to print the object values it says not in context.
Any clue where to check?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

眼泪都笑了 2024-09-16 23:06:11

您遇到数据对齐问题。这可能是由于尝试通过某种错误的指针进行读取或写入而引起的。

数据对齐问题是指指针指向的地址未正确“对齐”。例如,某些体系结构(例如旧的 Cray 2)要求从内存中读取除单个字符以外的任何内容的任何尝试只能通过指针进行,其中指针值的最后 3 位为 0。 3 位为 1,硬件将生成对齐错误,这将导致您所看到的问题。

大多数架构并没有那么严格,并且所需的对齐通常取决于所访问的确切类型。例如,32 位整数可能只要求指针的最后 2 位为 0,但 64 位浮点数可能要求最后 3 位为 0。

对齐问题通常是由导致对齐问题的同类问题引起的。 SEGFAULT 或分段错误。通常是未初始化的指针。但这可能是由于错误的内存分配器未返回正确对齐的指针引起的,或者是由于指针类型不正确时对指针进行指针算术的结果引起的。

malloc 和/或 operator new 的系统实现几乎肯定是正确的,否则您的程序将比当前崩溃得多。所以我认为糟糕的内存分配器是最不可能吠叫的树。我会首先检查未初始化的指针,然后检查错误的指针算术。

附带说明一下,x86 和 x86_64 架构没有任何对齐要求。但是,由于缓存行的工作方式以及各种其他原因,为了提高性能,将数据对齐到与所存储的数据类型一样大的边界(即 32 位 int 的 4 字节边界)通常是一个好主意。

You are having a data alignment problem. This is likely caused by trying to read or write through a bad pointer of some kind.

A data alignment problem is when the address a pointer is pointing at isn't 'aligned' properly. For example, some architectures (the old Cray 2 for example) require that any attempt to read anything other than a single character from memory only occur through a pointer in which the last 3 bits of the pointer's value are 0. If any of the last 3 bits are 1, the hardware will generate an alignment fault which will result in the kind of problem you're seeing.

Most architectures are not nearly so strict, and frequently the required alignment depends on the exact type being accessed. For example, a 32 bit integer might require only the last 2 bits of the pointer to be 0, but a 64 bit float might require the last 3 bits to be 0.

Alignment problems are usually caused by the same kinds of problems that would cause a SEGFAULT or segmentation fault. Usually a pointer that isn't initialized. But it could be caused by a bad memory allocator that isn't returning pointers with the proper alignment, or by the result of pointer arithmetic on the pointer when it isn't of the correct type.

The system implementation of malloc and/or operator new are almost certainly correct or your program would be crashing way before it currently does. So I think the bad memory allocator is the least likely tree to go barking up. I would check first for an uninitialized pointer and then bad pointer arithmetic.

As a side note, the x86 and x86_64 architectures don't have any alignment requirements. But, because of how cache lines work, and for various other reasons, it's often a good idea for performance to align your data on a boundary that's as big as the datatype being stored (i.e. a 4 byte boundary for a 32 bit int).

美人迟暮 2024-09-16 23:06:11

大多数处理器(不是 x86 和它的朋友......家族中的黑羊哈哈)要求访问某些元素以按多个字节对齐。也就是说,如果您从地址 0x04 读取一个整数,那没问题,但如果您尝试从 0x03 读取一个整数,则会导致抛出中断。

这是因为如果加载/存储硬件始终是您正在使用的数据大小的倍数,则更容易实现加载/存储硬件。

由于 HP-UX 仅在 RISC 处理器上运行,而 RISC 处理器通常具有此类限制,因此您应该在此处看到 -> http://en.wikipedia.org/wiki/Data_struct_alignment#RISC

Most processors (not x86 and friends.. the blacksheep of the family lol) require accesses to certain elements to be aligned on multiples of bytes. I.e. if you read an integer from address 0x04 that is okay, but if you try to do the same from 0x03 you will cause an interrupt to be thrown.

This is because it's easier to implement the load/store hardware if it's always on a multiple of the data size with which you're working.

Since HP-UX runs only on RISC processors, which typically have such constraints, you should see here -> http://en.wikipedia.org/wiki/Data_structure_alignment#RISC.

长发绾君心 2024-09-16 23:06:11

实际上,HP-UX 在 ITRC 上有自己的大型论坛,并且一些 HP 员工非常乐于助人。我刚刚查看了您所询问的同一主题,并且 这里是一些结果。例如,类似的问题实际上是由输入参数错误。我强烈建议您首先阅读类似问题的答案,如有必要,请在那里发布您的问题。

顺便说一句,您可能会被要求发布这些 gdb 命令的结果:

(gdb) bt
(gdb) info reg
(gdb) disas $pc-16*8 $pc+16*4

Actually HP-UX has its own great forum on ITRC and some HP staff members are very helpful. I just took a look at the same topic you are asking and here are some results. For example the similar problem was caused actually by a bad input parameter. I strongly advise you first to read answers to similar question and if necessary to post your question there.

By the way it is likely that you will be asked to post results of these gdb commands:

(gdb) bt
(gdb) info reg
(gdb) disas $pc-16*8 $pc+16*4
还给你自由 2024-09-16 23:06:11

这些问题大多数是由链接到同一库的不同版本的多个上游依赖项引起的。

例如,gnustl 和 stlport 都提供了 C++ 标准库的不同实现。如果您针对 gnustl 进行编译和链接,而您的依赖项之一针对 stlport 进行编译和链接,那么您将各自拥有标准函数和类的不同实现。当您的程序启动时,动态链接器将尝试解析所有导出的符号,并会发现偏移量不正确的已知符号,从而产生 BUS_ADRALN 信号。

Most of these issues are caused by multiple upstream dependencies linking to different versions of the same library.

For example, both the gnustl and stlport provide distinct implementations of the C++ standard library. If you compile and link against gnustl, while one of your dependencies was compiled and linked against stlport, then you will each have a different implementation of standard functions and classes. When your program is launched, the dynamic linker will attempt to resolve all of the exported symbols, and will discover known symbols at incorrect offsets, resulting in the BUS_ADRALN signal.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文