Custom Shortcuts – steps fail to work sometime after loading the project

Sysprogs forums Forums VisualGDB Custom Shortcuts – steps fail to work sometime after loading the project

This topic contains 4 replies, has 2 voices, and was last updated by  support 1 month ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #28458

    wilstark
    Participant

    VisualGDB version 5.5 preview 7 build 3666. VS 2017.

    I have a CMake integration project with a custom shortcut.  The shortcut has 15 or so steps, which are mostly copying single .so (build output) files to my development target from the build machine. A couple of the steps copy directories of static/resource files to the target from my PC build machine.

    The problem is that the entire list of steps will fail at some point (seemingly after a build).  I can get it to work again if I unload/reload the VisualGDB project. Then it will work until I do another build.

    Typical error output for a copy when in the failure state looks like this (from the PC/ local computer):

    or this (from the build machine, wilvm3):

    For a directory copy step, the failure appears as:

    The /tmp directory is of course writable by all.  (Remember: this works if I reload the project and try again.)

    Any suggestions would be appreciated.

    #28459

    wilstark
    Participant

    I went through the manual SysprogsSync setup process since I was getting prompted about that – apparently with the directory deploys. After setting that up, so far no issues. Fingers crossed.  Not sure why *not* setting that up was causing this issue, though.

    #28460

    support
    Keymaster

    Hi,

    Good to know it works. We tried reproducing the issue by running different combinations of building, configuring, reloading and transferring long lists of files, however we could not trigger the behavior you described.

    Given the issue you reported in the other thread, our best guess is that some combination of SSH actions triggers some unexpected behavior in the SSH server, and VisualGDB does not fully recover from it. Unfortunately, it’s hard to pinpoint this without further diagnostic logs.

    If using SysprogsSync solves the issue, we would advise keeping it, since it’s generally much faster and more reliable than other synchronization methods.

    Either way, we added more diagnostic logging to this build: VisualGDB-5.5.7.3685.msi. If you encounter the problem again, please try enabling View->Other Windows->VisualGDB Diagnostics Console, reproduce the error and share both the diagnostic console log and the custom action log. It should help pinpoint the cause of the error.

    #28693

    wilstark
    Participant

    I have a related issue where I see the same failure, but the reproduction is different.  I installed 5.5.7.3685 (still VS2017), and enabled the diagnostics console.

    The reproduction is to load the .sln with the .vgdbcmake project. Then run the shortcut that copies files.  SysprogsSync is set up.  It works. Then, reboot the target machine. Once it comes back up. Re-run the shortcut. It fails. See attached log vgdb_dump1.txt.   I then try testing the SSH connection to my target, which works, and re-run the shortcut.  It fails in the same way.  I then unload/reload the .vgdbcmake project in my .sln, and re-run the shortcut. It works (log in vgdb_dump2.txt). That log shows some similar failures, but the shortcut reports success in the GUI and it does work

    Hopefully this can help identify why rebooting the target breaks the copying shortcut until one reloads the visual gdb project.

    Attachments:
    You must be logged in to view attached files.
    #28713

    support
    Keymaster

    Thanks, restarting the target between synchronizations indeed reproduced the problem. We have fixed it in the following build: VisualGDB-5.5.7.3704.msi

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

You must be logged in to reply to this topic.