kvm backend Got into OnDebugTrap with LastBreakpoint error #223

jasocrow · 2025-01-22T15:53:04Z

I am consistently seeing the error message "Got into OnDebugTrap with LastBreakpoint error" when using the KVM backend.

I suspect the trap flag needs to be explicitly disabled here:

Instead of:

    if (TraceType_ == TraceType_t::Rip) {
      TrapFlag(true);
    } else {
      KvmDebugPrint("Turning off RFLAGS.TF\n");
    }

do:

    if (TraceType_ == TraceType_t::Rip) {
      TrapFlag(true);
    } else {
      KvmDebugPrint("Turning off RFLAGS.TF\n");
     TrapFlag(false);
    }

0vercl0k · 2025-01-22T16:11:54Z

Hello! Are you able to share more information about what you are doing / what you are seeing? I quickly skimmed through the piece of code you have linked but the code change you are suggesting is a no-op as TF should be cleared automatically after it triggered unless I am missing something 😅 If the code change fixes your issue then I'll need to look into this more tonight. Cheers

…

On Wed, Jan 22, 2025 at 7:53 AM jasocrow ***@***.***> wrote: I am consistently seeing the error message "Got into OnDebugTrap with LastBreakpoint error" when using the KVM backend. I suspect the trap flag needs to be explicitly disabled here <https://github.com/0vercl0k/wtf/blob/ebdccdd03efc7df9c6145fee3fcee973624eac85/src/wtf/kvm_backend.cc#L1583C1-L1587C6> : Instead of: if (TraceType_ == TraceType_t::Rip) { TrapFlag(true); } else { KvmDebugPrint("Turning off RFLAGS.TF\n"); } do: if (TraceType_ == TraceType_t::Rip) { TrapFlag(true); } else { KvmDebugPrint("Turning off RFLAGS.TF\n"); TrapFlag(false); } — Reply to this email directly, view it on GitHub <#223>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALIORPB3NCQJAJIO3XYBYD2L65HLAVCNFSM6AAAAABVVIUHX6VHI2DSMVQWIX3LMV43ASLTON2WKOZSHAYDINZVGA3DKMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

jasocrow · 2025-01-22T20:53:35Z

Thanks for the quick response!

I am seeing this every time I use the KVM backend when I fuzz using the latest wtf code. I see this error almost immediately on every fuzz iteration as soon as one of my breakpoints is executed.

kvm: Handling bp @ 0x55c26332c200                                                                                        |kvm: Handling bp @ 0x55c26332c200
kvm: Disarming bp and turning on RFLAGS.TF (rip=0x55c26332c200)                                                          |kvm: Disarming bp and turning on RFLAGS.TF (rip=0x55c26332c200)
kvm: Turning on RFLAGS.TF                                                                                                |kvm: Turning on RFLAGS.TF
kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c201                                                                       |kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c201
kvm: Received debug trap @ 0x55c26332c201                                                                                |kvm: Received debug trap @ 0x55c26332c201
kvm: Resetting breakpoint @ 0x3711b200kvm: Turning off RFLAGS.TF                                                         |kvm: Resetting breakpoint @ 0x3711b200kvm: Turning off RFLAGS.TF
kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c204                                                                       |kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c204
kvm: Received debug trap @ 0x55c26332c204                                                                                |kvm: Received debug trap @ 0x55c26332c204
Got into OnDebugTrap with LastBreakpointGpa_ = none

If I look at the disassembly of the instructions, I see that 0x55c26332c204 is the address of the instruction immediately following 0x55c26332c201, indicating that the TF is remaining set for some reason.

.text:0000000003047200 55        push    rbp       ; breakpoint here (0x55c26332c200)
.text:0000000003047201 48 89 E5  mov     rbp, rsp  ; first KVM_EXIT_DEBUG
.text:0000000003047204 41 57     push    r15       ; second KVM_EXIT_DEBUG

Adding the fix I suggested above in my private copy of wtf fixes the issue.

I swear I've run into this issue before as well with a different custom hypervisor I was using. IIRC, the trap flag was not getting cleared automatically when a VM-exit related to it occurred, which was not the behavior that I had initially expected.

