[git][SDL2]Dosbox-X crashes on start if I set machine to amstrad.

[FredBezies]

Describe the bug
Hello.

Using a Dosbox-X based on commit 5e41a63, I noticed it crashes right after I set machine to amstrad.

It crashes without logging anything when launched from terminal :(

To Reproduce
Steps to reproduce the behavior:

1. Build dosbox-x based on commit 5e41a63
2. Launch it
3. In configuration tool, set main / machine to amstrad
4. Save the dosbox conf file and restart using it.

Expected behavior
Dosbox-X not crashing.

Environment (please complete the following information):

• Archlinux
• DOSBox-X commit 5e41a63
• Only modification: replacing machine=svga_s3 by machine=amstrad

Here is the coredump backtrace I got:

Core was generated by `./dosbox-x'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f1f8e19dd22 in raise () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7f1f7e2cf080 (LWP 227567))]
(gdb) bt
#0  0x00007f1f8e19dd22 in raise () at /usr/lib/libc.so.6
#1  0x00007f1f8e187862 in abort () at /usr/lib/libc.so.6
#2  0x00007f1f8e1dfd28 in __libc_message () at /usr/lib/libc.so.6
#3  0x00007f1f8e1e792a in  () at /usr/lib/libc.so.6
#4  0x00007f1f8e1e8cfc in _int_free () at /usr/lib/libc.so.6
#5  0x00007f1f8e1ec9e8 in free () at /usr/lib/libc.so.6
#6  0x00007f1f9027cd97 in  () at /usr/lib/libX11.so.6
#7  0x00007f1f9027d182 in _XEventsQueued () at /usr/lib/libX11.so.6
#8  0x00007f1f9025ebcb in XFlush () at /usr/lib/libX11.so.6
#9  0x00007f1f907ab8fa in  () at /usr/lib/libSDL2-2.0.so.0
#10 0x00007f1f9070857e in  () at /usr/lib/libSDL2-2.0.so.0
#11 0x00007f1f907085c9 in  () at /usr/lib/libSDL2-2.0.so.0
#12 0x000055a7d9ca51c0 in GFX_Events() () at sdlmain.cpp:7603
#13 0x000055a7d9a9c365 in Normal_Loop() () at dosbox.cpp:389
#14 0x000055a7d9a9c42e in DOSBOX_RunMachine() () at dosbox.cpp:615
#15 0x000055a7d9ecd77d in CALLBACK_RunRealInt(unsigned char)
    (intnum=intnum@entry=22 '\026') at callback.cpp:212
#16 0x000055a7d9c4fda9 in BIOS::cb_bios_startup_screen__func() ()
    at bios.cpp:8997
#17 0x000055a7d9a9c244 in Normal_Loop() () at dosbox.cpp:364
#18 0x000055a7d9a9c42e in DOSBOX_RunMachine() () at dosbox.cpp:615
#19 0x000055a7d9a9105e in main(int, char**)
    (argc=<optimized out>, argv=<optimized out>) at sdlmain.cpp:14683

[FredBezies]

Tried with SDL1, another crash.

Here is the backtrace I got from the coredump:

Core was generated by `/home/fred/dosbox-x/src/dosbox-x -conf dosbox-x.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f23e22c4449 in malloc () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7f23d2898080 (LWP 250276))]
(gdb) bt
#0  0x00007f23e22c4449 in malloc () at /usr/lib/libc.so.6
#1  0x00007f23e2210be0 in  () at /usr/lib/libxcb.so.1
#2  0x00007f23e220e8c7 in  () at /usr/lib/libxcb.so.1
#3  0x00007f23e221008f in  () at /usr/lib/libxcb.so.1
#4  0x00007f23e2210203 in xcb_wait_for_reply64 () at /usr/lib/libxcb.so.1
#5  0x00007f23e45e1679 in _XReply () at /usr/lib/libX11.so.6
#6  0x00007f23e45d755b in XQueryPointer () at /usr/lib/libX11.so.6
#7  0x0000564c537f63a8 in X11_SetKeyboardState
    (display=0x564c5a044b90, key_vec=key_vec@entry=0x7fffdb12a698 "\003")
    at /home/fred/dosbox-x/vs2015/sdl/src/video/x11/SDL_x11events.c:1377
