Re: [hatari-devel] Resetting the machine crashes Hatari |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Resetting the machine crashes Hatari
- From: Uwe Seimet <Uwe.Seimet@xxxxxxxxx>
- Date: Fri, 14 Jul 2017 08:19:22 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500013162; l=5002; s=domk; d=seimet.de; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Subject:To:From:Date; bh=hkQvnaBWoQK38Z8TIM02GXi2rPKUJ51URcJ1rAAnpOc=; b=OWaVRlZMghE5mG+VL4dOTPy44BAX2min9+3vQuEzeNXibFfcXugtRYde5XNSSY1tYu PKFE5o3X5JNuJgoav4jLv4QaIngwQRqH677T5xiJ1OXgK6WHArNDixth93V9O3BOEDSH 1fI0Ztgacnc1o9naEaNUvo0bDrFokvfopnKLo=
Hi,
> Do you still see this issue if you disable all ACSI &
> IDE drives and just use GEMDOS HD emulation?
Yes, I still have this issue.
Take care
Uwe
>
>
> - 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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
>
>