0vercl0k · 2025-01-22T21:24:03Z

Yikes this looks really bad then - I'll take a look after work tonight; sorry for this 😔 Cheers

…

On Wed, Jan 22, 2025 at 12:53 PM jasocrow ***@***.***> wrote: Thanks for the quick response! I am seeing this every time I use the KVM backend when I fuzz using the latest wtf code. I see this error almost immediately on every fuzz iteration as soon as one of my breakpoints is executed. kvm: Handling bp @ 0x55c26332c200 |kvm: Handling bp @ 0x55c26332c200 kvm: Disarming bp and turning on RFLAGS.TF (rip=0x55c26332c200) |kvm: Disarming bp and turning on RFLAGS.TF (rip=0x55c26332c200) kvm: Turning on RFLAGS.TF |kvm: Turning on RFLAGS.TF kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c201 |kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c201 kvm: Received debug trap @ 0x55c26332c201 |kvm: Received debug trap @ 0x55c26332c201 kvm: Resetting breakpoint @ 0x3711b200kvm: Turning off RFLAGS.TF |kvm: Resetting breakpoint @ 0x3711b200kvm: Turning off RFLAGS.TF kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c204 |kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c204 kvm: Received debug trap @ 0x55c26332c204 |kvm: Received debug trap @ 0x55c26332c204 Got into OnDebugTrap with LastBreakpointGpa_ = none If I look at the disassembly of the instructions, I see that 0x55c26332c204 is the address of the instruction immediately following 0x55c26332c201, indicating that the TF is remaining set for some reason. .text:0000000003047200 55 push rbp ; breakpoint here (0x55c26332c200) .text:0000000003047201 48 89 E5 mov rbp, rsp ; first KVM_EXIT_DEBUG .text:0000000003047204 41 57 push r15 ; second KVM_EXIT_DEBUG Adding the fix I suggested above in my private copy of wtf fixes the issue. I swear I've run into this issue before as well with a different custom hypervisor I was using. IIRC, the trap flag was not getting cleared automatically when a VM-exit related to it occurred, which was not the behavior that I had initially expected. — Reply to this email directly, view it on GitHub <#223 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALIORMXOK6BFB6JNMQ2QN32MAAONAVCNFSM6AAAAABVVIUHX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBYGI2DCNBUHA> . You are receiving this because you commented.Message ID: ***@***.***>

0vercl0k · 2025-01-22T21:42:17Z

I am guessing you don't see the same offending behavior on v0.5.4 btw? I just tried the HEVD sample against the latest trunk & it seems to run fine. Also, do you see the same behavior if you run the HEVD sample in your set-up? Asking to see if I should witness a repro or not. Cheers

…

On Wed, Jan 22, 2025 at 1:23 PM Axel ***@***.***> wrote: Yikes this looks really bad then - I'll take a look after work tonight; sorry for this 😔 Cheers On Wed, Jan 22, 2025 at 12:53 PM jasocrow ***@***.***> wrote: > Thanks for the quick response! > > I am seeing this every time I use the KVM backend when I fuzz using the > latest wtf code. I see this error almost immediately on every fuzz > iteration as soon as one of my breakpoints is executed. > > kvm: Handling bp @ 0x55c26332c200 |kvm: Handling bp @ 0x55c26332c200 > kvm: Disarming bp and turning on RFLAGS.TF (rip=0x55c26332c200) |kvm: Disarming bp and turning on RFLAGS.TF (rip=0x55c26332c200) > kvm: Turning on RFLAGS.TF |kvm: Turning on RFLAGS.TF > kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c201 |kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c201 > kvm: Received debug trap @ 0x55c26332c201 |kvm: Received debug trap @ 0x55c26332c201 > kvm: Resetting breakpoint @ 0x3711b200kvm: Turning off RFLAGS.TF |kvm: Resetting breakpoint @ 0x3711b200kvm: Turning off RFLAGS.TF > kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c204 |kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c204 > kvm: Received debug trap @ 0x55c26332c204 |kvm: Received debug trap @ 0x55c26332c204 > Got into OnDebugTrap with LastBreakpointGpa_ = none > > If I look at the disassembly of the instructions, I see that > 0x55c26332c204 is the address of the instruction immediately following > 0x55c26332c201, indicating that the TF is remaining set for some reason. > > .text:0000000003047200 55 push rbp ; breakpoint here (0x55c26332c200) > .text:0000000003047201 48 89 E5 mov rbp, rsp ; first KVM_EXIT_DEBUG > .text:0000000003047204 41 57 push r15 ; second KVM_EXIT_DEBUG > > Adding the fix I suggested above in my private copy of wtf fixes the > issue. > > I swear I've run into this issue before as well with a different custom > hypervisor I was using. IIRC, the trap flag was not getting cleared > automatically when a VM-exit related to it occurred, which was not the > behavior that I had initially expected. > > — > Reply to this email directly, view it on GitHub > <#223 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AALIORMXOK6BFB6JNMQ2QN32MAAONAVCNFSM6AAAAABVVIUHX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBYGI2DCNBUHA> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

