BasiliskII causes SIGSEGV when run in gdb

[maf]

I'm trying to debug BasiliskII in Windows 10 with MinGW (GCC 8.2.0). To this end, I have downloaded the sources of SDL2 and BasiliskII as described in Build kanjitalk755's BasiliskII code in Windows. After sucessfully compiling and installing both, I was able to run this version of BasiliskII without problems.

I then compiled both packages with the additional compiler flags "-ggdb -O0". (First, I used "-g -O0". But the BasiliskII configure script will delete "-g" for reasons I don't understand.) Also, this version of BasiliskII runs fine as a standalone application, e.g.

Code: Select all

BasiliskII.exe --config <path to config file> --rom <path to ROM file>

But trying to run this version of BasiliskII in gdb consistenly produces a segmentation fault:

Code: Select all

$ gdb --args BasiliskII.exe --config <path to config file> --rom <path to ROM file>
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from <path to BasiliskII.exe>...done.
(gdb) run
Starting program: <path to BasiliskII.exe> --config <path to config file> --rom <path to ROM file>
[New Thread 4824.0x35e4]
[New Thread 4824.0x1380]
[New Thread 4824.0x3120]
[New Thread 4824.0x40d8]
warning: onecore\com\combase\objact\objact.cxx(836)\combase.dll!766CAE4C: (caller: 766C9E1B) ReturnHr(1) tid(35e4) 800401F0 CoInitialize wurde nicht aufgerufen.

warning: onecore\com\combase\objact\objact.cxx(836)\combase.dll!766CAE4C: (caller: 766C9E1B) ReturnHr(2) tid(35e4) 800401F0 CoInitialize wurde nicht aufgerufen.

warning: onecore\com\combase\objact\objact.cxx(836)\combase.dll!766CAE4C: (caller: 766C9E1B) ReturnHr(3) tid(35e4) 800401F0 CoInitialize wurde nicht aufgerufen.

[New Thread 4824.0x3394]
[New Thread 4824.0x15ec]
[New Thread 4824.0x46d4]
[New Thread 4824.0x183c]
[New Thread 4824.0x1a5c]
[New Thread 4824.0x3d94]
[New Thread 4824.0x439c]
[New Thread 4824.0x4478]
[New Thread 4824.0x2cf4]

Program received signal SIGSEGV, Segmentation fault.
0x004df54e in op_eaf8_0_nf (opcode=277151744) at cpuemu.cpp:33055
33055           int width = (((extra & 0x20 ? m68k_dreg(regs, extra & 7) : extra) -1) & 0x1f) +1;
(gdb) bt
#0  0x004df54e in op_eaf8_0_nf (opcode=277086208) at cpuemu.cpp:33055
#1  0x004e1404 in op_ecf9_0_nf (opcode=0) at cpuemu.cpp:33445
#2  0x004e1bc0 in op_edf0_0_nf (opcode=5118912) at cpuemu.cpp:33551
#3  0x004e23fd in op_eec0_0_nf (opcode=25164120) at cpuemu.cpp:33654
#4  0x004c173f in op_44e0_0_nf (opcode=1048576) at cpuemu.cpp:13141
#5  0x004c2206 in op_4690_0_nf (opcode=10736092) at cpuemu.cpp:13510
#6  0x0069b56c in BlitNtoNPixelAlpha (info=0x17ffd18) at src/video/SDL_blit_A.c:1249
#7  0x0069b5cb in BlitNtoNPixelAlpha (info=0x4c0000 <op_33f0_3_nf(unsigned int)+44>) at src/video/SDL_blit_A.c:1249
#8  0x007c82e4 in __EH_FRAME_BEGIN__ ()
#9  0x004c0000 in op_33f0_3_nf (opcode=4294967295) at cpuemu.cpp:37791
#10 0x004c1236 in op_4478_0_nf (opcode=28846576) at cpuemu.cpp:12956
#11 0x004c1305 in op_4490_0_nf (opcode=0) at cpuemu.cpp:12994
#12 0x774f7b74 in ?? ()
#13 0x774f7b44 in ?? ()
#14 0x00000000 in ?? ()

What am I missing?

[adespoton]

I don't see anything inherently wrong, but I'd always do that line as:

Code: Select all

gdb --args "BasiliskII.exe --config <path to config file> --rom <path to ROM file>"

[maf]

In reality, the paths specified as option arguments contain blanks, so the line looks more like

Code: Select all

$ gdb --args BasiliskII.exe --config "path to config file" --rom "path to ROM file"

I added single quotes but got

Code: Select all

$ gdb --args 'BasiliskII.exe --config "path to config file" --rom "path to ROM file"'
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
BasiliskII.exe --config "path to config file" --rom "path to ROM file": No such file or directory.
(gdb) run
Starting program:
No executable specified, use `target exec'.
(gdb)

[adespoton]

Hmm... maybe I put the single quotes after the executable. What happens when you run it with no arguments? Also, if you put the path to the ROM file in the config file, you don't need to add the rom flag.

[maf]

Sorry, I should have reported that Basilisk starts (just as without gdb) and complains that the keycodes file specified in the configuration is not available. Therefore, the configuration file and the ROM file are found and read. The segfault does occur after Basislik has opened a blank window. So I don't think the arguments are causing the problem.

[adespoton]

It's probably down to BII using debug control itself; the two are possibly not compatible. The BII documentation says that to debug BII, you should compile it with the optional cxmon code and use that debugger in-line.

[maf]

cxmon does not look like a potential substitute for GDB to me. I have found references to using cxmon for BasiliskII only in the context of the JIT compiler. Could you possibly point me to the part of the documentation you are referring to?

To check whether the JIT compiler might cause the GDB problem, I configured a version of BasiliskII with --disable-jit-compiler. But that version segfaults when run with gdb, too.

[Ronald P. Regensburg]

JIT is disabled in the current kanjitalk755 source for BasiliskII because it caused serious instability.

[kanjitalk755]

This is the reply for maf's PM.

I tried, but got Windows alert "Visual Studio Just-In-Time Debugger".
Back to gdb, BasiliskII has already exited and no back trace.
I am not familiar with Windows, so I don't know what to do.

BTW, if you use Windows10, how about WSL?
I tried under WSL, I succeeded to run BasiliskII from gdb with -ggdb -O0.

One more alternative:
https://github.com/rakslice/macemu/tree ... ingw32_wip

It it for MSYS2/mingw32.
BasiliskII runs fine from gdb with -ggdb -O0.

[maf]

Thanks for your suggestions. I'll have a look at rakslice's repository.

BTW, if you use Windows10, how about WSL?
I tried under WSL, I succeeded to run BasiliskII from gdb with -ggdb -O0.

This would be a Linux binary of BasiliskII using a Windows X server, right?

[kanjitalk755]

This would be a Linux binary of BasiliskII using a Windows X server, right?

Yes.

If you need not only to be able to debug but also the Windows binary, I recommend rakslice's fork.

[maf]

One more alternative:
https://github.com/rakslice/macemu/tree ... ingw32_wip

It it for MSYS2/mingw32.
BasiliskII runs fine from gdb with -ggdb -O0.

I tried that and got a segfault, too.

So may be its my setup. I'm using MSYS/MinGW from http://www.mingw.org/. Should I be using MSYS2 and MinGW-w32 from https://www.msys2.org? Or MSYS2 with MinGW? I'm confused...

[kanjitalk755]

Perhaps https://www.msys2.org.

In src/Windows/config.h, try commenting out following line.

Code: Select all

#define ENABLE_VOSF 1

[maf]

Great! With

/* Define if using video enabled on SEGV signals. */
// #define ENABLE_VOSF 1

there is no segfault when I start BasiliskII with gdb. I'm still using MSYS/mingw32.

The configure option --disable-vosf mentioned here does not seem to exist.

What does "video on SEGV signals support" (taken from video_vosf.h) do?

[kanjitalk755]

I don't know what it is for.
But it uses SIGSEGV on purpose.

[adespoton]

I used to know what it did... it's using the fault debug hook as a place to sync the video clock IIRC. This is not legal in Catalina. Intel is also fixing (in hardware) the ability to address from 0 as SheepShaver uses (not sure about BII). So in a couple of years, SS may no longer work on current hardware without disabling that hardware check.

[Ronald P. Regensburg]

Not sure if this is related.

I use SD Notary to notarize my SheepShaver and BasiliskII builds fore macOS. In order to successfully complete the notarization process, I need to start with the advanced option "Disable exec. mem. protection" checked.

[kanjitalk755]

For JIT compiler.
It writes native binary as data, then executes them.
So JIT translation cache is set up by vm_protect() with VM_PROT_EXECUTE flag.

[rakslice]

VOSF is not for synchronization, it is only a way to keep track of what screen regions have changed in video memory since the last host display update. VOSF uses the memory write protection settings and some code in the memory fault handler to implement a one-shot write alarm for each page of memory in the emulated Mac's framebuffer, sort of a guard-pages-but-only-for-writes. It's an alternative to figuring out what's different by just comparing against an entire copy of the framebuffer from the last update, what we rely on without VOSF. And either of those approaches are in service of being able to send updates to the underlying video implementation (e.g. SDL) with fewer pixels that didn't actually change, to improve performance -- i.e. to be worth doing, they have to be doable faster than the time savings of the smaller update compared to just sending the whole screen, on average.