-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Crashes during debugging when pausing in VS2022/.NET9 #110552
Comments
Tagging subscribers to this area: @tommcdon |
I'm happy to investigate this further locally if someone can give me tips on how to troubleshoot it. I'm kind of stumped because the process just goes away, I don't know how to get it into a mode where I can see what code is crashing during evaluation or where. EDIT: I tried native debugging and it's worse, there's not even a popup, just this in the log:
EDIT 2: The suggested "native-only debugging" does not seem to be an option in VS2022's UI anymore :( EDIT 3: This suggests it's related to Vector128:
In retrospect, I've had problems with the debugger displaying incorrect values for Vector128s in the past while working on this, so it might be the problem. |
Thanks for the bug report and investigation @kg! I was not able to reproduce on my machine (Intel I7), and so it is possible that it doesn't have all of the vectorization support needed to reproduce the bug. As for investigating, could you try setting a conditional breakpoint in |
Do I need to set that breakpoint in the debuggee or inside of VS? EDIT: From digging around by using a custom #include in a source server file, |
@kg - to stop on the 0xC0000409 error, we need to attach a second instance of VS to the first instance of VS debugging the app. When you F5 the app on the first instance, it will load mscordbi.dll which contains the |
Main thread stack:
I think maybe I need to disable tiered compilation to get a workable stack here... none of the other threads seem to be doing anything. EDIT: Hmm, started it with TieredCompilation set to 0 and the managed frames are still bare symbols. |
Got it:
Edit: Reproed again, another different !DumpStack trace:
|
@kg - thanks for the call stacks! The first one (from main), indicates that we were dispatching an APC. @thaystg recently produced a bug fix related to APC's here - #110533. It might be worth testing with the fix (I suggest a retail build as VS can trigger various asserts on debug builds). Note that if you try a private runtime build, please see https://aka.ms/vs/unsigned-dotnet-debugger-lib. |
@kg the 0xC0000409 is most likely a CET related issue. When the crash occurs, it would be helpful to dump the shadow stack too, it may reveal the culprit. You can use e.g. |
From the minidump I took:
|
@kg can you please dump the regular stack trace too? This doesn't seem to match the return addresses on the regular stack you've dumped in the comment #110552 (comment) above, so I assume it is a different run. |
It would be also better to use |
They match the 'another dumpstack trace' from the previous comment and are from a minidump I captured. Maybe minidumps don't work right? |
Attempting to repro again: On the second try I got a repro.
I have a minidump of this instance if you want it. |
@kg hmm, the shadow stack seems to match the real one, so that's strange. Please share the dump, I'll take a look to see if I can spot something. |
Wouldn't upload as a github attachment so here's a dropbox link. |
I can see what's wrong. The special user mode APC that we use for runtime suspension was just about to return (it restores a context to do that), but the Rip in the context that it wants to restore to doesn't match the frame below the The funceval hijack is performed in Maybe our debugger would need to register the cc: @tommcdon |
I am not sure if this is same problem, but I have noticed under .NET9 step-by-step debugging fails if any other thread throws a exception (user handled). I made a small test program and if you put the break line after the thread starting, then you would notice that sub-sequent steps would not be breaking anymore after exception thrown in the running thread.
|
Description
Since upgrading to .NET 9, I get frequent debugger crashes when pausing in both Debug and Release configurations for my dictionary container. I haven't been able to notice any particular pattern to it.
Reproduction Steps
Run the 'Benchmarks' project from https://github.com/kg/SimdDictionary/ and hit Pause in VS during the self-test period while it is testing TailCollider, then make sure the Autos or Locals tab(s) are visible in the debugger. Local evaluation will fail and the application process will collapse if VectorizedDictionary code is currently running. Pausing in Main works though. This is not 100% reproducible - setting a breakpoint in a specific spot doesn't reproduce it every time - but if I run the self test and pause repeatedly it will eventually crash while evaluating locals. It seems to happen even if the autos/locals tabs aren't visible.
Expected behavior
No application crash even if local evaluation fails.
Actual behavior
Local evaluation fails and the application crashes.
Regression?
I was able to get debugger crashes on .NET8 but it seems much much worse on 9. Could be a regression from upgrading VS, I'm not sure.
Known Workarounds
It looks like this could be related to some locals being NullRefs, so it's possible the workaround is to not use ref and Unsafe.NullRef at all, but that doesn't seem particularly reasonable.
Configuration
Visual Studio 2022 Version 17.12.3
x64 on a Ryzen 7950X
Other information
Sometimes it says evaluation failed for 'pair.Value' (but I don't have a watch on that, so what gives?)
Pair is defined like so:
The text was updated successfully, but these errors were encountered: