| Re: [hatari-devel] Natfeats regression? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Natfeats regression?
- From: Christian Zietz <czietz@xxxxxxx>
- Date: Thu, 16 Jun 2022 10:57:22 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1655369844; bh=TLcHvsNSIK2xRkvbjRq81gBdmXomf+33FfY3d4CuD/4=; h=X-UI-Sender-Class:Date:To:References:From:Subject:In-Reply-To; b=lKi4lFvjLzY+GiWlaYJtzU077gJBV5bpSaSN9lGOaXfn+Sxiu06Hx4o8uMx2NVFsv nfC7hJg9kM2lgVRHuXE9tigESg5uKUrq9Th+PhTRN5VFGa9p9aGb7WscTW6GyT6fTm eaa/JV6qal32tj43aBxzYzYyNGV56LVA1jhfxfuk=
Matthias Arndt schrieb:
My problem is that it does not seem to be an Atari side crash as Hatari
itself locks up, SDL GUI is unresponsive and there is no jump to the
debugger on the console. I have to manually kill hatari from a
different shell.
Find attached a sample harddisk image that should demonstrate the
crash. It's my Harddisk menu btw.
Adding "--trace natfeats" to the Hatari command line shows that it ends
up stuck in an endless loop trying to do NF_STDERR:
[...]
NF_STDERR(0xb7f4a )
NF_STDERR(0xb7f4a )
NF_STDERR(0xb7f4a )
NF_STDERR(0xb7f4a )
NF_STDERR(0xb7f4a )
NF_STDERR(0xb7f4a )
NF_STDERR(0xb7f4a )
NF_STDERR(0xb7f4a )
[...]
Now, without the source code to your program, it's hard to tell what
you're doing there. *However*, I can reproduce similar behavior by
calling nf_print("") [1], i.e., invoking NF_STDERR with an empty string.
The stack trace is as follows:
hatari_win64_debug!nf_stderr+0x21 [\home\hatari\hatari-builder2\hatari\src\debug\natfeats.c @ 139]
hatari_win64_debug!NatFeat_Call+0x60 [\home\hatari\hatari-builder2\hatari\src\debug\natfeats.c @ 358]
hatari_win64_debug!OpCode_NatFeat_Call+0x2b [\home\hatari\hatari-builder2\hatari\src\cpu\hatari-glue.c @ 350]
hatari_win64_debug!m68k_run_1_ce+0x22e [\home\hatari\hatari-builder2\hatari\src\cpu\newcpu.c @ 5431]
hatari_win64_debug!m68k_go+0x266 [\home\hatari\hatari-builder2\hatari\src\cpu\newcpu.c @ 7628]
Here is what I think happens: The NF_STDERR handler [2] calls
mem_string_ok() [3]. This function returns 0 for an empty string, which
causes nf_stderr() to return false. This in turn causes the CPU *not* to
advance its PC, as it will only do a (fake) NOP when the natfeats call
is successful [4]. Thus, the natfeats instruction is repeated over and
over again.
(I have an older build of hatari as backup where Natfeats work so my work is not affected.)
But this statement of yours confuses me. According to "git blame" the
corresponding code has not changed in years. How old is your "older build"?
Regards
Christian
[1]
https://github.com/hatari/hatari/blob/e471a2d196cd6ba42aaf3b8d8a945513267137e3/tests/natfeats/natfeats.c#L80
[2]
https://github.com/hatari/hatari/blob/e471a2d196cd6ba42aaf3b8d8a945513267137e3/src/debug/natfeats.c#L133
[3]
https://github.com/hatari/hatari/blob/e471a2d196cd6ba42aaf3b8d8a945513267137e3/src/debug/natfeats.c#L45
[4]
https://github.com/hatari/hatari/blob/e471a2d196cd6ba42aaf3b8d8a945513267137e3/src/cpu/hatari-glue.c#L343
--
Christian Zietz - CHZ-Soft - czietz@xxxxxxx
WWW: https://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA