Re: [hatari-devel] Resetting the machine crashes Hatari

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi,

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.

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
> >
> >
> >
> 
>