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
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
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.
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?