- This topic has 2 replies, 2 voices, and was last updated 3 years, 7 months ago by
.
-
Posts
-
Hi,
I have VGDB Custom Edition V5.5R4 (2 licenses). In general it is working well for me. I do run into a few issues that I hope can be resolved. These are not major issues, but I run into them so frequently that they are quite annoying.
Issue 1
I work with a project where the source code for the main program is not available on the host being debugged. There is not enough space on it to copy it there, and network access is way too slow to make it available via mount. For all practical purposes, let’s just say the source code for the main program is not available while debugging (and I don’t need it either).What I am working on is a module that is loaded when that program is being run. The source code for that module is available on the host, and breakpoints, stepping etc all work.
The problem is that about a year ago or so, a VGDB upgrade came with the annoying new habit where it always stops in the main function with the “Frame not in module” error in the Source Not Available window. I’m very well aware that the source for the main program is not available, and I didn’t personally put a breakpoint on main. So I don’t know why I need to see that every time, and then having to explicitly tell it to run every time. It doesn’t sound like a big issue, but do it a few 100 times a day and it becomes a problem.
I do understand that VGDB is stopping in main so that it can set breakpoints that were set in other source files by me. In fact when I don’t have any breakpoints set at all, it runs without stopping in main, so this only happens when I do set breakpoints somewhere else.
Can’t VGDB detect that it wasn’t the user that set the breakpoint in main, and then just continue regardless of whether the source code for main is available or not? Or is this something that is outside of VGDB’s control?
Issue 2
Ever since the Debug Symbols feature was added (which is great BTW!), VGDB insists on switching to the GDB Session window as it lists all the modules for which it will be skipping symbol loading. I do have the Don’t Activate GDB Session Window option set to True, however it still insists every single time on switching away from the Output window, which is what I’m interested in.Not sure how related this is, but sometimes it instead switches away from the Output window to the SSH Console window at startup, and I never use the SSH Console window.
I looked through all the settings I could find to change the above 2 issues, with no luck.
Thanks in advance for your help!
Hi,
VisualGDB would stop in the main() function if the user has set one or more breakpoints elsewhere and they have not been resolved at the time of load. This prevents the program from just running through without hitting any breakpoints and gives a chance to investigate it and correct path mapping errors.
Either way, we have added an option (Tools->Options->VisualGDB->General->Debug->Stop if All Breakpoints are Pending) to disable this behavior to the following build: VisualGDB-5.6.1.4102.msi. You can also find a comprehensive list of VisualGDB settings here: https://visualgdb.com/settings/
Regarding the windows, most likely you close the GDB session or the output window at some point, instead of just leaving it in the background. Due to the way VisualGDB handles it, it needs to re-create the window when it becomes relevant, bringing it into focus. Simply keeping it open in the background should work as long as you have the automatic window activation disabled. If not, please try determining a reliable set of steps to reproduce the issue so that we could try reproducing it on our side.
Excellent, thanks for the new build! I just tried it and it solved both issues I mentioned! Looks like they were related in some way.
BTW, seeing that I have had this behavior for a long time now, I forgot that VGDB will switch to the VGDB Output window, which is actually fine now that it is working again for me. Previously it would switch to either the GDB Session or SSH Console, and stay there. I had to manually switch back to the Output window.
Regarding the windows, most likely you close the GDB session or the output window at some point, instead of just leaving it in the background. Due to the way VisualGDB handles it, it needs to re-create the window when it becomes relevant, bringing it into focus. Simply keeping it open in the background should work as long as you have the automatic window activation disabled. If not, please try determining a reliable set of steps to reproduce the issue so that we could try reproducing it on our side.
No I always left all windows open. They were all still open at the time when I started the next debugging session. This included all VGDB specific windows as well as the main Output window, and any other window that were open.
I did a quick check by disabling the new option again… It appears that after the Source Not Available window is shown, and then pressing F5 to run, VS will switch to the tab of whatever is the very last open window, instead of the VGDB Output window.
Whatever the issue in that regard, it seems to no longer occur when I set the new option to False. So thanks again for the that new option!
- You must be logged in to reply to this topic.