Segmentation fault on arm but not on Linux pc

Hi, I have been able to run Michel Xhaard's spcaview (spcaClient) on VMware Linux pc but when I ran it on friendlyarm9 I get a segmentation fault. I changed the memory on the Vmware to the memory but it still run well. After reading about segmentation fault error, I suspect the only function in spcaClient that access memory. The function is below:

void resize (unsigned char *dst,unsigned char *src, int Wd,int Hd,int Ws,int Hs)

{ int rx,ry; int xscale,yscale; int x,y; Myrgb24 pixel; Myrgb24 *output =(Myrgb24*) dst ; Myrgb24 *input = (Myrgb24*) src ; xscale = (Ws 16; ry = y*yscale >> 16; memcpy(output++,&input[ADDRESSE((int)rx,(int)ry,Ws)],sizeof(Myrgb24)); } } }

I will be grateful for any helpful leads. Currently am using gdb to debug and making changes to the function to see if I get rid of the error.

Thanks.

--------------------------------------- Posted through

formatting link

Reply to
najafa
Loading thread data ...

er

x,(int)ry,Ws)],sizeof(Myrgb24));

Just keep in mind the problem may occur in that routine, but the real source may be elsewhere. It might show up in this routine if a pointer is trashed by some higher level routine and then passed into this routine. You should get some clues from the call stack in gdb.

HTH, ed

Reply to
Ed Prochak

Maybe the stack size on the ARM system is smaller. Check if there are functions in which something large like a buffer is declared. This might overwrite other stuff when it is larger than the stack and this can cause segmentation faults. If this is so, try if making it static helps.

Good luck! Greetings, Rene

Reply to
Rene

Am 22.10.2010 05:52, schrieb najafa:

You may run into problems with misaligned memory accesses. Many RISC processors require 32bit accesses at multiples of four and 16bit acesses at multiples of two. If the memory adresses do not satisfy these requirements the processor has to split the memory access into two accesses. The Intel x86 does this, many RISC architectures (including ARM9) don't and throw exceptions instead.

--
Mit freundlichen Grüßen

Frank-Christian Krügel
Reply to
Frank-Christian Krügel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.