This topic contains 12 replies, has 2 voices, and was last updated by 
-
Posts
-
Hi All and Support,
I’m using VS2019 and I’ve noticed something strange (and annoying) with the call stack. So when I hit a breakpoint and I double click a function name in the call stack, sometimes the list of functions in the call stack window disappears (not the window, just the list). It doesn’t happen every time, but will happen within a few double clicks. I have to single step to get the call stack to repopulate, but by then it might be too late.
Has anyone else experienced this issue or is peculiar to my setup?
Cheers
David
Hi,
This looks like a bug in Visual Studio itself. Based on the latest feedback we got from Microsoft, it was triggered by an unexpected combination of flags returned by our debug engine, however from a quick test on VS 16.8.2, it appears to be resolved on the VS side.
Please try updating your Visual Studio to the latest version. If the problem persists, we will try updating VisualGDB to emulate the fields VS would normally expect.
Hi Support,
Thanks for your reply. I’m on VS 16.8.3 and I have upgraded VisualGDB to 5.5R4. Unfortunately, the issue is still occurring. Please let me know if you want me to do anything.
Cheers
David
Thanks, we have retested it and indeed the problem is still there (it just doesn’t trigger when VS itself is being debugged). We have posted an update on the Visual Studio bug report and will await a reply from Microsoft. Feel free to post a comment there if the problem affects you as well.
Hi Support,
looks like Microsoft closed your report a while ago, but no resolution. I know it’s not a show stopper, but it is really annoying. Is there any chance you could get Microsoft to re-open the issue?
Cheers
David
We have provided them with an updated build that follows their instructions and still reproduces the problem on December 17th and have not heard from them since then. Please consider contacting Microsoft support directly, or posting on the bug tracking page to speed it up. We have done everything we could on this one (short from designing our own replacement Call Stack window) and the delay is on their side.
As a side note, a 100% working (although annoying) workaround would be to delete the watch expression that triggers the error, and switch back and forth between the threads via Debug->Windows->Threads. This makes the call stack reappear.
Yes, I can see your update. I’ll add a comment that the issue hasn’t been resolved yet. That might get their attention. It sounds like the fault is on the Microsoft side, so does that mean the call stack works with the latest VisualGDB (v5.5R4) but an older Visual Studio (say VS2015)?
The workaround I’ve been using is when the call stack disappears, I single step one assembler instruction and then it repopulates the call stack window.
Cheers
David
OK, we got some additional input from Microsoft and managed to add a workaround for this to the following build: VisualGDB-5.5.104.3941.msi
Hi Support,
Sorry, some how I missed your last reply.
When I download the new build, I get a file called VisualGDB-5.5.104.3970.msi. That’s not the same text in the link VisualGDB-5.5.104.3941.msi. I am assuming that is just a typo.
After installing the new build, unfortunately I still have the same problem. When clicking on a method in the stack trace, often the whole stack trace list disappears. I have to step to the next instruction in the program for the stack trace to be repopulated.
I have discovered if I double click a function in the stack trace and the list survives then that function always works. If I double click a function and the list disappears, then that will always happen when I double click that function.
Thanks for your assistance.
Cheers
David
Hi,
The temporary builds get automatically cleant up after some time, so you indeed got the latest build instead. Please try updating once again to this one: VisualGDB-5.5.104.3973.msi
If the problem persists, please try enabling the View->Other Windows->VisualGDB Diagnostics Console and reproducing the problem. Once the problem is reproduced, please attach the contents of the diagnostics console here along with a screenshot of the Help->About VisualGDB window.
Again sorry I didn’t see your last reply. I don’t know why I’m not getting email notifications when you reply.
He is the diagnostic data. I’ve zipped the trace and the screenshot.
There does seem to be an issue in the trace, but hopefully you have a better understanding of what it means 🙂
[+452] Reading disassembly stream (0/0): 447 msec
[+15] ExecuteRawCommand(x/62xb 0x8001902, d)
[+3] ExecuteFrameSensitiveCommand(-stack-list-frames, 1, -1)
[+0] ExecuteRawCommand(-stack-list-frames –thread 1, c)
[+0] Cannot accept command: another command is already running
[+0] ExecuteRawCommand(-thread-select 1, c)
[+0] Cannot accept command: another command is already running
[+0] ExecuteFrameSensitiveCommand(-stack-list-frames 0 0, 1, -1)
[+0] ExecuteRawCommand(-stack-list-frames –thread 1 0 0, c)
[+0] Cannot accept command: another command is already running
[+0] ExecuteRawCommand(-thread-select 1, c)
[+0] Cannot accept command: another command is already running
[+0] ExecuteFrameSensitiveCommand(-data-evaluate-expression “\$pc”, 1, -1)
[+0] ExecuteRawCommand(-data-evaluate-expression –thread 1 “\$pc”, c)
[+0] Cannot accept command: another command is already running
[+0] ExecuteRawCommand(-thread-select 1, c)
[+0] Cannot accept command: another command is already running
failed to query the frame list
at yu1.EnumFrameInfo
at System.Threading.SynchronizationContext.WaitHelperCheers
David
Thanks, this looks like a slightly different variation of the problem coming from the disassembly window. Please try this build: VisualGDB-5.5.104.3990.msi. If the problem persists, please attach the updated log and screenshots.
Also, in case anyone else is experiencing this, below is an explanation why it’s taking so long to pinpoint.
A recent update to Visual Studio changed the logic used by the Call Stack window so that it will sometimes try to re-query its contents while VisualGDB is already running another GDB command. This happens very rarely and intermittently, and almost never happens when a debugger is attached to the VS itself, so we have initially incorrectly concluded that VS was losing the frames reported by VisualGDB (in reality, it was sometimes re-querying them in an unsupported way that never happened with a debugger attached). We have initially updated VisualGDB to prevent VS from re-querying the frames by temporarily suspending background job processing in the main thread until the main GDB command would be completed, but it did not solve all the instances of the problem. The latest fix introduces caching instead. Now if Visual Studio queries the call stack in an unexpected way, VisualGDB will simply return the last known version of it. This may still not be a 100% solution in case VS submits a stack frame request in an unsupported context before submitting it in a regular context. As the problem is extremely intermittent and rare, it’s hard to predict whether it’s likely or not. If this happens, we will consider other workarounds as well.
Looks like you fixed the problem. Many Thanks.
You must be logged in to reply to this topic.