In complement :
I've started from a Falcon with prefetch emulation, cycle exact, MMU,
24-bits and accurate FPU (all ON).
Then, I've removed accurate FPU and rebooted. OK
Then, I've removed MMU emulation an rebooted, OK
Then, I've removed Cycle exact and rebooted, OK
Then, I've removed Prefetch and rebooted, OK
Then, I've switched to ST and again, core dump.
It seems that the problem is not related to MMU (it was disabled in my
test), but switching from Falcon to ST.
I've done another test, switching from Falcon to STe, and again, I've
got the core dump.
I've done another test, switching from the Falcon to a TT (tos 3.06fr)
and no problem (no core dump).
The main differences for the last test (in regard to switching to ST
or STE) :
- I changed the system to TT (I change it to ST or STE when I
switch to Atari ST or STe)
- I remove the DSP in all cases
- I kept the 68030 (from 16 to 32 Mhz). When I swith to ST, I
change to 68000 (8 Mhz)
- I kept the FPU (68882). I remove it when I swith to ST or STe
- I kept Prefetch emulation and Cycle exact (I also keep them when
switching to ST or STe)
- I removed MMU ( I always remove it when I swith)
- I always keep the 24 bits addressing mode
- I removed the accurate FPU emulation
- I changed the TOS to 3.06fr
- I kept the memory to 14 Mo (I use 1 Mo when I switch to ST or STe)
Regards
Le 05/11/2023 à 16:48, Laurent Sallafranque a écrit :
Hello,
I've compiled hatari in debug mode.
I've erased my hatari.cfg file.
I've configured a falcon and saved the config (file is attached to
this mail).
When I use hatari GUI to select an atari ST, 1 Mo, no DSP, TOS
1.04fr, hatari segfault.
Here is what I get :
(gdb) run
Starting program: /home/laurent/Atari/hatari/build/src/hatari
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
INFO : Hatari v2.5.0-devel (Nov 5 2023), compiled on: Nov 5 2023,
16:41:15
[New Thread 0x7ffff5f1f640 (LWP 24540)]
[New Thread 0x7fffe2c59640 (LWP 24541)]
INFO : GEMDOS HDD emulation, C: <->
/media/Toshiba/Data_Laurent/Jeux/Atari/DiskDur.FAL.
[New Thread 0x7fffe1449640 (LWP 24542)]
Thread 1 "hatari" received signal SIGSEGV, Segmentation fault.
__GI__IO_fputs (str=str@entry=0x55555695e030 <MsgState+16> '\201'
<repeats 200 times>..., fp=fp@entry=0x8181818181818181) at
./libio/iofputs.c:36
36 ./libio/iofputs.c: Aucun fichier ou dossier de ce type.
(gdb)
(gdb) bt
#0 __GI__IO_fputs (str=str@entry=0x55555695e030 <MsgState+16> '\201'
<repeats 200 times>..., fp=fp@entry=0x8181818181818181) at
./libio/iofputs.c:36
#1 0x00005555560847cf in printPendingMsgRepeat
(fp=fp@entry=0x8181818181818181) at
/home/laurent/Atari/hatari/src/debug/log.c:287
#2 0x0000555556084ac4 in addMsgRepeat (fp=0x8181818181818181,
line=line@entry=0x7ffffffbb510 "DEBUG: Loaded TOS version 1.04,
starting at $fc0000, country code = 2, PAL\n")
at /home/laurent/Atari/hatari/src/debug/log.c:313
#3 0x0000555556084e63 in Log_Printf (nType=nType@entry=LOG_DEBUG,
psFormat=psFormat@entry=0x5555560b0530 "Loaded TOS version
%i.%c%c, starting at $%x, country code = %i, %s\n") at
/home/laurent/Atari/hatari/src/debug/log.c:412
#4 0x000055555574ad9a in TOS_InitImage () at
/home/laurent/Atari/hatari/src/tos.c:1148
#5 0x000055555573c4b6 in Reset_ST (bCold=bCold@entry=true) at
/home/laurent/Atari/hatari/src/reset.c:61
#6 0x000055555573c63a in Reset_Cold () at
/home/laurent/Atari/hatari/src/reset.c:139
#7 0x000055555570d8dc in Change_CopyChangedParamsToConfiguration
(current=current@entry=0x7ffffffbb7d0, changed=<optimized out>,
bForceReset=<optimized out>)
at /home/laurent/Atari/hatari/src/change.c:504
#8 0x000055555570fa81 in Dialog_DoProperty () at
/home/laurent/Atari/hatari/src/dialog.c:70
#9 0x0000555555745e20 in ShortCut_ActKey () at
/home/laurent/Atari/hatari/src/shortcut.c:297
#10 0x0000555555751b41 in Video_InterruptHandler_VBL () at
/home/laurent/Atari/hatari/src/video.c:4630
#11 0x000055555570f716 in CycInt_CallActiveHandler (Clock=<optimized
out>) at /home/laurent/Atari/hatari/src/cycInt.c:548
#12 0x000055555578b2ab in CycInt_Process_stop (stop_cond=0) at
/home/laurent/Atari/hatari/src/includes/cycInt.h:92
#13 m68k_run_2ce () at /home/laurent/Atari/hatari/src/cpu/newcpu.c:7013
#14 0x000055555578c2ca in m68k_go (may_quit=may_quit@entry=1) at
/home/laurent/Atari/hatari/src/cpu/newcpu.c:7798
#15 0x0000555555730501 in M68000_Start () at
/home/laurent/Atari/hatari/src/m68000.c:307
#16 0x0000555555731e90 in main (argc=<optimized out>, argv=<optimized
out>) at /home/laurent/Atari/hatari/src/main.c:983
(gdb)
If you need more debug infos, just tell me what you need.
Regards
Laurent
Le 05/11/2023 à 13:53, Laurent Sallafranque a écrit :
Hi all,
I've just tested the path and I still have a core dump when I switch
from Falcon to ST.
I'll give you mode context soon.
Regards
Le 04/11/2023 à 23:08, Nicolas Pomarède a écrit :
Le 23/09/2023 à 22:32, Nicolas Pomarède a écrit :
Le 23/09/2023 à 19:30, Eero Tamminen a écrit :
Hi Nicolas,
This is not logging issue, but Hatari memory setup one.
Over ~143 KB area of Hatari process memory, including its global
variables, was overwritten with value 0x81, and preceding memory
area with value 0x48.
Among those global variables, is FILE pointer to Hatari log
file. Both in my and Laurent's case, Hatari segfaulted when
fputs() tried to use the pointer that had been changed to invalid
0x8181818181818181 address. It's a bit miracle Hatari got that
far...
ASAN reports memory setup to be the culprit:
------------------------------------------
==10734==ERROR: AddressSanitizer: global-buffer-overflow on
address 0x5625d1dd6e20 at pc 0x5625ce3f0b68 bp 0x7ffc142ee490 sp
0x7ffc142ee488
WRITE of size 1 at 0x5625d1dd6e20 thread T0
#0 0x5625ce3f0b67 in map_banks2 src/cpu/memory.c:1959
#1 0x5625ce3f0b67 in map_banks_ce src/cpu/memory.c:1988
#2 0x5625ce3f0b67 in memory_map_Standard_RAM
src/cpu/memory.c:1614
#3 0x5625ce3f0f79 in memory_init src/cpu/memory.c:1748
#4 0x5625ce2e9d4c in TOS_InitImage src/tos.c:1132
#5 0x5625ce2c10f1 in Reset_ST src/reset.c:61
#6 0x5625ce23050b in Change_CopyChangedParamsToConfiguration
src/change.c:504
#7 0x5625ce236b17 in Dialog_DoProperty src/dialog.c:70
#8 0x5625ce2de904 in ShortCut_ActKey src/shortcut.c:297
0x5625d1dd6e20 is located 32 bytes to the left of global variable
'TTmem_mask' defined in 'src/cpu/memory.c:41:16' (0x5625d1dd6e40)
of size 4
0x5625d1dd6e20 is located 0 bytes to the right of global variable
'ce_banktype' defined in 'src/cpu/memory.c:114:8'
(0x5625d1dc6e20) of size 65536
------------------------------------------
I could not reproduce this by switching from TT emulation to ST
one, or with EmuTOS, only with real TOS.
Smallest run-time change triggering the issue following...
1. Start Hatari with Falcon TOS and >4MB RAM:
hatari --machine falcon --tos tos404.img -s 8
2. Switch to 1.x / 2.x TOS + 4MB or less RAM in Hatari setup dialog
3. OK changes, so that emulation gets rebooted
Hi
thanks for the trace, will have a look later.
From the corresponding source code, it might be possible that
MMU_Bank0_Size comes with a too big value in that case, not
compatible with STF memory, thus overriding some memory regions.
Hi
took more time to fix due to not many spare time recently.
Anyway, it should now be OK. The problem was that in Falcon mode
MMU_Bank0_Size is not used and is set to 0 at some point.
But after changing tos to 1.x/2.x, this value of 0 was kept, which
caused a problem in memory_init() and memory_map_Standard_RAM() :
map_banks_ce(&STmem_bank_MMU, 0x10000 >> 16, ( MMU_Bank0_Size -
0x10000 ) >> 16, [...]
Ooops, MMU_Bank0_Size==0 would mean map_banks_ce will in fact use
a huge/wrong value (-0x10000 as unsigned) instead of the correct
bank's size.
I added a call to Memory_Reset(true) when a change to TOS version
implies a change to the machine's type.
But I think tos.c has too much specific cases trying to "fix"
machine/hardware to match the tos version. Instead of doing some
UnInit/Init for various components it would be safer to call
Change_DoNeedReset() (as when changing parameters from the UI) and
then call Reset_ST(true) to force a cold reset to be sure
everything start with sane default values.
Nicolas