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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/