- This topic has 14 replies, 3 voices, and was last updated 5 years, 11 months ago by
.
-
Posts
-
Hello,
I am developing some software with VisualGDB and ESP-IDF, and I experience possibly a bug (also checked it with project for STM32, happens too):
Normally, when I point cursor over some function, then Visual Studio shows popup with function declaration and block of comment above it, like on the photo below:
Hovewer, up to my observations, if the block of comment above is too long to show it fully in this popup, then IDE hangs up, VS2017 task is stressing one CPU core, user interface hangs up, tried to wait, but no response even after few minutes. I end up having to kill Visual Studio process.
FreeRTOS functions are good ones to test it out, for example hover popup from xSemaphoreGive or xEventGroupSetBits functions can freeze IDE.
Also, I have 1080 pixels height screen resolution.I am not sure if this problem might be connected with VisualGDB or with Visual Studio itself.
Have anyone else experienced this problem too?
Software versions:
- VisualGDB 5.4 preview 3
- Visual Studio 2017 Community, version 15.7.2 (on 15.7.1 it happened too, not sure about 15.6.x)
- Windows 10 (1709, 16299.371)
Best regards
Hi,
We have quickly tried reproducing this, however unfortunately could not get anything similar. Could you please try attaching another VS instance to the hanging one (ensure Managed mode is enabled) and check the call stack of the main thread when it’s hanging? If it contains anything from the VisualGDB assemblies, please let us know the exact build number (from the About VisualGDB window).
There is an issue somewhere. I was also getting hangups requiring me to use the task manager to end the VS2017 task. I’m using the same software versions on an ESP32 project (1920×1200 screen though). I’m not so sure the tooltip is the cause but it may be related. Last week I was at a point where simply opening my solution would cause the crash. I found that a 2nd 2017 instance didn’t crash, so I ended up working a day with a hung instance in the background.
This week everything has been fine??
If it hangs again I’ll check the call stack.
So it’s definitely related to the tooltip. Right after testing I was ok with vTaskDelay and posting, I crashed on xEventGroupSetBits. I think I’ve been ok so far this week because I wasn’t working near code using the FreeRTOS functions.
The call stack simply was [External Code]. Maybe I’m not setup correctly? It is debugging in Managed mode.
Edit – VisualGDB build is 2193
VisualGDB 5.4 preview 3, build number 2193
I tried to attach second VS instance to first instance of VS, then hang first instance, but in call stack I have [External Code].
When I was attaching to first instance of VS, there was information that this process was “Managed”.I turned off every plugin (except VisualGDB) that I was able to. There was only Visual Studio and VisualGDB. Problem still occured.
If this might be helpful – I was able to run profiling with list of DLLs and % use of CPU (see attachments). I can post you whole list if you want.
Additional data if somehow it might be useful:
- CPU AMD FX-8320
- Two monitors (1920×1080, 3840×1080 total resolution)
- Two graphics card (Radeon 7950 and R9 280)
- Radeon 18.2.2 software drivers
My Setup:
- Intel i7 870
- Radeon HD 4550 with windows update driver, devmgr says version 8.970.100.9001
- dual monitors (each 1920×1200)
Hi,
This might be caused by some combination of your VS version, video driver and the display resolution (that would explain why it doesn’t trigger on our side).
We could add a setting that will limit the maximum amount of lines shown in the popups if this helps. However before that, please try attaching to the VS instance again and enable the “Show external code” option in the call stack. This should show what exactly the main thread is doing when VS is hanging.
Well, for main thread call stack is not available…
Only for some threads I can see callstack, see pictures.
I have chosen all the threads where there is something with VisualGDB and made screenshots of them.
Hi,
Thanks, this looks like the hang happens outside the VisualGDB (or any other .Net-based components), which is strange as most GUI-related object in Visual Studio is based on .Net.
Please try attaching both ‘managed’ and ‘native’ modes and then recheck the main thread stack (you don’t need to attach other thread stacks as they are not related to the hang).
Ok, this time I enabled both managed and native, in attachments there is screenshot with callstack for main thread (and from profiler it actually was taking about 95% of CPU time after hang).
I noticed one interesting thing – tooltip popup showed from Intellisense (see attached pic) does not cause hang… But if I only point cursor over it, I have sure hang.
Little edit to make thing more clear:
by pointing cursor I mean over already written function call (the same case I described in first post in this topic),
pointing cursor over Intellisense list does not do anything, I can also choose elements from list using mouse and nothing wrong happens.Hi,
Thanks again for checking this. Looks like the main thread’s call stack is missing one more step – right-click on the ntdll frames (and other unnamed ones) and select “Load Symbols”. This will unwind the stack correctly and will display the meaningful information.
Based on your description, it is starting to look like a bug triggered by some combination of display drivers, resolution, etc, so it might be tricky to solve it on our side. You might be able to avoid it by setting the comment size limits via Tools->Options->Text Editor->C/C++ (VisualGDB)->Advanced->Code Completion->Max. following comment lines/Max. preceding comment lines.
Here’s that last step. If I set the Max following/proceeding comment lines to 5000, this fixes the issue (by no longer showing the popups that crash).
Hi,
Thanks for the update. The call stack looks like the main thread is waiting for some other window running on a different thread, and does not appear like anything related to VisualGDB.
If limiting the comment lines to 5000 works, VisualGDB could have been incorrectly computing some comment block sizes (we’ve never seen any comment blocks that large in the ESP-IDF codebase), although we could never reproduce this on our side. If you could nail it down to a specific place in the code that triggers the problem, we should be able to investigate it further, otherwise the workaround with limiting the line count should a viable solution.
- You must be logged in to reply to this topic.