#8  0x0000564c537f6c38 in X11_DispatchEvent (this=this@entry=0x564c5a042890)
    at /home/fred/dosbox-x/vs2015/sdl/src/video/x11/SDL_x11events.c:527
#9  0x0000564c537f744b in X11_PumpEvents (this=0x564c5a042890)
    at /home/fred/dosbox-x/vs2015/sdl/src/video/x11/SDL_x11events.c:969
#10 0x0000564c537e6be9 in SDL_PumpEvents ()
    at /home/fred/dosbox-x/vs2015/sdl/src/events/SDL_events.c:381
#11 0x0000564c537e6c29 in SDL_PollEvent (event=0x7fffdb12a8d0)
    at /home/fred/dosbox-x/vs2015/sdl/src/events/SDL_events.c:400
#12 0x0000564c533d1d98 in GFX_Events() () at sdlmain.cpp:7914
#13 0x0000564c531cfb65 in Normal_Loop() () at dosbox.cpp:389
#14 0x0000564c531cfc2e in DOSBOX_RunMachine() () at dosbox.cpp:615
#15 0x0000564c535f798d in CALLBACK_RunRealInt(unsigned char)
    (intnum=intnum@entry=22 '\026') at callback.cpp:212
#16 0x0000564c5337f779 in BIOS::cb_bios_startup_screen__func() ()
    at bios.cpp:8997
#17 0x0000564c531cfa44 in Normal_Loop() () at dosbox.cpp:364
#18 0x0000564c531cfc2e in DOSBOX_RunMachine() () at dosbox.cpp:615
#19 0x0000564c531c484e in main(int, char**)
    (argc=<optimized out>, argv=<optimized out>) at sdlmain.cpp:14683

Hope it helps!

[FredBezies]

Done some research: you have to go back to dosbox-x 0.83.13 to get a starting dosbox-x version with machine=amstrad.

[rderooy]

I'm unable to do this myself for the moment, but a git bisect should find the offending commit quite quickly. Just tell git which commit is good and bad and it will hone in on the offending commit in typically 6/7 builds.

[FredBezies]

I just have to found how to get a specific commit on github. I cannot get this to work. Will try later this week.

[joncampbell123]

Evidently some bitrot has set in, if Amstrad is crashing like that.

@FredBezies You have a local copy you made with "git clone", correct? Use "git log" to get a list of each commit. You can then do a "git checkout" followed by the commit number to get a snapshot of the files at that commit. You can also git checkout by tag name.

[FredBezies]

First feedback. Looks like this regression happened on May 21st, 2021.

I got a working build based on commit af95e80 (pushed on May 2nd, 2021).

When I tested a build based on commit f8c5092 (the last one pushed on May 21st, 2021), I got a crash.

I will test every commit pushed on May 21st, 2021 and report ASAP.

[Wengier]

I am checking this too. The issue appears to only happen on non-Windows platforms (no crash on Windows) with non-TTF outputs. You may also avoid the crash on Linux with -fastlaunch command-line option, or comment out line 8707 of bios.cpp:

CALLBACK_RunRealInt(0x10);

[FredBezies]

Got the guilty commit. It is commit 2f68df5

I have to say I don't know why this commit breaks machine=amstrad value in dosbox-x

[Wengier]

@FredBezies The said commit only changed the Config Tool and is supposed to have absolutely nothing to do with amstrad. Are you sure if it is this commit?

[FredBezies]

Well... Looks like I stepped on a bug which get fixed a little later. Still searching.

Looks like I lost myself in all these commits. I will retry from "scratch" all commits of may 2021. It will be a long afternoon...

[FredBezies]

So, I started my git bissecting from scratch. I knew that Dosbox-X 0.83.13 was OK, but not 0.84.14. I browse each backward, starting by May 31st, and going back one day each time to find the last working day. I used last commit of every day.

After 2 hours (each day testing took me around 5 to 10 minutes), I found the last working day was May 14th, 2021, commit 4d51ffd.

Well, I think I found the real guilty here: It is commit 5860652.

