Dear Toradex Developer Community,
in my team we are getting systematically the following error when trying to run in debug mode (F5) a C++ Torizon CMake project, which was created from template in VS Code/Torizon Extension for Colibri iMX8X.
The error was observed in the past a few times with other boards, but was not systematical as in this case. We have tried the following actions to unlock but without success:
Import again the project in the extension
Cancel docker container and image from board and retry
Delete and let extension regenerate .devcontainer, .vscode and appconfig_0
Remove and reconnect device from the extension in network mode
Clean build and rebuild application and SDK container
Reboot the board
Reload VS Code
Updated VS Code version
Tried with Torizon extension version both stable and early access
Same error on a Linux and a Windows 10 OS, two different PCs, same project
Is it the problem already known? Do you have any solution available or suggestion? I canno find a vs-code tag for the question, sorry but seems only visual-studio tag exists.
I did a quick test and created a fresh C++ CMake project. I was able to successfully debug the default hello-world app with no such issues. As a sanity check could you try this on your side as well?
If a default CMake project works, then this leads me to believe there’s some configuration issue with your specific project that is somehow causing the issue.
Could you also please provide the following information:
The version of the Torizon extension you are using
The output of the OUTPUT pane in VSCode coming from the Torizon extension
The output of the TERMINAL pane in VSCode coming from the Torizon extension
The auto-generated config.yaml file for your project so I can see how your project was configured.
Hi @jeremias.tx, thanks for the test and the answer. I confirm it was working correctly at the beginning for several days, then the issue arose (Torizon extension “Early access” v1.4.252). By accident, today happened the same on an other board, we brainstormed and troubleshooted it.
It seems related to Moses issues about rsync (similar or the same of TE-449 issue), where rsync is not able to delete a folder. In our case the folder was created by app running as root in the docker, probably in our case is due to sync filesystem from different OSs: Windows before and Linux after, where different FS support different permission or other FS features. We solved it deleting the /home/torizon/myproject folder manually as root.
Interesting, but glad you were able to resolve the issue. TIE-449 was specifically regarding python-based projects but the core issue seems similar. Where a root-owned folder/file is created, then rsync can’t remove it.
Just to understand, was this root-owned folder that was created part of the process of your application? Or was it just an unintended behavior? I’m asking so I can figure out if there’s something for us to address on the IDE side or not.
Hi @jeremias.tx , I confirm the folder was intentionally created by the application to store its own output. That application was running as root in privileged mode for development purposes (will be torizon later).
Bests,
ldvp
