我们对HP-UX和我的代码是C ++。我们正在
BUS_ADRALN - 无效的地址对齐
在我们的函数调用可执行文件。这个错误是什么意思？同样的功能在工作多次后，突然给其核心转储。在GDB当我尝试打印它说不是在上下文中的对象的值。任何线索在哪里检查？
你有一个数据对齐问题。这可能是由试图读取或通过某种不好的指针写所致。
一种数据对准问题是，当一个指针所指向的地址不是“对齐”的正常。例如，一些结构（旧克雷2例如）要求任何尝试读取的任何其他比从存储器中的单个字符只能通过一个指针，在该指针的值的最后3位是0。如果任何最后的发生3位是1，硬件会产生对齐错误，这将导致你所看到的那样的问题。
大多数的架构几乎没有这么严格，并经常要求的对齐取决于被访问的确切类型。例如，一个32位整数，可能需要只有指针的最后2个比特为0，但在64位浮点可能需要的最后3个比特为0。
对准问题通常是由相同的种，将导致一个段错误或段故障问题造成的。通常未初始化的指针。但是它可以通过不与正确对齐返回指针，或通过指针的指针运算的结果不好的内存分配当它是类型不正确引起的。
该系统的实施malloc和/或operator new的几乎肯定是正确的或你的程序将崩溃方式，目前确实之前。所以我觉得不好的内存分配器是最有可能的树去吠叫。我会首先检查了未初始化的指针再不济指针运算。
作为一个侧面说明，在x86和x86_64体系结构没有任何对齐要求。但是，因为高速缓存行是如何工作的，以及其他各种原因，它往往对性能对齐边界为被存储的数据类型，这是大的数据是个好主意（即一个32位的int 4字节边界）。
大多数处理器（没有x86和朋友..家庭笑的害群之马）需要访问某些元素的字节数的倍数对齐。即如果你读地址0×04的整数是好的，但如果你尝试做从0×03，你同样会引起中断被抛出。
这是因为它更容易实现加载/存储硬件，如果它总是在与您合作的数据大小的倍数。
由于HP-UX只在RISC处理器，它通常有这样的限制运行，你应该看到在这里 - > http://en.wikipedia.org/wiki/Data_structure_alignment#RISC。
实际上HP-UX对ITRC自己的伟大的论坛和一些惠普的工作人员都非常有帮助。我只是拍了一下你问同一主题和here are some results。例如the similar problem是由错误的输入参数实际上造成的。我强烈建议您先阅读回答类似的问题，并在必要时有张贴您的问题。
顺便说一句，很可能你会被要求张贴的这些gdb命令的结果：
(gdb) bt
(gdb) info reg
(gdb) disas $pc-16*8 $pc+16*4
大多数的这些问题通过链接到不同版本的同一个库的多个上游的依赖造成的。
例如，无论是gnustl和STLport的提供C ++标准库的不同的实施方式。如果您编译和链接对gnustl，而你的一个依赖编译和对STLport的链接，那么你将各有不同的实现的标准函数和类。当你的程序启动时，动态连接器将尝试解决所有导出的符号，并会在不正确的偏移发现已知符号，导致BUS_ADRALN信号。