- This topic has 11 replies, 2 voices, and was last updated 7 years, 1 month ago by
.
-
Posts
-
Hi,
I’m currently using VGDB 5.2 Beta, and I’ve been running into problems with modal dialogs opening behind VS, essentially hanging it and requiring the VS task to be killed. Note that this is not specific to 5.2 Beta, I’ve been having this problem previously when using non-beta builds as well.
The problem is more likely to be encountered when switching away from VS while starting a debug session. My project is big and it takes quite a while for VS to become unblocked due to VGDB not running on background threads, so I tend to switch away to something else until VGDB decides to give me control back of VS. However very often, VGDB has opened a modal dialog behind VS which then requires me to kill VS because there is absolutely no way I have found to get the dialog to come to the front (no amount of Alt-Tab switching or other ways of cycling through open applications work).
I have actually run into the same problem with my own VS plugins, and the way I solved it was by doing this:
public class WindowWrapper : IWin32Window
{
public WindowWrapper(DTE2 dte)
{
m_hwnd = (IntPtr)dte.MainWindow.HWnd;
}public IntPtr Handle
{
get { return m_hwnd; }
}private readonly IntPtr m_hwnd;
}var package = VisualStudioPluginPackage.Instance;
var dte = package.GetService<DTE, DTE2>();dialog.ShowDialog(new WindowWrapper(dte));Hi,
Sorry about that. VisualGDB 5.2 actually does most of the preparation steps in background threads, so it should not show any dialogs during session startup. Please try updating to the final v5.2.
If it does not help, please let us know which exact dialog causes this because we are using a similar trick for most of them to avoid the problem you described.
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.
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.
Hi,
Thanks for confirming this. We have added background execution for custom shortcuts to v5.3 roadmap. We will post an update here once this feature is available.
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?).
Hi,
The Shift-F5 is actually a VS bug (if you press it before VisualGDB reports that the session is started, VS waits for 30 seconds before actually stopping). Normally if some commands are hanging, the GDB Session window should display a message about and allow aborting the session from it.
Regarding the other warning, the “suspicious Pseudo-TTY path detected: sh: tty: not found” simply means that VisualGDB could not get the name of the pseudo-tty it created (if the main method of creating it fails, it runs the ‘tty’ command). Adding ‘tty’ path to the $PATH variable on your Linux machine should completely resolve this.
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!
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.
Hi,
Thanks for confirming this. We have quickly rechecked the ‘Save host key’ dialog, but could not get it to appear behind VS.
Could you please let us know the exact steps that cause this behavior on your machine? (you can rename the %APPDATA%\VisualGDB\KnownHosts.xml file to temporarily reset the saved keys).
- You must be logged in to reply to this topic.