Crash after resuming execution from gdb stub

[ddcc7]

I am debugging a Ubuntu 18.04 virtual machine using the built-in gdb stub in VMware Workstation 16.1.0, with the following configuration options:

debugStub.listen.guest64 = "TRUE"
debugStub.hideBreakpoints = "TRUE"

I am able to connect to the stub fine and inspect the paused state, but when I attempt to resume execution using the "continue" command, the VM crashes:

2021-01-21T20:30:10.308-05:00| vmx| W003: Debug stub: Remote connection accepted from 127.0.0.1
2021-01-21T20:30:10.308-05:00| vmx| I005: SOCKET 12 (2280) AsyncTCPSocketSetOption: Option layer/level [6], option/name [1]: successfully set OS option for TCP socket.
2021-01-21T20:30:10.308-05:00| vcpu-0| I005: Vix: [vmxCommands.c:4557]: VMAutomation_Pause: pause = TRUE
2021-01-21T20:30:10.309-05:00| vcpu-0| I005: Not informing DCL we are stopping.
2021-01-21T20:30:10.313-05:00| mks| I005: MKS-VMDB: VMDB requested a screenshot
2021-01-21T20:30:10.313-05:00| svga| I005: MKSScreenShotMgr: Taking a screenshot
2021-01-21T20:30:10.316-05:00| mks| I005: MKS-VMDB: VMDB requested a screenshot
2021-01-21T20:30:10.335-05:00| svga| I005: MKSScreenShotMgr: Taking a screenshot
2021-01-21T20:30:10.372-05:00| mks| I005: SWBWindow: Number of MKSWindows changed: 0 rendering MKSWindow(s) of total 2.
2021-01-21T20:30:15.321-05:00| vcpu-2| E001: PANIC: NOT_IMPLEMENTED D:\build\ob\bora-17198959\bora\vmcore\monitor\ulm\platform\windows\ulm.c:6253
2021-01-21T20:30:15.321-05:00| vcpu-2| E001: Panic loop
MPLEMENTED D:\build\ob\bora-17198959\bora\vmcore\monitor\ulm\platform\windows\ulm.c:6253
2021-01-21T20:30:15.321-05:00| vcpu-0| E001: Panic loop
2021-01-21T20:30:15.321-05:00| vcpu-0| E001: Panic loop
2021-01-21T20:30:15.321-05:00| vcpu-2| I005: Backtrace:
2021-01-21T20:30:15.322-05:00| vcpu-0| 005: Backtrace:
MPLEMENTED D:\build\ob\bora-17198959\bora\vmcore\monitor\ulm\platform\windows\ulm.c:6253

[wila]

Hi,

The crash is in ulm.c

Without more details, part of it means that I'm guessing here, but there's a very high probability that it stands for "User Level Monitor" as it does elsewhere whenever VMware mentions "ulm".

As such that means your VM is running on a host with Hyper-V mode enabled.

That codepath is pretty new and is most likely why you are getting this issue.
The most likely workaround would be to disable Hyper-V mode at the host level.
This might not be an option for you though.

If it is then the steps to disable the Hyper-V role is to run the following command at the host in windows command-line with Administrator privileges:

bcdedit /set hypervisorlaunchtype off

Reboot the system to activate it.

If you want to go back to Hyper-V mode again, then you can enable it like this:

bcdedit /set hypervisorlaunchtype auto

hope this helps,
--

Wil

[ddcc7]

Thanks for the suggestion! Yeah it seems like the stub hasn't been tested much with the Hyper-V mode; I previously noticed there were log entries suggesting another issue with the stub and mksSandbox, and ended up disabling graphics acceleration for the VM to avoid the sandbox.

It's been a while since I've used the gdb stub, so it makes sense that disabling Hyper-V would revert to the previous behavior.

[shawnh_]

I am having the same problem. It occurs whether hardware breakpoints are used or not.

I just updated to Workstation 16 (16.1.1 build-17801498) because the advertising claimed it had better support for running under the hyper-v hypervisor. I guess not.

Unfortunately I cannot just disable hyper-v as I rely on hyper-v features and WSL2.

When is vmware going to support gdb stub when using ULM? Is there a different workaround?