KVS SDK Alignment trap debug

1.起因是在测试S1 upload clip遇到的问题.

经过排查，确认是KVS SDK 3.1.1的锅

2.这个问题的原因是发生非对齐地址访问

然后尝试了一下echo 2 >/proc/cpu/alignment （2：fixup）, 发现并不能解决问题

3.经过以上尝试不行，所以接下来就要想想如何定位错误。

代码出现字节对齐错误，有些代码量很小，很容易定位错误地方，但如果在大型项目中，就很难定位，尤其是在嵌入式中——嵌入式的调试也相对比较困难、麻烦。以我的经验，与其用gdb来调试，不如靠经验及printf大法解决问题来得更快，但是这次由于是kvs 的SDK（代码量有些大），不是我们自己的code，所以依靠printf不太现实。

因为这个log打印是由于系统发送signal(SIGBUS)产生的。
所以我们理所应当的可以利用这个signal做一些事情。

我们要在程序有问题的地方, 让它中断, 然后印出 backtrace 来让 addr2line 反查. 因此, 我们分成以下三个步骤说明之.（利用此方法，也可以用来捕捉 SIGSEGV (Segmentation Fault, 内存区段错误) 所发生的地方. 甚至是其他的 signal 发生时, 程序执行的位置.）

用 signal 让程序在有问题的地方中断
印出 backtrace
使用 addr2line 来解析其内容（addr2line -e 执行文件 -f 地址）

1.首先我们先将行为模式设为5
echo 5 > /proc/cpu/alignment
关于 User faults, 有以下 5 种设定,
0 - ignore (默认值)
1 – warn
2 - fixup
3 - fixup+warn
4 - signal
5 - signal+warn (我们需要这个)

2.印出 backtrace
这个部份, 需要利用 backtrace(). 如果 source code 分成很多 .c 或 .cpp 的话, 请找出main() 所在的那个档案来增加以下的 code,

/* 此为 signal handler */
static void catch_sig(int sig) {
void *trace[128];
int n = backtrace(trace, sizeof(trace) / sizeof(trace[0]));
backtrace_symbols_fd(trace, n, 1);
exit(0);
}
/* 此函式指定 SIGBUS 的 handler 为 catch_sig() */
static void set_signals(void) {
struct sigaction act;
sigemptyset(&act.sa_mask);
act.sa_flags = 0;
act.sa_handler = catch_sig;
sigaction(SIGBUS, &act, NULL);
}
/* 在你的 main() 的前头, 呼叫 set_signals() */
int main() {
set_signals();:
:
}

编译时, 务必增加 -g -rdynamic 选项.

重新编译及执行后, 若发生 Alignment trap, kernel 会送给这个 process 一个 SIGBUS 的 signal, 而我们在 set_signal() 里, 设定了收到 SIGBUS 时要执行 catch_sig(), 而在 catch_sig() 里, 我们利用backtrace() 来取得 stack frame 的地址之后, 用 backtrace_symbols_fd() 来印出比较看得懂的信息

3.本来想着从以上的log中判断出出错的位置，但是无奈什么多余的log都没有。
这个时候再猜测，会不会是kernel的log没打印全，所以我将kernel里面“quiet”去掉（NT9852X），结果还是不行。。难道是编译选项-s为了降低文件大小将一些符号删除，或是strip的锅？然后我又尝试去掉这两个地方，结果还是没有log产生。
所以addrline也没法用了

4.烦人，还是要GDB，

接着我去找nvt的SDK 里面的tool,看看GDB是否在里面，找到之后，解了半天的编译错误，终于得到了GDB，
执行./gdb sc_producer
然后输入"r",按回车
结果触发upload clip，接着打印出信息
我亲爱的bug终于定位到了。

5.DEBUG (尝试)，解决方案

接着找到出错的地方，尝试把结构体用4字节对齐的方式编译，然后问题果然没了

6.补充

理解SIGBUS产生的原因

