VisualGDB hangs when creating new project

Sysprogs forums Forums VisualGDB VisualGDB hangs when creating new project

This topic contains 13 replies, has 2 voices, and was last updated by  jmkresse 5 days, 23 hours ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #11202

    jmkresse
    Participant

    One of the VisualGDB users here reports that VisualGDB hangs when creating a new project.

    He gets to the step labeled “New Linux Project” , and clicks on “Finish”. A pop-up shows VisualGDB doing a series of steps, and then disappears. At that point, the “New Linux Project” step is still on the screen, and VisualGDB is hung.

    Do you have any ideas on things we can try to figure out what is wrong?

    (Also is there a way to post screenshots on here?)

    Thanks!

     

    #11211

    support
    Keymaster

    Hi,

    If you are using VS2017, this could be caused by the bugs in the AddFilter() API in Visual Studio.

    We are actually experimenting with editing the .vcxproj files directly instead of using the buggy API, so feel free to try this build and let us know if it solves the problem: http://sysprogs.com/files/tmp/VisualGDB-5.3.1.1509.msi

    #11212

    jmkresse
    Participant

    Thanks! I’ll pass that along to that user.

    I don’t think he was using VS2017, though; probably VS2015. I’ll check on that.

    #11213

    support
    Keymaster

    Hi,

    If it was not VS2017, we would recommend attaching another VS instance to the hanging one and checking the call stack of the main thread. This should explain what exactly is causing the delay.

    #11214

    jmkresse
    Participant

    Ok, thanks for the quick reply!

    Would you please explain to me how to do that? I’m not that familiar with VS; most of my experience has been in embedded processors.

    #11215

    support
    Keymaster

    Hi,

    No problem. Please follow the steps below:

    1. Ensure you have exactly 1 instance of Visual Studio running
    2. Start another VS instance
    3. Select Debug->Attach to process
    4. In the process list select devenv.exe (Visual Studio) and in the “types of code to attach” select “automatic”.
    5. Click “Attach”
    6. Click Debug->Break All
    7. Open the Debug->Windows->Threads window, locate the GUI thread and double-click on it
    8. Open the Debug->Windows->Call Stack window, select all frames and copy-paste them here
    #11216

    jmkresse
    Participant

    Thanks! We’ll give that a try.

    #11219

    jmkresse
    Participant

    We tried to follow those steps, but when we got to step 7, we saw 34 threads, but didn’t see a GUI thread. Also, when we tried clicking on a thread, they all just came back with “[External Code]” in the Call Stack window.

    I have screenshots, and can attach them if you tell me how to do that.

    Thanks!

    #11222

    support
    Keymaster

    Hi,

    We have double-checked the window. The GUI thread should have the following attributes set:

    • Both Category and Name should read “Main Thread”
    • The Managed ID should be 1

    In order to get past the “external code” issue, please right-click in the Call Stack window and select “Show External Code”.

    Alternatively you can simply select Debug->Save Dump As, upload the dump file (~1GB) to dropbox and share a link so that we could investigate it on our side.

    #11234

    jmkresse
    Participant

    Thank you for that clarification.

    Here is the frame copy from the Call Stack window:

     

    #11235

    support
    Keymaster

    Hi,

    Thanks, this looks like the hang is related to VisualGDB. Could you please let us know the exact VisualGDB build (from VisualGDB.exe file properties) so that we could pinpoint this further?

    Please also try manually killing the CppEngineHost.exe process next time the hang happens. If the hang is related to the Clang IntelliSense engine, this should help.

    #11239

    jmkresse
    Participant

    Hi,

    After being able to repeat the issue at will previously, my user was not able to repeat it today. Instead, things glitched at an earlier point, but he was able to recover and work around the issue. For now, given he has a workaround, he doesn’t want to pursue this any further. If (when) that changes, I’ll get back to you.

    For what it’s worth, the version we are using here is 5.2.15.1452.

    Thanks!

    #11243

    support
    Keymaster

    Hi,

    Thanks, according to the stack trace, VisualGDB was stuck waiting for a response from the Linux machine while trying to close an SSH connection. If you run into this problem again, please try updating your SSH server or try a different network connection (e.g. this could be caused by packet loss).

    #11250

    jmkresse
    Participant

    Thanks! That explains why the issue was intermittent; I’m guessing he was hitting network congestion when he had the issue.

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.