- This topic has 7 replies, 2 voices, and was last updated 5 years, 7 months ago by
.
-
Posts
-
Hello, there is a way how to freeze visual studio.
1) you should add breakpoint in common inline function that used in many files
2) after start debugging visual studio gui will remain completely frozen until breakpoints-resolve is complete.
In my sample with remote server it takes 200+ seconds`[ 9563 ms] -break-insert -f Pool.h:62
[ 12122 ms] ^done,bkpt={number=”4″,type=”breakpoint”,disp=”keep”,enabled=”y”,addr=””,times=”0″,original-location=”Pool.h:62″},{number=”4.1″,enabled=”y”,addr=”0x00000000006b4965″,func=”Ring::Pool::GetPoolObjectGuarantee()”,file=”./Ring/Pool.h”,fullname=”/data/Tst/Ring/Pool.h”,line=”62″,thread-groups=[“i1″]},{number=”4.2″,enabled=”y”,addr=”0x00000000006b8525″,func=”Ring::Pool::GetPoolObjectGuarantee()”,file=”./Ring/Pool.h”,fullname=”/data/Tst/Ring/Pool.h”,line=”62″,thread-groups=[“i1″]},{number=”4.3″,enabled=”y”,addr=”0x00000000006bec5f”,func=”Ring::Pool::GetPoolObjectGuarantee()”,file=”./Ring/Pool.h”,fullname=”/data/Tst/Ring/Pool.h”,line=”62″,thread-groups=[“i1″]}
,…..
{number=”4.141″,enabled=”y”,addr=”0x0000000000b64645″,func=”Ring::Pool::GetPoolObjectGuarantee()”,file=”./Ring/Pool.h”,fullname=”/data/Tst/Ring/Pool.h”,line=”62″,thread-groups=[“i1″]},{number=”4.142″,enabled=”y”,addr=”0x0000000000b676dc”,func=”Ring::Pool::GetPoolObjectGuarantee()”,file=”./Ring/Pool.h”,fullname=”/data/Tst/Ring/Pool.h”,line=”62″,thread-groups=[“i1″]}
[ 12135 ms] -break-after 4 0
[ 12365 ms] ^done
[ 12365 ms] info symbol 0x6b4965
[ 12596 ms] &”info symbol 0x6b4965\n”
[ 12596 ms] ~”_ZN5Sh6Common3SFL5GetLREN3LRT11LogRowLevelENS2_10LogRowTypeE + 4201 in section .text\n”
[ 12596 ms] ^done
[ 12596 ms] info line *0x6b4965
[ 12827 ms] &”info line *0x6b4965\n”
[ 12827 ms] ~”Line 62 of \”./Ring/Pool.h\” starts at address 0x6b4965 <Common::SFL::GetLR(LRT::LogRowLevel, LRT::LogRowType)+4201> and ends at 0x6b49c7 <Common::SFL::GetLR(LRT::LogRowLevel, LRT::LogRowType)+4299>.\n”
[ 12827 ms] ^done
………..
[ 80215 ms] info line *0x938002
[ 80444 ms] &”info line *0x938002\n”
[ 80444 ms] ~”Line 263 of \”./Ring/Info.h\” starts at address 0x938002 <Ring::SystemInfo::Add(Object::BaseObject*)+130> and ends at 0x93803d <Risk::SystemInfo::AddObject(Object::BaseObject*)+189>.\n”
[ 80444 ms] ^done
…….
[ 85253 ms] -break-disable 4.1
[ 85525 ms] ^done
[ 86222 ms] -break-disable 4.2
[ 86493 ms] ^done
[ 87190 ms] -break-disable 4.3
[ 87420 ms] ^done
….
[ 220880 ms] -break-disable 4.141
[ 221143 ms] ^done
[ 221850 ms] -break-disable 4.142
[ 222109 ms] ^done`Hi,
Unfortunately this is a design limitation of Visual Studio itself. It does query the breakpoint status from the main thread, so if your gdb communication is slow and setting a breakpoint results in 142 different sub-breakpoints, each of them taking considerable time, the delays will add up and the GUI will be frozen until all of those commands complete.
As a workaround, please try running gdb locally using a gdbserver. This will greatly reduce the command latency.
We can also suggest a few other tricks to make VisualGDB regroup some of the commands, however we would need to verify your support status first. Hence please let us know the email address associated with your license key, or update your forum profile to match it.
Unfortunately this is a design limitation of Visual Studio itself.
very sad to hear it.
As a workaround, please try running gdb locally using a gdbserver.
I dont have this option in 5.2 version.
we would need to verify your support status first
I don`t have support now – that is why I am writing here and not writing to you by mail.
Sorry, we can only provide help to users with active technical support. If anyone else would like to share their workaround to a similar problem here, they are more than welcome to do so, however we will not be able to provide any further help with this until your license is renewed.
I can buy newer version – but you tell me that you cant fix this problem. I tried in virtual enviriment latest VS and latest VGDB – it works same as my old one. I always had this freeze problem when i had adding many breakpoints. But when it was frozen for 5-10 seconds i couldnt diagnose it and tell thet visualgdb is the reason of GUI freeze. Do you have mictosoft ticket for this problem? I will check is the Visual C++ for Linux Development have same problem.
Hi,
As most of the slowdown comes from the gdb debugger itself, we won’t be able to fully eliminate it, however we could try reducing it. Specifically, VisualGDB will detect when VS tries to disable all nested breakpoints (-break-disable 4.1, -break-disable 4.2, …) and will instead proactively disable all of them in one command after the first few ‘disable’ requests (-break-disable 4.1 4.2 4.3 …). You can gauge the performance improvement from this fix by running the large -break-disable command manually.
Another option would be to try running a Windows build of gdb (i.e. from a cross-compiler). This could significantly reduce the command latency and hence reduce the overall slowdown.
however we could try reducing it
Options what you talk about will decrease freeze time, but the freezing will occur. The main problem is that there is no progress bar / gdb log or something else where you can watch the process. You can’t run manual command when it happens.
Running a program locally is not a solution.
The delay ultimately happens because Visual Studio needs to run certain commands from the GUI thread (i.e. won’t continue or respond to commands until the command is completed) and those commands altogether take a lot of time due to a slow network connection. VisualGDB does show a “command in progress” window when a command doesn’t respond for 2 seconds or longer, however this doesn’t happen in this case because each of the individual 142 commands takes less time (showing and hiding the progress window 142 times would be more confusing and distracting). Sorry, the only long-term way to solve this would be to eliminate the factors that cause the delay (i.e. speed up the connection or run gdb locally).
- You must be logged in to reply to this topic.