- This topic has 4 replies, 2 voices, and was last updated 4 years, 4 months ago by
.
-
Posts
-
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):
Executing Copy file $(ProjectDir)\..\lib\FTCJTAG\src\FTCJTAG\libftd2xx.so on local computer to /tmp/libftd2xx.so on TargetMachine... Copy file C:\tf\cmake\LinuxTargets\..\lib\FTCJTAG\src\FTCJTAG\libftd2xx.so on local computer to /tmp/libftd2xx.so on TargetMachine Object reference not set to an instance of an object. Failed to upload C:\tf\cmake\LinuxTargets\..\lib\FTCJTAG\src\FTCJTAG\libftd2xx.so
or this (from the build machine, wilvm3):
Executing Copy file $(CMakeConfigurationDir)/src/FF/FFTSequencer/libFFTSequencer.so on BuildMachine to /tmp/libFFTSequencer.so on TargetMachine... Copy file /home/dw/VisualGDB/ff/VisualGDB/Debug/src/FF/FFTSequencer/libFFTSequencer.so on wilvm3 to /tmp/libFFTSequencer.so on TargetMachine Object reference not set to an instance of an object. The '/tmp' directory on '192.168.1.46' is not writable by ''. Please double-check file permissions or try deleting it with sudo.
For a directory copy step, the failure appears as:
Executing Transfer files from $(ProjectDir)\..\src\FF\Core\Images to /tmp/Images on TargetMachine... Transfer files from C:\tf\cmake\LinuxTargets\..\src\FF\Core\Images to /tmp/Images on TargetMachine The '/tmp' directory on '192.168.1.46' is not writable by ''. Please double-check file permissions or try deleting it with sudo.
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.
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.
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.
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.
Thanks, restarting the target between synchronizations indeed reproduced the problem. We have fixed it in the following build: VisualGDB-5.5.7.3704.msi
- You must be logged in to reply to this topic.