- This topic has 5 replies, 2 voices, and was last updated 5 years ago by
.
-
Posts
-
Hey,
I’m writing a program for a Ubuntu using VisualGDB. I’m using some multi threading stuff in my program. After running my program in Debug Modus with VisualGDB, Visual Studio allways hangs up after a few seconds when my program is running. It seems like the time my program needs to hang up Visual Studio depends on the number of task I’m running parallel… Because, when I disable some taks, Visual Studio doesn’t hang for a longer period of time.
How may I tackle this down?
The CPU usage of Visua Studio in the hanging state is relativly high ~50%.
The CPU usage of the program executing on the target maschine (while Visual Studio hangs) of gdb is ~50% too, the usage of my program launched from the command line on the target maschine is ~20%.
I guess gdb is doing some weird shit and so in a chained way VisualGDB too.
I was generating a new thread each few milliseconds. Doing this task synchronous solved the problem for me.
But I think it’s still a bug.
Hi,
Sorry, based on your description, it looks like the slowdown comes from gdb itself processing the thread events (that is outside VisualGDB’s control) and VisualGDB/Visual Studio processing the excessive GDB output. E.g. each time VisualGDB reports a new thread to Visual Studio, it would update multiple internal structures (and the Threads window if it’s open) and it was likely never designed for the “new thread every few milliseconds” scenario.
Although we could optimize VisualGDB to reduce its impact on the slowdown, given that this scenario is unlikely for regular debugging and that both GDB and Visual Studio contribute heavily to the slowdown, it would likely not improve the GUI responsiveness, sorry.
I’m using this https://nopaste.xyz/?76f04193b9c86ebd#QrzWidqOpbeaEvvSisiSklCik0e5L3PPfsf1WnEPUBw= timer implementation. Set the timer interval small enought (~5ms) will make Visual Studio hanging after a few seconds.
But I understand that it’s a implementaion thing and you can’t simply hotfix it.
Thank you for the reply.
In order to determine for sure whether this can be hotfixed on our side side, we would need to do a detailed profiling of this scenario on our side, however as creating new threads every 5ms doesn’t usually happen during typical debugging scenarios and as other components (i.e. GDB) also appear to be hitting the bottlenecks, we won’t be able to do the advanced investigation of this, unless it can be reproduced in a more typical debugging scenario where gdb itself is still responsive and is not using all of the CPU sending thread events (and hence likely not be able to respond to VisualGDB).
- You must be logged in to reply to this topic.