Am 18.01.2010, 10:44 Uhr, schrieb Vincent Rivière
<vincent.riviere@freesbee.fr>:
But it is strange, the bug appears before the trap.
There is only standard C here, and nothing can be inlined...
Yeah - really strange: everything is on the stack, and should be
separated from each other.
I think the explication will become obvious by looking at the
generated assembler code.
This is without the static:
vs_color.o: file format a.out-mint
Disassembly of section .text:
00000000 <_vs_color>:
0: 4fef ffc0 lea %sp@(-64),%sp
4: 2f02 movel %d2,%sp@-
6: 342f 0048 movew %sp@(72),%d2
a: 302f 004a movew %sp@(74),%d0
e: 206f 004c moveal %sp@(76),%a0
12: 42af 0022 clrl %sp@(34)
16: 42af 0026 clrl %sp@(38)
1a: 42af 002a clrl %sp@(42)
1e: 42af 002e clrl %sp@(46)
22: 42af 0032 clrl %sp@(50)
26: 42af 0036 clrl %sp@(54)
2a: 42af 003a clrl %sp@(58)
2e: 426f 003e clrw %sp@(62)
32: 42af 0006 clrl %sp@(6)
36: 42af 000a clrl %sp@(10)
3a: 43ef 0022 lea %sp@(34),%a1
3e: 2f49 000e movel %a1,%sp@(14)
42: 43ef 0006 lea %sp@(6),%a1
46: 2f49 0012 movel %a1,%sp@(18)
4a: 42af 0016 clrl %sp@(22)
4e: 2f7c 0000 0000 movel #0,%sp@(26)
54: 001a
56: 2f7c 0000 0000 movel #0,%sp@(30)
5c: 001e
5e: 3f40 0006 movew %d0,%sp@(6)
62: 3f58 0008 movew %a0@+,%sp@(8)
66: 3f58 000a movew %a0@+,%sp@(10)
6a: 3f50 000c movew %a0@,%sp@(12)
6e: 43ef 000e lea %sp@(14),%a1
72: 2049 moveal %a1,%a0
74: 2208 movel %a0,%d1
76: 2050 moveal %a0@,%a0
78: 20fc 000e 0000 movel #917504,%a0@+
7e: 20fc 0000 0004 movel #4,%a0@+
84: 20fc 0000 0000 movel #0,%a0@+
8a: 3082 movew %d2,%a0@
8c: 303c 0073 movew #115,%d0
90: 4e42 trap #2
92: 241f movel %sp@+,%d2
94: 4fef 0040 lea %sp@(64),%sp
98: 4e75 rts
The bug appears at 62. I'm not very good at assembler though.
When I change the C-code to vdi_intin[1] = rgb[0], instead of *ptr++ =
..., the pointer vdi_params.control is even, but something else gets
corrupted, which again leads to an odd pointer arriving at fvdi for the
rgb-array.
Or would it be possible there is a stack overflow ?
Even if the stack overflows, it should show up somewhere else (the
caller), except another thread mixes it up, but then it would not always
be the same, I assume.
Or something (interruption, etc...) that overwrites the stack variables?
That's the last possibility. I will write a test-prog later this week to
see if it reproduces. If so, it should be possible to find it with gdb.
If not: not good ...