前几天交叉编译crtmpserver到arm9下。编译通过，但是运行的时候，总是提示Alignment trap，但是并不影响程序的运行。这依然很令人不爽，因为不知道是什么原因引起的，这就像一颗定时炸弹一样，一定要解决。
修改makefile，加入-ggdb，去掉编译优化，重新编译。编译完毕，在gdb下运行，依然提示Alignment
trap，并且gdb没有任何反应。按照设想，操作系统应该能捕获到这个错误，然后通过信号的方式传递给gdb，gdb再中断停下来。但是事实上并没有按
照我的设想运行，为什么呢？通过查找资料，发现cpu在处理内存对齐的时候，有几种方式可以设置。
cat /proc/cpu/alignment
User: 1
System: 0
Skipped: 0
Half: 0
Word: 1
DWord: 0
Multi: 0
User faults: 3 (fixup+warn)
我的嵌入式linux系统下的默认处理方式是第3级处理方式：修复+警告。
0 - ignore
1 - warn
2 - fixup
3 - fixup+warn
4 - signal
5 - signal+warn (需要这个)
于是修改为：echo 5 > /proc/cpu/alignment，这样就会给内核一个信号。再在gdb下面重新运行
./rtmpserver ./rtmpserver.lua，果然gdb捕获到该信息,然后bt,查看出现问题的代码：
cat /proc/cpu/alignment
User: 1
System: 0
Skipped: 0
Half: 0
Word: 1
DWord: 0
Multi: 0
User faults: 3 (fixup+warn)
我的嵌入式linux系统下的默认处理方式是第3级处理方式：修复+警告。
0 - ignore
1 - warn
2 - fixup
3 - fixup+warn
4 - signal
5 - signal+warn (需要这个)
于是修改为：echo 5 > /proc/cpu/alignment，这样就会给内核一个信号。再在gdb下面重新运行
./rtmpserver ./rtmpserver.lua，果然gdb捕获到该信息,然后bt,查看出现问题的代码：
_currentFPVersion = ntohl(*((uint32_t *) (GETIBPOINTER(buffer) + 4))); //----MARKED-LONG---
原来是在强制类型转换读取内存的时候出现了错误，于是修改为：
uint32_t uTemp = 0; memcpy(&uTemp,GETIBPOINTER(buffer) + 4,sizeof(uint32_t)); _currentFPVersion = ntohl(uTemp); 再重新编译，运行，果然烦人的Alignment trap消失了。这也提醒我们，平时在写代码的时候，在内存访问上，尽量使用memcmp,memcpy,memset等函数，
而不要为了方便，直接对指针内容进行访问。这样的代码在x86上可能没问题，但是运行到arm上，就可能会出问题。
关于为什么在arm上会出现Alignment trap，可以参考http://hi.baidu.com/simplejoy/blog/item/cf456c8b1549e617c8fc7ad6.html