0vercl0k · 2025-01-22T22:25:08Z

If I check the code before / after implementing RIP traces for KVM; I do see the change in behavior you are referring to, and it doesn't use directly TF but instead uses the interface that KVM exposes (KVM_GUESTDBG_ENABLE / KVM_GUESTDBG_SINGLESTEP) which seems to need resetting. This is all consistent with what you are seeing, what you fixed. I am still puzzled on why I don't see this on the HEVD sample; maybe I don't even hit that code path 🤔 anyways, will keep the thread updated once I figure it out. Cheers

…

On Wed, Jan 22, 2025 at 1:42 PM Axel ***@***.***> wrote: I am guessing you don't see the same offending behavior on v0.5.4 btw? I just tried the HEVD sample against the latest trunk & it seems to run fine. Also, do you see the same behavior if you run the HEVD sample in your set-up? Asking to see if I should witness a repro or not. Cheers On Wed, Jan 22, 2025 at 1:23 PM Axel ***@***.***> wrote: > Yikes this looks really bad then - I'll take a look after work tonight; > sorry for this 😔 > > Cheers > > On Wed, Jan 22, 2025 at 12:53 PM jasocrow ***@***.***> > wrote: > >> Thanks for the quick response! >> >> I am seeing this every time I use the KVM backend when I fuzz using the >> latest wtf code. I see this error almost immediately on every fuzz >> iteration as soon as one of my breakpoints is executed. >> >> kvm: Handling bp @ 0x55c26332c200 |kvm: Handling bp @ 0x55c26332c200 >> kvm: Disarming bp and turning on RFLAGS.TF (rip=0x55c26332c200) |kvm: Disarming bp and turning on RFLAGS.TF (rip=0x55c26332c200) >> kvm: Turning on RFLAGS.TF |kvm: Turning on RFLAGS.TF >> kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c201 |kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c201 >> kvm: Received debug trap @ 0x55c26332c201 |kvm: Received debug trap @ 0x55c26332c201 >> kvm: Resetting breakpoint @ 0x3711b200kvm: Turning off RFLAGS.TF |kvm: Resetting breakpoint @ 0x3711b200kvm: Turning off RFLAGS.TF >> kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c204 |kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c204 >> kvm: Received debug trap @ 0x55c26332c204 |kvm: Received debug trap @ 0x55c26332c204 >> Got into OnDebugTrap with LastBreakpointGpa_ = none >> >> If I look at the disassembly of the instructions, I see that >> 0x55c26332c204 is the address of the instruction immediately following >> 0x55c26332c201, indicating that the TF is remaining set for some reason. >> >> .text:0000000003047200 55 push rbp ; breakpoint here (0x55c26332c200) >> .text:0000000003047201 48 89 E5 mov rbp, rsp ; first KVM_EXIT_DEBUG >> .text:0000000003047204 41 57 push r15 ; second KVM_EXIT_DEBUG >> >> Adding the fix I suggested above in my private copy of wtf fixes the >> issue. >> >> I swear I've run into this issue before as well with a different custom >> hypervisor I was using. IIRC, the trap flag was not getting cleared >> automatically when a VM-exit related to it occurred, which was not the >> behavior that I had initially expected. >> >> — >> Reply to this email directly, view it on GitHub >> <#223 (comment)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AALIORMXOK6BFB6JNMQ2QN32MAAONAVCNFSM6AAAAABVVIUHX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBYGI2DCNBUHA> >> . >> You are receiving this because you commented.Message ID: >> ***@***.***> >> >

