Re: [hatari-devel] TT emulation crashes when there is no ACSI drive |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] TT emulation crashes when there is no ACSI drive
- From: Uwe Seimet <Uwe.Seimet@xxxxxxxxx>
- Date: Sun, 11 Aug 2019 08:02:30 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1565503350; s=strato-dkim-0002; d=seimet.de; h=In-Reply-To:References:Message-ID:Subject:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=01tXurN19Dl9b1TRdaEINjNqeDGmCeXwoR+puOgPiuI=; b=qjmf442QfJFCqCNdWK0bjpsYJYPvKuk1n/lIz3vYNrh/7JKjldz2vq9yJNctHbczLy 9T5auxgUrlrpLfxTXR0sJcnm1K782gkjoRP+M3I8IUV+i3qfCbgf6IoJa2kBI5p5pFTE b0A1Btk6uuOLTiT2HJnETdkMozFYzYP4VPddq++cRC6GNZkl4j/hiwPRxDz5+b7OQ/NH ID6gfDcR+q5b96lbd065f/O7b15BYSFZzg58ZcVMhagvZr13i/v/8Le6UvcmQKQJqvAR /ELOCWx59nCPhDgZbSjUV8ThEflR/ecsfldD1osFZKygNsNOLQxK1rQaZGTE9MSJsi9/ E2fw==
Hi,
Disabling IDE disks does not make a difference.
This is the offending commit:
* 50bf142e - Merge new TT MFP code (3 months ago) <Nicolas Pomarede>
Commit ID 65dda3cf and older work fine for me, since 50bf142e there is
the crash. My compiler is gcc 8.3.0, by the way.
Best regards
Uwe
> Am Tue, 6 Aug 2019 01:18:04 +0300
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> ...
> > It seems like either a6 got overwritten load_n_reloc, or it
> > somehow cause stack area pointed by a6 to be overwritten. Or
> > TOS gives "bad" data for Pexec() during AUTO/ in your case,
> > when TT-RAM is present (which I can't reproduce).
> >
> > => Uwe, are there any other programs in AUTO folder? If yes,
> > do you get the issue also if only NF_SCSI.PRG is in AUTO?
> >
> > Thomas, any comments?
>
> I cannot reproduce the crash here, using Uwe's config file from his
> earlier mail.
>
> Uwe, could you maybe also disable the IDE disks in your config, to see
> whether it makes a difference? Also, please try to compile Hatari with
> a different compiler (e.g. clang instead of gcc), to make sure that
> we're not hunting a bogus compiler bug here.
>
> If that all does not make a difference, please try to bisect the
> problem (with "git bisect ...") to see where it started.
>
> Thomas
>
>