| Re: [hatari-devel] Resetting the machine crashes Hatari |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 07/13/2017 10:07 PM, Uwe Seimet wrote:
Please see the attachments. The logfile contains everything from starting
Hatari, waiting for Thing to be started, then resetting and waiting
until the desktop (not Thing this time, because it is not started after
a reset) to appear.
Thanks!
On boot:
----------------------------------------------------
Mounting hard drive image '/home/us/hatari/aranym.img'
Mounting IDE hard drive image /home/us/hatari/master.img
Mounting IDE hard drive image /home/us/hatari/slave.img
GEMDOS HDD emulation, C: <-> /home/us/TT/C.
WARNING: GEMDOS HD drive C: (may) override ACSI/IDE image partitions!
GEMDOS HDD emulation, D: <-> /home/us/TT/D.
WARNING: GEMDOS HD drive D: (may) override ACSI/IDE image partitions!
GEMDOS HDD emulation, E: <-> /home/us/TT/E.
GEMDOS HDD emulation, F: <-> /home/us/TT/F.
GEMDOS HDD emulation, G: <-> /home/us/TT/G.
GEMDOS HDD emulation, H: <-> /home/us/TT/H.
GEMDOS HDD emulation, I: <-> /home/us/TT/I.
memory_map_Standard_RAM 14680064 2097152 0
WARNING: too large VDI mode for TOS v3 memory detection to work correctly!
VDI mode memtop: 0xdd2600, phystop: 0xdf7e00 (screensize: 182 kB,
memtop->phystop: 150 kB)
Resulting INF file TOS resolution: 0x03 -> 0x03.
GEMDOS: NEWDESK.INF -> host: /home/us/TT/C/NEWDESK.INF
Going to modify '/home/us/TT/C/NEWDESK.INF'.
Virtual 'NEWDESK.INF' TOS resolution override file created.
----------------------------------------------------
On reset:
----------------------------------------------------
....
WARNING: too large VDI mode for TOS v3 memory detection to work correctly!
VDI mode memtop: 0xdd2600, phystop: 0xdf7e00 (screensize: 182 kB,
memtop->phystop: 150 kB)
Resulting INF file TOS resolution: 0x03 -> 0x03.
GEMDOS didn't find filename /home/us/TT/C/THING/NEWDESK.INF
Using builtin 'NEWDESK.INF'.
Virtual 'NEWDESK.INF' TOS resolution override file created.
----------------------------------------------------
I.e. on reset GEMDOS HD emulation doesn't anymore find your
NEWDESK.INF file and therefore autoboot / VDI resolution
code overrides it with a *builtin* NEWDESK.INF file.
Do you still see this issue if you disable all ACSI &
IDE drives and just use GEMDOS HD emulation?
- Eero
Take care
Uwe
Hi,
On 07/13/2017 08:58 AM, Uwe Seimet wrote:
This fixes the problem with the crash after the reset, but now after
resetting Hatari the desktop info file is not read properly anymore. I have
installed Thing as my desktop application, but Thing is not executed after
a reset. I have to reset Hatari twice in order to get Thing started. In
general, only every second reset works.
I wasn't able to reproduce the original issue, and I'm not able
to reproduce this (when starting something else than Thing).
Could you provide:
* the *.INF files in your GEMDOS HD
* Hatari output for the full use-case after you add
"--trace gemdos" option
?
- Eero
Take care
Uwe
Hi,
Thanks for the Valgrind trace!
I commited a fix that that.
Could Uwe or you try whether it fixes also the crash?
I didn't have time to do that myself.
- Eero
On 07/11/2017 11:26 PM, Thomas Huth wrote:
Am Tue, 11 Jul 2017 22:19:52 +0200
schrieb Thomas Huth <th.huth@xxxxxxxxx>:
Am Tue, 11 Jul 2017 22:04:41 +0200
schrieb Uwe Seimet <Uwe.Seimet@xxxxxxxxx>:
Hi,
It also crashes without hard disk images. This is the stack
backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5e4697a in ?? () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff5e4697a in ?? () from /lib64/libc.so.6
#1 0x00007ffff5e47558 in ?? () from /lib64/libc.so.6
#2 0x000000000056c2e0 in ClearInternalDTA (idx=<optimized out>)
at /home/us/hatari/hatari/src/gemdos.c:348
Ah, that's the point! I did not adapt the GEMDOS HD setting in your
config file when I tried it, so Hatari was running without GEMDOS HD
emulation here.
If I set the GEMDOS HD path to something valid in your config file, it
crashes for me already during startup of Hatari:
#0 0x00007ffff5fe5738 in raise () from /lib64/libc.so.6
#1 0x00007ffff5fe734a in abort () from /lib64/libc.so.6
#2 0x00007ffff60266f0 in __libc_message () from /lib64/libc.so.6
#3 0x00007ffff602ee7a in _int_free () from /lib64/libc.so.6
#4 0x00007ffff60323dc in free () from /lib64/libc.so.6
#5 0x000000000058b3e6 in INF_CreateOverride ()
at /home/thomas/devel/hatari/mercurial/src/inffile.c:826 #6
0x000000000058911c in TOS_LoadImage ()
at /home/thomas/devel/hatari/mercurial/src/tos.c:707 #7
0x000000000057bdd0 in Reset_ST (bCold=bCold@entry=true)
at /home/thomas/devel/hatari/mercurial/src/reset.c:54 #8
0x000000000057bf31 in Reset_Cold ()
at /home/thomas/devel/hatari/mercurial/src/reset.c:127 #9
0x000000000057634a in Main_Init ()
at /home/thomas/devel/hatari/mercurial/src/main.c:730 #10 main
(argc=3, argv=0x7fffffffdea8)
at /home/thomas/devel/hatari/mercurial/src/main.c:892
Looks like there is a problem with the INF code that Eero added a
couple of weeks ago. Eero, could you please have a look?
FWIW, looks like a buffer overflow, valgrind reports:
==3313== Invalid write of size 1
==3313== at 0x4C2ECC7: strcpy (vg_replace_strmem.c:506)
==3313== by 0x58A7CB: get_builtin_inf (inffile.c:535)
==3313== by 0x58B15B: get_inf_file (inffile.c:618)
==3313== by 0x58B15B: INF_CreateOverride (inffile.c:822)
==3313== by 0x58911B: TOS_LoadImage (tos.c:707)
==3313== by 0x57BDCF: Reset_ST (reset.c:54)
==3313== by 0x57BF30: Reset_Cold (reset.c:127)
==3313== by 0x576349: Main_Init (main.c:730)
==3313== by 0x576349: main (main.c:892)
==3313== Address 0x111c1978 is 0 bytes after a block of size 792 alloc'd
==3313== at 0x4C2BBAD: malloc (vg_replace_malloc.c:299)
==3313== by 0x58A70C: get_builtin_inf (inffile.c:504)
==3313== by 0x58B15B: get_inf_file (inffile.c:618)
==3313== by 0x58B15B: INF_CreateOverride (inffile.c:822)
==3313== by 0x58911B: TOS_LoadImage (tos.c:707)
==3313== by 0x57BDCF: Reset_ST (reset.c:54)
==3313== by 0x57BF30: Reset_Cold (reset.c:127)
==3313== by 0x576349: Main_Init (main.c:730)
==3313== by 0x576349: main (main.c:892)
Thomas