Re: [MiNT] XaAES regression in launch()

[Vincent Rivière <vincent.riviere@freesbee.fr>]

On 21/11/2012 00:20, Helmut Karlowski wrote:
> Is teradesk run by xaaes.cnf (shell=)?

Yes.
But I use GEM=ROM, then I double-click xaloader.prg from the desktop.
I always do that, I think that should not matter.

> First I would write a DBG at the beginning and return of draw_nesticon to
> verify it is really not called directly.

I mistaken, it does not crash there.
Actually it crashes in the kernel, in sys/proc.c.
It seems to crash in sleep(), or more precisely in swap_in_curproc():

	save = m->save;
	for (shdw = m->shadow; shdw->save; shdw = shdw->shadow)
		assert (shdw != m);

Somewhere inside this, it crashes when accessing shdw->save because shdw is 
actually 'XBRA', which is totally bogus.

> Do you say that the wrong RTE succeeds 2 times before it crashes?

No, I put an breakpoint on the crash location above, then swap_in_curproc() 
succeds 2 times before it crashes.

By looking at that swap_in_curproc() code, it is related to that MEMREGION 
stuff, it this looks consistent with the other bug I experienced yesterday 
(kfree() complaining).

> It's not necessarily caused by teradesk, disable everything (enable
> memory-protection ;-))

I could disable TosWin2, which is not used in this scenarion.
About memory protection, it is still not supported on ColdFire.

> What is around that XBRA-pointer?

It is not a pointer, I just see the 'XBRA' value inside a0, then it is 
accessed with 16(a0). This is what causes the Bus Error.

> Maybe it's a simple stack-overflow.

Maybe.

> What about the kfree from your previous finding?

Some days kfree() complains, some other days I get a Bus Error instead. 
There is something random.
Today is Bus Error day, kfree() does not complain.

> > And once again this leads us to ARGV stuff, which seems to be tightly
> > related to that make_argv() function in XaAES...
>
> I guess you're close ;-)

I've been fooled again >:o
That "=VGRA" presence just indicates that the program crashes on the 
TeraDesk user stack, no more.

> but also sr which has the bogus value of 0x0000.

Fooled again, it seems that FreeMiNT starts users process with sr = 0x0000, 
so there is nothing wrong (to be verified). I suspect the FireBee to have no 
HBL, in that case sr may never change to 0x0300 (also to be verified).


So, next plans.
I have no idea about what that swap_in_curproc() is about. I will put debug 
traces there, to try to see what is going wrong, and where that damn XBRA 
could come from.

A memory overwrite somewhere (or stack overflow) is still the most probable 
cause of this trouble.

--
Vincent Rivière