As soon as I built Dosbox-X using git checkout 5860652 and build script, the executable crashes.

When I tried May 15th last commit 4d51ffd, it was broken. I will look at which commit is guilty now. And of course, -fastlaunch works too :)

[cimarronm]

@FredBezies Can you test out PR #2681 and see if it fixes your crash?

[FredBezies]

@FredBezies Can you test out PR #2681 and see if it fixes your crash?

Tried your branch, without luck.

Maybe trying directly on main code will work better?

Edit: I made a debug build and got a stacktrace. Here is the output:

#5  0x00005590c57c5970 in GFX_Events() () at sdlmain.cpp:7609
#6  0x00005590c55bfc05 in Normal_Loop() () at dosbox.cpp:389
#7  0x00005590c55bfcce in DOSBOX_RunMachine() () at dosbox.cpp:615
#8  0x00005590c59ec5fd in CALLBACK_RunRealInt(unsigned char)
    (intnum=intnum@entry=22 '\026') at callback.cpp:212
#9  0x00005590c5770e09 in BIOS::cb_bios_startup_screen__func() ()
    at bios.cpp:8997
#10 0x00005590c55bfae4 in Normal_Loop() () at dosbox.cpp:364
#11 0x00005590c55bfcce in DOSBOX_RunMachine() () at dosbox.cpp:615
#12 0x00005590c55b497e in main(int, char**)
    (argc=<optimized out>, argv=<optimized out>) at sdlmain.cpp:14629

[Wengier]

With the code in PR #2681 it works for me too (thanks @cimarronm). Perhaps @FredBezies can test it again once it is merged.

[grapeli]

Finding the cause of this error is not so easy. Because the effects are different for surface and opengl as well as SDL1 and SDL2.

I narrowed my search to SDL2 and the opengl output only.
The culprit is in this pull requst - specifically this commit.
Checked under x86_64 - Archlinux with sdl2-2.0.14 and Debian stable with sdl2-2.0.9.

[FredBezies]

Finding the cause of this error is not so easy. Because the effects are different for surface and opengl as well as SDL1 and SDL2.

I narrowed my search to SDL2 and the opengl output only.
The culprit is in this pull requst - specifically this commit.
Checked under x86_64 - Archlinux with sdl2-2.0.14 and Debian stable with sdl2-2.0.9.

You find the same commit I reported earlier. See PR #2681.

And yes, it was long and hard to find this commit.

[grapeli]

I still have a problem with that.
Today I built dosbox-x 0.83.15 (39c31a) under google cloud shell. Debian stable, sdl2, gcc-8.3.0. CFLAGS/CXXFLAGS="-O1 -march=x86-64 -mtune=generic"
Launched under GCS (google cloud shell):
Intel (R) Xeon (R) CPU and AMD EPYC
Linux cs-840259782252-default-default-vst6x 5.4.120+ # 1 SMP Tue Jun 22 14:53:20 PDT 2021 x86_64 GNU / Linux
works correctly
./dosbox-x -set output=opengl -set machine=amstrad
Floating point exception (core dumped) Under AMD EPYC, segfault under Intel Xeon
./dosbox-x -set output=surface -set machine=amstrad

Same binary running under Archlinux Linux 5.13.1
starts up correctly
./dosbox-x -set output=surface -set machine=amstrad
when started this way exits segfault.
./dosbox-x -set output=opengl -set machine=amstrad

Surprisingly not obvious.

[FredBezies]

@grapeli: both surface and opengl works for me on start. Could it be related to your hardware? I'm using a Ryzen3 2200G (which integrates a GPU) without any crash on start on my three and half years old Archlinux installation.

[grapeli]

It was related to the MESA version (opengl) I was using. With the current one, it starts up flawlessly.

I don't know why the surface output is failing under GCP. I don't think there is any point in investigating, because this commit definitely fixes this unfortunate error.

[FredBezies]

It was related to the MESA version (opengl) I was using. With the current one, it starts up flawlessly.

I don't know why the surface output is failing under GCP. I don't think there is any point in investigating, because this commit definitely fixes this unfortunate error.

Ok. So let's close this bug now.