0vercl0k · 2025-01-22T22:27:42Z

Okay actually, my guess is that all the breakpoints I hit with HEVD either directly kill the testcase, or move `@RIP` from the handler. In the first case, the testcase ends so I don't even get to see this and in the second one I don't need to use TF because RIP has moved so no need to step-over the breakpoint. I'll verify this in a few hours! Cheers

…

On Wed, Jan 22, 2025 at 2:24 PM Axel ***@***.***> wrote: If I check the code before / after implementing RIP traces for KVM; I do see the change in behavior you are referring to, and it doesn't use directly TF but instead uses the interface that KVM exposes (KVM_GUESTDBG_ENABLE / KVM_GUESTDBG_SINGLESTEP) which seems to need resetting. This is all consistent with what you are seeing, what you fixed. I am still puzzled on why I don't see this on the HEVD sample; maybe I don't even hit that code path 🤔 anyways, will keep the thread updated once I figure it out. Cheers On Wed, Jan 22, 2025 at 1:42 PM Axel ***@***.***> wrote: > I am guessing you don't see the same offending behavior on v0.5.4 btw? I > just tried the HEVD sample against the latest trunk & it seems to run fine. > > Also, do you see the same behavior if you run the HEVD sample in your > set-up? Asking to see if I should witness a repro or not. > > Cheers > > On Wed, Jan 22, 2025 at 1:23 PM Axel ***@***.***> wrote: > >> Yikes this looks really bad then - I'll take a look after work tonight; >> sorry for this 😔 >> >> Cheers >> >> On Wed, Jan 22, 2025 at 12:53 PM jasocrow ***@***.***> >> wrote: >> >>> Thanks for the quick response! >>> >>> I am seeing this every time I use the KVM backend when I fuzz using the >>> latest wtf code. I see this error almost immediately on every fuzz >>> iteration as soon as one of my breakpoints is executed. >>> >>> kvm: Handling bp @ 0x55c26332c200 |kvm: Handling bp @ 0x55c26332c200 >>> kvm: Disarming bp and turning on RFLAGS.TF (rip=0x55c26332c200) |kvm: Disarming bp and turning on RFLAGS.TF (rip=0x55c26332c200) >>> kvm: Turning on RFLAGS.TF |kvm: Turning on RFLAGS.TF >>> kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c201 |kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c201 >>> kvm: Received debug trap @ 0x55c26332c201 |kvm: Received debug trap @ 0x55c26332c201 >>> kvm: Resetting breakpoint @ 0x3711b200kvm: Turning off RFLAGS.TF |kvm: Resetting breakpoint @ 0x3711b200kvm: Turning off RFLAGS.TF >>> kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c204 |kvm: exit_reason = KVM_EXIT_DEBUG @ 0x55c26332c204 >>> kvm: Received debug trap @ 0x55c26332c204 |kvm: Received debug trap @ 0x55c26332c204 >>> Got into OnDebugTrap with LastBreakpointGpa_ = none >>> >>> If I look at the disassembly of the instructions, I see that >>> 0x55c26332c204 is the address of the instruction immediately following >>> 0x55c26332c201, indicating that the TF is remaining set for some >>> reason. >>> >>> .text:0000000003047200 55 push rbp ; breakpoint here (0x55c26332c200) >>> .text:0000000003047201 48 89 E5 mov rbp, rsp ; first KVM_EXIT_DEBUG >>> .text:0000000003047204 41 57 push r15 ; second KVM_EXIT_DEBUG >>> >>> Adding the fix I suggested above in my private copy of wtf fixes the >>> issue. >>> >>> I swear I've run into this issue before as well with a different custom >>> hypervisor I was using. IIRC, the trap flag was not getting cleared >>> automatically when a VM-exit related to it occurred, which was not the >>> behavior that I had initially expected. >>> >>> — >>> Reply to this email directly, view it on GitHub >>> <#223 (comment)>, >>> or unsubscribe >>> <https://github.com/notifications/unsubscribe-auth/AALIORMXOK6BFB6JNMQ2QN32MAAONAVCNFSM6AAAAABVVIUHX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBYGI2DCNBUHA> >>> . >>> You are receiving this because you commented.Message ID: >>> ***@***.***> >>> >>

