- This topic has 11 replies, 2 voices, and was last updated 3 years, 3 months ago by
.
-
Posts
-
Hi.
I’m evaluating VisualGDB and have encountered an issue. The “Synchronize sysroot” function fails, with this error:
System.Exception: Expected end of remote SysprogsSync stream, got 68157440 at i81.h.Dispose() at mr2.a(t42 a, zw e, yf b, wm f, aa c, StreamWriter d) at ib.j1(zw c, yf a, wm b) at VisualGDB.Common_GUI.WPF.SysrootSynchronizationWindow.ControllerImpl.DoRunRequest(zw rq, String specificDir)
I’m using the toolchain from raspberry-gcc8.3.0-r3.exe, but not the associated SD card image – I’m not in a position to replace the filesystem.
/boot/issue.txt contains
Raspberry Pi reference 2021-05-07 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, dcfd74d7d1fa293065ac6d565711e9ff891fe2b8, stage4
Am I just out of luck? Or is there a fix/workaround?
Thanks,
-Nick
Hi,
This error means that the remote SysprogsSync executable, that packs the remote file system, handling filters and up-to-date files, exited unexpectedly. It is likely a bug in SysprogsSync triggered by something very specific on that particular SD card image.
You can try enabling SysprogsSync logging (Tools->Options->VisualGDB->General->SSH->Log SysprogsSync Transfers) and checking the SysprogsSync.log file in the Windows sysroot directory to get an idea of what is going on, or simply disable SysprogsSync for this target via Tools->VisualGDB->SSH Host Manager.
That said, if you are using a completely different SD card image, the existing toolchain will likely not work with it, or may produce unexpected results, even if you resynchronize sysroot. If you are using a custom tool to generate the image, it might have a special mode to build a cross-toolchain as well. Even if the target cross-toolchain runs on Linux, VisualGDB can still use it via an additional Linux VM or WSL.
Hi.
Thanks for the reply.
We’re using the official RaspiOS distribution from May (raspios_armhf-2021-05-28).
Enabling the log didn’t provide any new information – the warnings were also displayed in the client. I’ll attach the file, but the last few lines are here:
\\?\C:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot\usr\include\pnglibconf.h => libpng16/pnglibconf.h(file) \\?\C:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot\usr\include\libpng => libpng16(dir) \\?\C:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot\opt\vc\bin\dtparam => dtoverlay(file) \\?\C:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot\lib => usr/lib(dir) -------------------------------------- Warnings: Unreadable symbolic link 'usr/lib/jvm/java-11-openjdk-armhf/lib/src.zip', error code 2 Unreadable symbolic link 'usr/lib/jvm/openjdk-11/src.zip', error code 2 Unreadable remote directory 'usr/lib/ssl/private', error code 13 --------------------------------------
Both /usr/lib/jvm/java-11-openjdk-armhf/lib/src.zip and /usr/lib/jvm/openjdk-11/src.zip are symlinks that ultimately resolve to non-existent files.
/usr/lib/ssl/private is a symlink to /etc/ssl/private, which has permissions “drwx–x—“.The code I build with VisualGDB seems to run without problems. Could I just update the filesystem in the local sysroot from the Pi’s file system? Or is that what SysprogsSync is trying to do?
Thanks,
-Nick
Hmm. It looks like I’m not able to upload files:
<h6>Upload Errors:</h6>- SysprogsSync.log: File not uploaded.
let me know if you’d like to see more of the log posted.
-Nick
Hi,
No problem. Due to security considerations, the forum engine we are using rejects certain types of attachments. Please try packing the log file into a .7z or a .zip file to work around it.
Either way, we have updated our toolchain to the latest 2021-05-07-raspios-buster image. The only difference from the previous toolchain release is the contents of the sysroot folder.
We could not reproduce any issues with synchronizing sysroot, so it could be an indication of network errors or SD card corruption. Either way, please consider using the latest SD card image, or disabling SysprogsSync via Tools->VisualGDB->SSH Host Manager.
Okay, here’s take two, still using the previous sysroot version. I’ll update my system and see if that helps, too.
Thanks,
-Nick
Thanks, it looks like the synchronization has completed succesfully (other than the warnings). It is hard to say what would cause the error messages, but it should be safe to ignore it, or simply disable SysprogsSync for that host.
Hi.
Unfortunately, the root file system is not actually synchronized. For example, there are numerous references in the log file to sigc++-2.0, but none of the directories or files referenced in the log are present on my local drive after sysroot synchronization completes (or fails to).
I need the libsigc++-2.0 headers and library to build my project, along with a few others.
IntelliSync also seems to have problems. If it finds a missing header file in an unrelated project, and I choose to “Ignore this directory for the current project,” it responds with an “Object reference not set to an instance of an object” error dialog.
I’ve tried reinstalling raspberry-gcc8.3.0-r4.exe from scratch, and performing a repair installation with VisualGDB-5.5r5-trial.msi, but there is no change in behavior.
I can of course manually “sync” the required headers and libraries, but that’s much less desirable than the automated solution. I’d also like to understand why parts of VisualGDB seem not to be working properly.
Here’s my setup, just in case:
- Windows 10 Pro VM (32 GB)
- Visual Studio Community 2019 (v 16.10.4)
- VisualGDB 5.5 (trial)
- Project settings
- Build machine = local computer
- Deploy executable = “different machine”
- Synchronize sysroot with = Deployment machine
- Build subsystem = MSBuild
- MSBuild settings
- Toolchain = Raspberry PI in C:\SysGCC\raspberry
- Project settings
- Raspberry 4 Compute Module (2GB RAM, 0GB eMMC) + I/O board + PICAN FD DUO dual CAN hat
- SSH connection via 1GB Ethernet
Thanks,
-Nick
No problem. Please try disabling SysprogsSync for this host via Tools->VisualGDB->SSH Host Manager. This will revert to using tar.
Hi.
Sorry, I didn’t understand earlier that disabling SysprogsSync didn’t mean disabling sync entirely.
That seems to work, thanks.
-Nick
No problem. SysprogsSync is faster and more efficient than tar or rsync, as it only downloads the mismatching files and also handles complex symbolic links correctly. However, if it doesn’t work, VisualGDB can always fall back to the legacy mechanisms.
If using tar gets the folder synchronized correctly and using SysprogsSync doesn’t, we can help you get it to work as well, as long as you can provide more details. I.e.:
- Specific files that got synchronized with tar and did not get synchronized with SysprogsSync.
- A relevant SysprogsSync.log file so that we could recheck whether they were read correctly.
- Any relevant details about these files (e.g. they are inside another mounted volume or have special access rights).
- You must be logged in to reply to this topic.