Re: [MiNT] libgem16: vs_color

["Helmut Karlowski" <helmut.karlowski@ish.de>]

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 ...

--
Helmut Karlowski