Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debugger exceptions from dynamically generated code causes the debugger to pseudo hang. #106

Closed
mistymntncop opened this issue Jan 23, 2024 · 6 comments
Labels
Bug A report of unintended or broken behavior.

Comments

@mistymntncop
Copy link

If you run this code it pseudo hangs the debugger. Namely the int3 (0xCC) instruction is never caught by the debugger (no call stack, etc) and the disassembly view becomes "hung" in a forever loading loop. This will be a problem for JITted code.

#include <stdio.h>
#include <stdint.h>
#include <windows.h>

int main(void) {
    printf("1\n");
    
    VOID *code = VirtualAlloc(0, 0x1000, MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE);
    *((uint32_t*)code) = 0xCCCCCCCC;

    ((void (__fastcall *)()) code)();

    printf("2\n");
    return 0;
}
@mistymntncop mistymntncop changed the title Dynamically generated code causes the debugger to pseudo hang. Debugger exceptions from dynamically generated code causes the debugger to pseudo hang. Jan 23, 2024
@ryanfleury ryanfleury added the Bug A report of unintended or broken behavior. label Jan 23, 2024
@ryanfleury
Copy link
Collaborator

ryanfleury commented Jan 23, 2024

I'm investigating this and it looks like the debugger does catch the exception, although I do see that the call stack is not produced, and the disassembly view does not work. The exception info is displayed in the bottom left-hand corner:

image

Can you confirm this is what you see, or do you not even see this exception info at the bottom?

Just in case it matters, I am building from the top of dev.

@mistymntncop
Copy link
Author

Hey Ryan. Yes I see the same results as you, the exception is caught according to the info at the bottom (0x80000003).

@ryanfleury
Copy link
Collaborator

Got it. I've fixed a number of bugs or unsupported behavior for JIT'd code in 804a840 and abb2dd7. There is one major stumbling block for JIT'd code still, though, which is that the disassembly system/UI do not currently assume that the actual code memory will change, and thus hot-reload when the JIT'd code's memory changes, and so on. I'll let you know when that is fixed.

@ryanfleury
Copy link
Collaborator

As of 0ead1c0 (currently just on dev, will be soon merged into master, and will be present in the next release), the debugger's disassembly view has been completely ported over to a more general purpose disassembly visualization layer (e.g. that can also be used in the watch window). This gracefully supports hot-reloading of modified machine code, and so this should work much better with JIT'd code now.

@mistymntncop
Copy link
Author

mistymntncop commented May 16, 2024

Hey @ryanfleury, just letting you know JIT debugging is broken on the latest version (8901dd3). The call stack is missing. If the disassembly view has not loaded anything it will correctly disassemble the JITTed code. However if the dissasembly view already has some other code loaded it will not show the JITTed code.

Same test as before:

#include <stdio.h>
#include <stdint.h>
#include <windows.h>

int main(void) {
    printf("1\n");
    
    VOID *code = VirtualAlloc(0, 0x1000, MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE);
    *((uint32_t*)code) = 0xCCCCCCCC;

    ((void (__fastcall *)()) code)();

    printf("2\n");
    return 0;
}

@ryanfleury
Copy link
Collaborator

This should be re-fixed as of 489ae56.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A report of unintended or broken behavior.
Projects
None yet
Development

No branches or pull requests

2 participants