I'm developing on Mac OS using c++. Compiled with gcc.
For performance thinking, we embedded some assembly codes.
But Last Friday, I encounter a very strange and very trick bug.
That's look into the gdb debugging screen first:
Look at this information cut from gdb.
Call 0x1a3a8
That should change the eip to 0x1a3a8 and jmp to this address, but for unknown reason, it jump to 0x1a4c9.
If we look into the source, the Call 0x1a3a8 instruction if from line 3340:
In function RMCT_R97_FLOAT_ASM_ATT_24BITS_RGB
:
:
http://lh3.ggpht.com/_nFmozv0srkM/TGCXaGuqiRI/AAAAAAAAAo0/gK6wiOqhfqo/err_4.JPG
I got this bug. I try many many ways to find out what happened in the kernel, I try disable the functions line by line.
If we disable line 2913 2919 in the above source, this error disappeared.
But how come these lines will cause this bug?
I even track into the assembly codes .
Looks like its caused by the stack error, the esp point to an invalid address.
But each call should only change the esp by -4
Look on the above information, before call, the esp is 0xb0080980
After one call, the esp should be 0xb008097c. Here instead, esp changed to 0x300908ec
Anybody know where this bug might come from?
For performance thinking, we embedded some assembly codes.
But Last Friday, I encounter a very strange and very trick bug.
That's look into the gdb debugging screen first:
Look at this information cut from gdb.
Call 0x1a3a8
That should change the eip to 0x1a3a8 and jmp to this address, but for unknown reason, it jump to 0x1a4c9.
If we look into the source, the Call 0x1a3a8 instruction if from line 3340:
In function RMCT_R97_FLOAT_ASM_ATT_24BITS_RGB
:
:
http://lh3.ggpht.com/_nFmozv0srkM/TGCXaGuqiRI/AAAAAAAAAo0/gK6wiOqhfqo/err_4.JPG
I got this bug. I try many many ways to find out what happened in the kernel, I try disable the functions line by line.
If we disable line 2913 2919 in the above source, this error disappeared.
But how come these lines will cause this bug?
I even track into the assembly codes .
Looks like its caused by the stack error, the esp point to an invalid address.
But each call should only change the esp by -4
Look on the above information, before call, the esp is 0xb0080980
After one call, the esp should be 0xb008097c. Here instead, esp changed to 0x300908ec
Anybody know where this bug might come from?