… a breakpoint & re-enabled it (fix #223)

0vercl0k · 2025-01-23T00:37:25Z

Okay yeah I confirmed the above; below outputs are w/o a breakpoint that needs single-stepping over it (so 'no bug')..:

bubuntu:~/wtf/targets/hevd$ sudo ../../src/build/wtf run --name hevd --input ./inputs/A --backend kvm
Found a 'state' folder in the cwd, so using it.
The debugger instance is loaded with 7 items
PMU Version 2 is available (3 fixed counters of 48 bits)
Resolved breakpoint 0xfffff8046f1bf830 at GPA 0x27bf830 aka HVA 0x56005f657c10
Setting debug register status to zero.
Setting debug register status to zero.
Setting mxcsr_mask to 0xffbf.
Resolved breakpoint 0x7ff6f5bb1124 at GPA 0xd374124 aka HVA 0x56005f6585d4
Resolved breakpoint 0xfffff8046f122bb0 at GPA 0x2722bb0 aka HVA 0x56005f65a090
Resolved breakpoint 0xfffff8046f0287c4 at GPA 0x26287c4 aka HVA 0x56005f65acd4
Resolved breakpoint 0xfffff8046f2a53e0 at GPA 0x28a53e0 aka HVA 0x56005f65b920
Resolved breakpoint 0xfffff8046f1c3880 at GPA 0x27c3880 aka HVA 0x56005f65cdf0
Running ./inputs/A
kvm: exit_reason = KVM_EXIT_DEBUG @ 0xfffff8046f122bb0
kvm: Handling bp @ 0xfffff8046f122bb0
Hevd: DbgPrintEx: [-] Invalid IOCTL Code: 0x%X
kvm: The bp handler ended up moving @rip from 0xfffff8046f122bb0 to 0xfffff8046ca955ec so no need to do the step-over dance
kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff6f5bb1124
kvm: Handling bp @ 0x7ff6f5bb1124
Hevd: Back from kernel!
kvm: The bp handler asked us to stop so no need to do the step-over dance
--------------------------------------------------
Run stats:
          Dirty pages: 663552 bytes, 162 pages, 0 MB
            UffdPages: 684032 bytes, 167 pages, 0 MB
              VMExits: 2
Instructions executed: 6400
#1 cov: 0 exec/s: 0.0 lastcov: 0.0s crash: 0 timeout: 0 cr3: 0 uptime: 0.0s

..and w/ bp that needs single-stepping (triggers the bug):

bubuntu:~/wtf/targets/hevd$ sudo ../../src/build/wtf run --name hevd --input ./inputs/A --backend kvm
Found a 'state' folder in the cwd, so using it.
The debugger instance is loaded with 7 items
PMU Version 2 is available (3 fixed counters of 48 bits)
Resolved breakpoint 0xfffff8046f1bf830 at GPA 0x27bf830 aka HVA 0x5632583aac10
Setting debug register status to zero.
Setting debug register status to zero.
Setting mxcsr_mask to 0xffbf.
Resolved breakpoint 0x7ff6f5bb111e at GPA 0xd37411e aka HVA 0x5632583ab5ce
Resolved breakpoint 0x7ff6f5bb1124 at GPA 0xd374124 aka HVA 0x5632583ab5d4
Resolved breakpoint 0xfffff8046f122bb0 at GPA 0x2722bb0 aka HVA 0x5632583ad0b0
Resolved breakpoint 0xfffff8046f0287c4 at GPA 0x26287c4 aka HVA 0x5632583adcd4
Resolved breakpoint 0xfffff8046f2a53e0 at GPA 0x28a53e0 aka HVA 0x5632583ae920
Resolved breakpoint 0xfffff8046f1c3880 at GPA 0x27c3880 aka HVA 0x5632583afdf0
Running ./inputs/A
kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff6f5bb111e
kvm: Handling bp @ 0x7ff6f5bb111e
Hevd: Hello!
kvm: Disarming bp and turning on RFLAGS.TF (rip=0x7ff6f5bb111e)
kvm: Turning on RFLAGS.TF
kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff83e2e6360
kvm: Received debug trap @ 0x7ff83e2e6360
kvm: Resetting breakpoint @ 0xd37411ekvm: Turning off RFLAGS.TF
kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff83e2e6365
kvm: Received debug trap @ 0x7ff83e2e6365
Got into OnDebugTrap with LastBreakpointGpa_ = none--------------------------------------------------
Run stats:
          Dirty pages: 53248 bytes, 13 pages, 0 MB
            UffdPages: 90112 bytes, 22 pages, 0 MB
              VMExits: 3
Instructions executed: 2
#1 cov: 0 exec/s: 0.0 lastcov: 0.0s crash: 0 timeout: 0 cr3: 0 uptime: 0.0s

0vercl0k · 2025-01-23T00:42:12Z

I will be fixing this in #224 - I basically implemented your suggested fix.

I need to run for now but will run more tests when I'm back / see if there's another similar issue elsewhere in the code / if it might affect WHV as well.. and if we're good I'll release v0.5.6 to address this.

Thanks again for the report as usual 🙏🏽🙏🏽

Cheers

0vercl0k · 2025-01-23T04:58:28Z

Okay https://github.com/0vercl0k/wtf/releases/tag/v0.5.6 is out - hope this works fine this time 😅

Apologies for the trouble and thank you again for finding this & filling a report (and a suggested fix!) 🙏🏽🙏🏽

Cheers

jasocrow · 2025-01-23T14:41:29Z

Damn, thanks for getting a fix out so quickly!

0vercl0k · 2025-01-23T15:46:52Z

Heh, I had to to be honest - major regression 😥

Cheers

0vercl0k added a commit that referenced this issue Jan 23, 2025

make sure to properly disable single stepping once we've stepped over…

29f99aa

… a breakpoint & re-enabled it (fix #223)

0vercl0k linked a pull request Jan 23, 2025 that will close this issue

Disable single stepping once we've stepped over the breakpoint (fix #223) #224

Merged

0vercl0k closed this as completed in #224 Jan 23, 2025

0vercl0k closed this as completed in 8576012 Jan 23, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

kvm backend Got into OnDebugTrap with LastBreakpoint error #223

kvm backend Got into OnDebugTrap with LastBreakpoint error #223

jasocrow commented Jan 22, 2025

0vercl0k commented Jan 22, 2025 via email

jasocrow commented Jan 22, 2025

0vercl0k commented Jan 22, 2025 via email

0vercl0k commented Jan 22, 2025 via email

0vercl0k commented Jan 22, 2025 via email

0vercl0k commented Jan 22, 2025 via email •

edited

Loading

0vercl0k commented Jan 23, 2025

0vercl0k commented Jan 23, 2025

0vercl0k commented Jan 23, 2025

jasocrow commented Jan 23, 2025

0vercl0k commented Jan 23, 2025

kvm backend Got into OnDebugTrap with LastBreakpoint error #223

kvm backend Got into OnDebugTrap with LastBreakpoint error #223

Comments

jasocrow commented Jan 22, 2025

0vercl0k commented Jan 22, 2025 via email

jasocrow commented Jan 22, 2025

0vercl0k commented Jan 22, 2025 via email

0vercl0k commented Jan 22, 2025 via email

0vercl0k commented Jan 22, 2025 via email

0vercl0k commented Jan 22, 2025 via email • edited Loading

0vercl0k commented Jan 23, 2025

0vercl0k commented Jan 23, 2025

0vercl0k commented Jan 23, 2025

jasocrow commented Jan 23, 2025

0vercl0k commented Jan 23, 2025

0vercl0k commented Jan 22, 2025 via email •

edited

Loading