Forum Replies Created
-
Posts
-
Hi,
Thanks for the reply. So I added this at the start of main:
for (int i = 0; i < 100; i++) { sleep(1); };While it is in the loop and currently running, I can set a breakpoint on the sleep and it will successfully place the breakpoint and then stop in the debugger.
However, the strange thing is that if I do the same thing (while it is still looping at the same place), it fails to set a breakpoint at any other line in main. This is true for all other locations throughout the application as well. Note once again that if I set a breakpoint ahead of time at any other location in main, or anywhere else in the application, it correctly hits the breakpoints.
So it is not that something stops Ctrl-C from working, since it works when I dynamically place a breakpoint inside the loop, but nowhere else. A bit strange.
Maybe related: I noticed my path mapping is empty, however it doesn’t have any issues finding sources in all other cases, but I’m just mentioning it in case you think it could cause issues.
Just to add… If the Parallel Stacks view was open at the time when the libraries were loaded, it too will continue to show the old symbols, even if it is closed/re-opened.
Hi,
Yes I have confirmed that bt will show the updated stack after manually loading libraries with sharedlibrary.
Also, if I open the Parallel Stacks view after manually loading the libraries, it too shows the updated stacks. However, when I double-click in a frame in the Parallel Stacks view to go to that frame, the Call Stack view goes to that frame but because the Call Stack view is still using the old symbols, it doesn’t find the source code even though the Parallel Stacks view’s stacks do show the correct function names.
So either the Call Stack view (and related internal structures) need to be refreshed when VGDB detects that GDB loaded new symbols, or there needs to be a command/button somewhere that can be manually activated so that VGDB can refresh the Call Stack view. Not sure if VGDB actively tracks the output of GDB and hence can be trained to pick up on new symbols being loaded (e.g., when GDB outputs “Loaded symbols for <filename>”).
I have to add the following complication: The Python code that I need to write/debug is started indirectly by a Ruby script. This Ruby script first sets up a complex environment before running the Python script, so it would be difficult to run the Python scrip by itself. I don’t know which one of the 3 options I listed above would have the least problems with this requirement.
Here are some more dialogs that can show up behind VS:
- GDB Timeout
- Establich SSH connection
- Save Host Key
BTW I’m not sure why I get the GDB timeout dialogs so many times for things like ‘-data-evaluate-expression “sizeof(<any type here>)”‘. I almost always have to cancel that command before I can continue, after which things seem to work properly. I just let one sit for 10 minutes and it was still waiting. Any suggestions how to get rid of those?
EDIT: After disabling “Enable asynchronous GDB mode” and “GDB can receive commands while the target is running”, the timeout dialogs went away. So the only issue is the 3 dialogs that can be open behind VS.
This specific Linux build does not have the tty command (at least I could not find it). I solved the problem by creating a file /bin/tty with the following contents:
#!/bin/sh
echo $SSH_TTYI no longer get the TTY warning dialog, so thanks that did the trick!
I ran into the following…
Sometimes starting to debug seems to “hang” although VS is still responsive, so eventually I press Shift-F5. VS is then frozen for about 30 seconds, and then I get an error dialog saying something about an issue with GDB. Clicking on OK in this dialog then hangs VS for another 30 seconds or so, before it becomes responsive again.
I *think* what is happening in these cases is that the warning dialog stating “Warning: suspicious Pseudo-TTY path detected: sh: tty: not found. This can be caused by…” is displayed (see below). However these dialogs sometimes show up behind VS so I never see them in these cases. Strangely VS eventually becomes responsive again even though these dialogs are still open. I know this because at some point I used the above method of using Task Manager to switch to the hidden dialogs, and there were 8 of them stuck behind the same VS instance! I was able to close them one by one following the Task Manager trick.
As for why the warning dialog is displayed, that is a different issue so I don’t want to get too much into that in this thread since this is specific to dialogs getting stuck behind VS. Let’s just say I tried everything under the sun to get rid of that warning dialog with no luck. There is absolutely no MOTD displayed when logging in using Putty for example, so not sure why it is having this issue. I eventually had to add the following as a startup command to GDB: “-inferior-tty-set” just to get debugging to work (without that, debugging just exists with ‘^error,msg=”During startup program exited with code 1.”‘). I still get the warning dialog, but debugging works otherwise, so I just learned to live with this annoying dialog (is there a way to just disable it altogether?).
I just found another way to switch back to the hidden dialog box… If you go to Task Manager and go to the Processes tab (I’m usually on the Details tab), you can expand the VS node and the modal dialog will be listed as a child. Right-click and select “Switch to” to bring it to the front.
At least this seems like a reliable workaround for this problem.
This happened today with a long running Custom Shortcut when I switched away from VS. My shortcut runs for about 5 minutes, but I was not able to switch back to VS since the modal dialog was behind VS. The dialog did not show up under Alt-Tab either (sometimes they do, and you can switch to it that way).
So I had to force-kill VS.
EDIT: BTW it would be really nice to not block VS for the duration of the time that the shortcut runs. For instance if I forget to first switch to the Custom Shortcut Output before running it, I’m stuck for 5 minutes guess what it is doing since I can’t switch to the output view once the operation starts.
Hi,
It would be great to be able to experiment with such an extensibility API. I’m not familiar with the current API (I’m going to take a look to see what can currently be done), but would it be possible to have the thread requests go completely through this API? What I mean is currently the thread info is retrieved using multiple GDB commands. The plugin would need to have the ability to do this in one GDB command. And also be able to cache the thread info to eliminate multiple GDB commands being issued for the same thread info requests.
This is not critical though, since the stepping is now quite acceptable. However I think maybe in cases where users want to use the Threads/Parallel Stacks windows, or want to use the “Show Threads in Source” feature, the bt command could make even those have quite acceptable performance with many threads (~300 ms to get info on all threads). So it would be great if you can add this capability to the API.
Aaaarrggg!
Well, good news and bad news… The bad news is I spent half the day trying everything under the sun to track down the issue. I don’t have the option to try this out on a different system, so I tried disabling/uninstalling every one of the plugins I possibly can, uninstalling/re-installing VGDB and a bunch of other things too.
The good news is I finally found the culprit: On the Debug toolbar, you will notice a button called “Show Threads in Source”. Mine was enabled but I didn’t know this because that toolbar was hidden since I never use it. As soon as I toggled the feature off, stepping became just as fast as in VS 2010. Finally!!!
I did a search for this feature, and there is very little info about it, other than it can slow down stepping in regular VS projects. But certainly nothing that also mentions VGDB. If you don’t already mention this somewhere in your documentation, it would be good to add it since it makes a huge difference.
Even better, a VS plugin can check the state of this button, so maybe VGDB can show a warning that this will impact debugging speed if it is enabled.
I still believe you can get even better stepping speed if using GDB’s bt command. Maybe there is a reason it can’t work for VGDB, but I briefly compared the outputs of the two different approaches and it seems you should get everything you need from the bt command. Maybe it is worth checking into if you are looking for more ways to optimize VGDB.
I tried debugging my main project using VS 2010 and stepping is much faster, to the point where the delay is no longer an issue (but I still think “bt” could speed it up even more :)).
So it is something to do with VS 2015 or one or more of the plugins. Do you have suggestions on how to track down which plugin could be causing this, e.g, are you aware of any plugins that you have seen causing such issues? I might need to disable each until I find the culprit(s).
In the meantime I’ll just go back to VS 2010 for now since I have a grueling deadline… 🙁
Hi,
So I tried the above program and got the same type of output as before, see below (note I trimmed the long lines):
[ 49390 ms] -exec-next [ 49403 ms] ^running [ 49403 ms] *running,thread-id="all" [ 49502 ms] Hello, World! [ 49513 ms] *stopped,reason="end-stepping-range",frame=... [ 49565 ms] -stack-list-frames --thread 1 [ 49567 ms] ^done,stack=[frame=... [ 49568 ms] -stack-list-frames --thread 1 [ 49570 ms] ^done,stack=[frame=... [ 49570 ms] -stack-list-arguments --thread 1 1 [ 49572 ms] ^done,stack-args=[frame=... [ 49588 ms] -stack-list-frames --thread 1 [ 49590 ms] ^done,stack=[frame=... [ 49590 ms] -stack-list-arguments --thread 1 0 [ 49592 ms] ^done,stack-args=[frame={level="0",args=[name="argc",name="argv"]}] [ 49592 ms] -stack-list-frames --thread 1 [ 49594 ms] ^done,stack=[frame=... [ 49594 ms] -stack-list-arguments --thread 1 0 [ 49595 ms] ^done,stack-args=[frame={level="0",args=[name="argc",name="argv"]}] [ 49595 ms] -stack-list-frames --thread 2 [ 49598 ms] ^done,stack=[frame=... [ 49611 ms] -stack-list-arguments --thread 2 0 [ 49613 ms] ^done,stack-args=[frame={level="0",args=[]},frame={level="1",args=[]}] [ 49623 ms] -stack-list-frames --thread 2 [ 49625 ms] ^done,stack=[frame=... [ 49625 ms] -stack-list-arguments --thread 2 0 [ 49627 ms] ^done,stack-args=[frame={level="0",args=[]},frame={level="1",args=[]}]The above is from VS 2015. I have quite a few plugins enabled. So then I tried the same thing in VS 2010, which has just a few plugins installed. The output then looks like this:
[ 21909 ms] -exec-next [ 21914 ms] ^running [ 21914 ms] *running,thread-id="all" [ 22003 ms] Hello, World! [ 22022 ms] *stopped,reason="end-stepping-range",frame=... [ 22036 ms] -break-after 1 0 [ 22039 ms] ^done [ 22039 ms] -stack-list-frames --thread 1 [ 22042 ms] ^done,stack=[frame={level="0",addr="0x000000889d552252",func="main",file=... [ 22049 ms] -stack-list-arguments --thread 1 0 [ 22051 ms] ^done,stack-args=[frame={level="0",args=[name="argc",name="argv"]}]I’m not sure why there is such a difference in output. You might be right there could be a plugin causing the extra GDB calls. But if so, won’t those calls still need to go through VGDB, and hence can’t VGDB cache thread and stack related requests for each time VS breaks into the debugger?
Also, it still seems to me that “bt” (current thread only) and “thread apply all bt” (all threads) seem much faster than the multiple commands that VGDB currently use. AFAICT it gives the same information, just in a different format, and just in a single command.
Thanks for your support, much appreciated!
