EpicGamesExt/raddebugger

Can crash the debugger after running this program many times with Ctrl+Shift+F5

Opened this issue · 1 comments

Tested this on the latest master and dev branches.

Steps to reproduce:

  1. Compile this program with MSVC - normal flags e.g. (cl -Zi -Od test.c)
#include <stdio.h>
#include <stdint.h>
#include <windows.h>

DWORD WINAPI thread_func(VOID *param) {
    while(TRUE) {
        int lol = 3;
    }
}

int main(void) {
    DWORD thread_id = 0;
    HANDLE thread_handle = CreateThread(0, 0, thread_func, 0, 0, &thread_id);
    
    return 0;
}

  1. Put a breakpoint on line "int lol = 3;"
  2. Hold down the Restart debugging key (Ctrl+Shift+F5) for 30 seconds (or longer). Eventually you will get the following error message:
[Window Title]
Fatal Exception

[Content]
A fatal exception (code 0xc0000005) occurred. The process is terminating.

Press Ctrl+C to copy this text to clipboard, then create a new issue in
https://github.com/EpicGames/raddebugger/issues

Call stack:
0. [0x7ff71df054db] demon_run +507, demon_core.c line 289
1. [0x7ff71df2c0ef] ctrl_thread__next_demon_event +2991, ctrl_core.c line 1730
5. [0x7ff71df2d52d] ctrl_thread__launch_and_init +461, ctrl_core.c line 2069
6. [0x7ff71df2b3c2] ctrl_thread__entry_point +418, ctrl_core.c line 1544
7. [0x7ff71de977f8] w32_thread_base +56, os_core_win32.c line 173
8. [0x7ffa28077344] KERNEL32
9. [0x7ffa29b226b1] ntdll

edit: looks like this in remedy when I attach to the crashed process:
image

This line decrements run_ctrls.run_entity_count when it is zero. For some reason the "ctrl_thread__launch_and_init" function is encountering a DEMON_EventKind_ExitProcess event after all run entities have been removed.

I see you added a check for "run_ctrls.run_entity_count". I think this crash is just one symptom of a greater issue. Holding (Ctrl+Shift+F5) to restart the debugged process in quick succession eventually somehow leads to the current instance of process not being restarted but new instances being created. See the Scheduler panel here and also the crazy breakpoint hit graphic. I guess the hit breakpoint somehow has a role to play in this as it operates as expected when you don't have any breakpoints set.

image