硬件故障，不用说，程序员最常碰上的肯定不是这种情形。
Linux平台上执行malloc()，如果没有足够的RAM，Linux不是让malloc()失败返回，
而是向当前进程分发SIGBUS信号。
注: 对该点执怀疑态度，有机会可自行测试确认当前系统反应。
某些架构上访问数据时有对齐的要求，比如只能从4字节边界上读取一个4字节的
数据类型。IA-32架构没有硬性要求对齐，尽管未对齐的访问降低执行效率。另外
一些架构，比如SPARC、m68k，要求对齐访问，否则向当前进程分发SIGBUS信号。

SIGBUS与SIGSEGV信号一样，可以正常捕获。SIGBUS的缺省行为是终止当前进程并产
生core dump。
一般我们平时遇到SIGBUS时总是因为地址未对齐导致的，而SIGSEGV则是由于内存地址不合法造成的。

对于以上几点，我们作为coding debug的人员，理所应当的应该关注第三点
SIGBUS(Bus error)总线错误：
引起原因：意味着指针所对应的地址是有效地址，但总线不能正常使用该指针。几乎总是由于对未对齐的读或写引起的。它之所以称为总线错误是因为对未对齐的内存访问时，被阻塞的组件就是地址总线。

对齐（alignment）数据项只能存储在地址是数据项大小的整数倍的内存位置上，这样可以加速内存访问。如：访问一个8字节的double的数据时，地址只能是8的整数倍，所以存储一个double的地址只能是24，8008，但不能存储于地址1006因为它不能被8整除，只要保证这个原则，就可以保证一个原子项数据不会跨页或cache块的边界。这样也就加快了访问数据的时间。

SIGBUS和SIGSEGV也许是我们在平时遇到的次数最多的两个内存错误信号。内存问题一直是最令我们头疼的事情，弄清楚两个信号的发生缘由对我们很好的理解程序的运行是大有裨益的。

我们来看两段程序：

//testsigsegv.c
int main()
{char *pc = (char*)0x00001111;*pc = 17;
}//testsigbus.c
int main()
{int *pi = (int*)0x00001111;*pi = 17;
}

上面的代码那么的相似，我们也同样用gcc编译(加上-g选项，便于gdb调试；平台Solaris Sparc)，执行结果也都是dump core。但通过GDB对core进行观察，你会发现细微的不同。第一个例子出的core原因是：Program terminated with signal 11, Segmentation fault. 而第二个例子的core则提示：Program terminated with signal 10, Bus error. 两者有什么不同呢？这两段代码的共同点都是将一个非法地址赋值给指针变量，然后试图写数据到这个地址。

testsigsegv.c中，0x00001111这个地址值被赋给了char *pc；也就是告诉CPU通过这个地址我们要存取一个字节的值，对于一个字节长度的数据，无所谓对齐，所以该地址通过对齐校验；并被放到地址总线上了。而在testsigbus.c里，0x00001111这个地址值被赋给了int *pi；也就是告诉CPU通过这个地址我们要存取一个起码4个字节的值，那么对于长度4个字节的对象，其存放地址起码要被4整除才可以，而0x00001111这个值显然不能满足要求，也就不能通过内存对齐的校验。也就是说SIGBUS这个信号在地址被放到地址总线之后被检查出来的不符合对齐的错误；而SIGSEGV则是在地址已经放到地址总线上后，由后续流程中的某个设施检查出来的内存违法访问错误。
（因为一个地址位只能存一个字节，一个四字节的变量需要四个地址位，地址存储往往是连续的四个地址，首地址作为定义地址。于是能被四整除方便后续的数据处理。）

7.在代码编写中，需要注意一下以下的事：

1、结构体尽量使用4字节对齐，比如设置一个传输长度len的类型时，用short表示的范围已经足够，当然也可以用int。像制定一些网络协议，最好考虑一下4字节对齐。
2、分配内存时也尽量4字节对齐，无论是申请的内存还是定义数组大小。
3、对指针进行访问的时候也要十分注意4字节对齐，特别是一些为了避免编译警告的强制类型转换。