From mint-bounce@lists.fishpool.fi Mon Jan 18 08:03:45 2010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ErkRPMVEIiu8Kf+aqbZllubWx7n7cGC5IY3F165GZqE=; b=cFhv5lYs2i6t1k7kKWcfEvCGlVVFnxa+tJcY2fM+dUTQV38fdrE+sBoLBoEd0isxTT E0Z6KM8CFHDja0jGbKbL9PUCQyHKpqU+nOB9oWNVjsyZ7QeFbjzAsue+SzX6cSURbeOL MvGID6wSOvRZBUhQdMkvXdLZ8RzuTWhcIOUyA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=khjV36MeaYw4Awpu0I1YoDbxxv5m+HrORBDI/fB6v9h+AYlrxcCauWj984YDCML9cv PRwlLVoSUpaMeDW0ivxB7/ZZBN3JTPEweTS9+WZrMO1/niaHabRvLekj4sMmFHMSKaB0 kPiNE/N+oZjpzEosDuO4R29KPuAOLipdvnaSU= Message-ID: <4B543E5D.30600@atari.org> Date: Mon, 18 Jan 2010 11:56:29 +0100 From: Odd Skancke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; nb-NO; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b2pre Thunderbird/3.0 MIME-Version: 1.0 To: mint@lists.fishpool.fi Subject: Re: [MiNT] libgem16: vs_color References: <4B542D75.6080103@freesbee.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Approved-By: tjhukkan@fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: oskancke@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Does this happen with all VDI versions? (Nvdi, no VDI enhancers or just fvdi) Den 18.01.2010 11:29, skrev Helmut Karlowski: > Am 18.01.2010, 10:44 Uhr, schrieb Vincent Rivière > : > >> 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 ... >