Re: [MiNT] Fwd: Re: marathon,was:Egale

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

Jo Even Skarstein wrote:

> On Mon, 20 Feb 2012 09:05:59 +0100, Helmut Karlowski
> <helmut.karlowski@ish.de> wrote:
>
> >> > It's not only for marathon but to improve the general stability.
> >>
> >> I don't think these two statements are compatible ;) If this hack
> >> causes a
> >
> > It would kill the system immediately else.
>
> Why? You are already catching it, but instead of allowing the application
> to continue you could kill it immediately.

It would also run if it's ok for the user.

> > The instability does not nessecarily come from the slb - there are
> > probably many other issues in marathon.
>
> Ok, so the cause of the inevitable crash is not determined? That changes
> it. I thought the appl_init() from slb_init() was found to be the cause.

The "fixed" version where the slb uses the apid of the caller crashes with
memory-violation. When I start it again system hangs always. I've not
been able to protect MiNT against this. I have a feeling the damage is
already done when aranym reports the memory-violation and MiNT kills it.

When I kill it on slb-load the system crashes after some restarts of the app, or shutdown, no
matter if there is a dialog or not.

I think I'll stop searching. It might also be fVDI-related - the display
looks not correct in some windows. Another issue might be the fact that
the slb and the slb-caller are killed during slb-initialization, which might confuse MiNT.

> >> supposed to call the AES from slb_init anyway, so in this particular
> >> case
> >> it's a matter of fixing the SLB.

Of course the app should be fixed, but MiNT/XaAES should not get
corrupted by any app, in theory.

> > Let the user decide ;-)
>
> The user will never know because the bug is silently accepted. So when
> (if) the system crashes due to this the user won't know why.

He is warned!

-Helmut