同样的代码，在vs下运行正常，在android ndk下却崩溃：
signal 7(SIGBUS),code 1 (BUS_ADRALN),fault addr 0xe6b82793
Func(short *pVY[])
{
short *dstY[2] = {pVY[0],pVY[1]};//使用backtrace定位,crash在这一句
}
pVY[0],pVY[1]是从一个统一分配的buffer偏移得来的。
1.考虑内存对齐的原因
pVY[0],pVY[1]:0xee25ffe0,0xee262470 。都是32字节对齐的。
重新分配按64字节对齐，pVY[0],pVY[1]:0xee260600,0xee262b00 ,实际已经256字节对齐了，错误同样出现.
不是pVY[0]和[1]内存没对齐的原因
it appears that SIGBUS 7 is a data misalignment issue, and SIGSEGV 11 is a write to inaccessible memory.
打印出pVY的值为0xe6b82793,正好与fault addr一样,pVY + 1的值为0xe6b82797.
参考：http://stackoverflow.com/questions/13077791/fatal-signal-7-sigbus-at-0x00000000-code-2
Linux操作系统会对于 非对齐内存访问的进程，发送SIGBUS的信号，你的程序，接收到这个信号后，进行coredump，并退出了。
Windows操作系统允许 非地址对齐的内存访问（会损失性能），所以程序在Windows操作系统下，不会出现error。
Win32平台下的微软VC编译器在默认情况下采用如下的对齐规则: 任何基本数据类型T的对齐模数就是T的大小，即sizeof(T)。比如对于double类型(8字节)，就要求该类型数据的地址总是8的倍数，而char类型数据(1字节)则可以从任何一个地址开始。Linux下的GCC奉行的是另外一套规则:任何2字节大小(包括单字节吗?)的数据类型(比如short)的对齐模数是2，而其它所有超过2字节的数据类型(比如long,double)都以4为对齐模数。
应该是对pVY,pVY+1的非对齐内存访问造成的,pVY(0xe6b82793)存的是(short*) pVY[0]。
pVY来自class的成员变量：
class A{
...
short *pVY[6];
};
在vs下调试，pVY 为0x001cd9a8,是8字节对齐的。
在ndk下， pVY+0到5为：0xe6b82793,797,79b,79f,7a3,7a7，默认并没有对齐。
解决办法：
1.不进行赋值，函数体内直接使用形参操作：
Func(short *dstY[])
{
for(x = 0;x<w;x++){
dstY[0][x] = x;
dstY[1][x] = x;
}
}
2.设置内存对齐
#pragma pack(push) //保存对齐状态
#pragma pack(8)//设定为4字节对齐
class A{
...
short *pVY[6];
};
#pragma pack(pop)
在ndk下pVY的值为0xe6b82794