|Re: [hatari-devel] ide.c segfault when config changed to Falcon|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
That looks like SDL, not Hatari bug.
Which SDL version you're using?
Could you get also backtrace with a Hatari version
from which haven't stripped debug symbols (use
"RelWithDebInfo" build type) after you're
installed SDL debug symbols package?
On 1/14/21 2:24 PM, Laurent Sallafranque wrote:
I don(t know if this can be of any help, but here is the stack when it
#0 tcache_get (tc_idx=<optimized out>) at malloc.c:2937
#1 __GI___libc_malloc (bytes=24) at malloc.c:3051
#2 0x00007ffff7b3d106 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffff7b3dcda in _XReply () from /lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007ffff7b39641 in XSync () from /lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff7f32b54 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#6 0x00007ffff7f05725 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#7 0x00007ffff7eaab94 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#8 0x00007ffff7eaada9 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#9 0x00007ffff7ea73a3 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#10 0x0000555555920f60 in Screen_SetSDLVideoSize ()
#11 0x0000555555921795 in Screen_SetSTResolution ()
#12 0x0000555555923307 in Screen_Reset ()
#13 0x0000555555919f3d in Reset_ST ()
#14 0x00005555558cb34a in Change_CopyChangedParamsToConfiguration ()
#15 0x00005555558ce78e in Dialog_DoProperty ()
#16 0x0000555555928e59 in ShortCut_ActKey ()
#17 0x0000555555939f77 in Video_InterruptHandler_VBL ()
#18 0x0000555555980ed2 in m68k_run_2ce ()
#19 0x000055555597ae02 in m68k_go ()
#20 0x00005555558bd7ef in main ()
Le 13/01/2021 à 23:27, Laurent Sallafranque a écrit :
I'm starting from the falc configuration.
When on the desktop, I load the hatari.cfg (which is the st
destination) and I select reset.
I get the core dump
Does this help ?
Le 13/01/2021 à 13:50, Nicolas Pomarède a écrit :
Le 13/01/2021 à 13:26, Laurent Sallafranque a écrit :
I've also noticed another hatari core dump.
I start in falcon mode and I change all my conf to switch to ST mode
and I click reboot now.
Hatari then crash.
can you be more specific on the tos version you use before and after
Le 13/01/2021 à 11:17, Nicolas Pomarède a écrit :
Le 07/12/2020 à 20:46, Thomas Huth a écrit :
Am Mon, 7 Dec 2020 15:28:13 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
Le 06/12/2020 à 17:59, Eero Tamminen a écrit :
I've pushed doc updates for all the fixes.
Unless there are objections, I was thinking of
pushing also my fix for the issue with double
usage of same image through ACSI/SCSI/IDE
(the one Uwe reported).
I'm not against it, but on my side I don't use ACSI/SCSI/IDE, so I'm
not able to test if these changes can have any side effects.
More testers would be needed for this fix to ensure all cases are
FWIW, the patches look pretty straight-forward to me, so I think it
should be safe to commit them. I currently don't have much spare time
for testing, though, sorry.
unfortunately, I found another case where Hatari might crash
because of IDE IO.
start hatari in falcon mode (with --tos tos404.img) then do a
memory save while falcon mode is booting (atari logo displayed in
exit hatari and restart hatari with --memstate and the name of the
save file. hatari should start, complete the floppy test and then
core dump when it comes to checking IDE state.
#0 0x00000000005f6980 in Ide_Mem_bget ()
#1 0x0000000000691d34 in wait_cpu_cycle_read_ce020 ()
#2 0x0000000000bd1070 in op_4a39_24_ff ()
#3 0x000000000066fca8 in m68k_run_3ce ()
#4 0x000000000066a852 in m68k_go ()
#5 0x00000000005bc9a3 in main ()
In my case I don't use any IDE drive, so it's likely to be some
null pointers in IDE part as we saw before.