Infinite scan 'stat' loop in container when a layer has the same name as the parent workspaceFolder

[Paullgk]

Hello, When using the extension in a Yocto directory with the same name of one of the layer, project scan fail. For example, my parent project directory is called meta-seapath, and of my Yocto layer is also called meta-seapath. Here's the debug output of the extension:

stat: missing operand
Try 'stat --help' for more information.

98435076

2500500

2499907

2499903

2142138

Comparing container inodes: WARNING::98435076 /home/pleguendekerneizon/PROJECTS/SEAPATH/meta-seapath:98435076
Found container mount point: WARNING: -> /home/pleguendekerneizon/PROJECTS/SEAPATH/meta-seapath

Current workaround is to rename the parent directory. Thanks in advance, Paul Le Guen de Kerneizon, Savoir-faire Linux

[deribaucourt]

Thanks for this bug report!

We run a "stat" commands in a while loop to resolve mountpoints in the container and outside of it when a commandWrapper is used. If the name of a layer is the same as the workspace folder, I guess we truncate the path string too early which results in a faulty while command.

• Fix the while command to not do infinite loops on errors
• Add a timeout to protect against this kind of issues in project scanning
• Use absolute paths or another mechanism to work when workspacefolder and a layer share the same name

[Paullgk]

Update: the issue is not caused by the parent dir name. I am using a custom bitbake wrapper, which output warning such as follow:

asciidoctor: WARNING: admonition icon not found or not readable: /home/pleguendekerneizon/PROJECTS/SEAPATH/seapath_yocto/doc/icons/warning.png

Removing it fix the issue. I also had a scan passing even with this message. It might be a combination of errors?

[deribaucourt]

The regex to test the output is ^\d+$, so it would not be affected by wrapper script output like this one.

I tested using a parent dit with the name of a layer, could not reproduce the issue. Maybe it was external to our extension? Like your filesystem being slow for some reason.

I added a more aggressive timeout of 20s (was 3000s, default bitbake timeout) for this function in #323