running VI crashes Docker container

[PeterFoerster]

Hi all,

I've run into a problem running VIs in a docker container with g-cli.

I built a docker container using Felipe's docker files. It just contains a licensed LabVIEW 2020 and g-cli, which I've added through the "Stryker method". I can run the quitlabview.vi just fine, but running my own VI (attached) crashes the container completely. On the first call, I get to "detected LabVIEW versions". When I try again it hangs for a moment and crashes immediately, without console output. On my development machine my VI works correctly.

Why might this be happening? What can I try to figure this out?

# this works
g-cli -v quitlabview.vi

# this crashes
g-cli -v Test.vi

Upon crashing, my Docker container gives this error:

time="2022-12-21T14:30:39-05:00" level=error msg="Error waiting for container: failed to shutdown container: container 1e30794dcef7c07be5a3f0da75c2563dbb67d2b24cc6fd6964c81440f7fbdb27 encountered an error during hcsshim::System::Shutdown: failure in a Windows system call: The connection with the virtual machine or container was closed. (0xc037010a): subsequent terminate failed container 1e30794dcef7c07be5a3f0da75c2563dbb67d2b24cc6fd6964c81440f7fbdb27 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The connection with the virtual machine or container was closed. (0xc037010a)"

I'm using g-cli 3.0.0-beta.1

Any pointers are appreciated.

[PeterFoerster]

I also just ran the whole thing with g-cli 2.4.0.5 and it also crashes. The only difference is that the crash happens identically for each run now. I get the output below, then the container just shuts down. I'm running g-cli from the location of the VI.

G CLI Started - Verbose Mode
Version 2.4.0.4 32-Bit
G CLI Arguments: -v Test.vi
Arguments passed to LabVIEW:
Current Version: 2020 f1, 32bit
Detected LabVIEW versions:
2020 f1, 32bit(C:\Program Files (x86)\National Instruments\LabVIEW 2020\)       
Launching Program:
C:\Program Files (x86)\National Instruments\LabVIEW 2020\LabVIEW.exe "Test.vi" -
unattended -- -p:56946
LabVIEW/App started, process ID is 3768
Waiting for connection on port 56946

[cbutcher]

On the first errors (hcsshim), I feel like one of the following might be true:

• Docker container allocation
• Guest/Host OS matching/versioning

So I'd suggest to check that you have your Docker context set to a Windows-based version (i.e. if running in Docker Desktop on Windows, that you've selected the "Switch to Windows Containers" option, or if you know what a context is separately from that, that you're passing the appropriate command line flags to use a Windows-based context).

The second bullet point refers to using Process Isolation rather than Hyper-V, but isn't the default setup (on Windows Pro - it is on Windows Server!), so again, it's likely you'd have considered this if you were using that method.

If you already have that set (I'd guess probably, or else I'm not sure if you can even get as far as you have) then check you have RAM available to allocate to the container (more likely to be a problem if you're running Docker inside a VM, assuming this isn't on an RPi or similar...).

If those both aren't the case, I'd have to search for log files and see if I've hit that exact error or not.

[PeterFoerster]

Thanks for your reply, I'll look into these. The thing that puzzles me is that the included VIs (e.g. quitlabview.vi) work and they're more complicated than mine...

I am running Docker on windows, with windows containers enabled (else, I wouldn't even be able to start it) and I'm running on Hyper-V. RAM also shouldn't be a problem. I just checked and it goes up to 1 GB before the crash, same as for quitlabview.

I also tried running docker logs after the failure, but that appears to be empty.

[PeterFoerster]

How could I debug this further? Is there any way to get more log output and get a better idea what's going on? Either from LabVIEW/g-cli or Docker? As I said, when I run docker logs on the container I get no output.

[cbutcher]

I'm not sure how you're running the container, but particularly if you're passing the G-CLI command as an entrypoint you could try instead passing Powershell for an interactive container and then running the same G-CLI command directly. It might not change much, but can sometimes help with debugging.

I'd also suggest copying your VI into the vi.lib location that the examples are in - that will rule out any problems with the VI (I mean, it looks simple, but maybe there's a bug in LV or G-CLI and it's being triggered by the lack of complexity in your VI? Some sort of race condition maybe... Just grasping at straws here though).

Assuming that isn't the case and the VI works, I think you'd then be best looking at the paths you're using, and mounting or volumes you're using (now that I write this, it seems likely given the hcsshim error?) and if placing the VI somewhere else can work.

Are you mounting the VI into the container at runtime?

Edit: I reread your earlier posts and it seems likely you're already using an interactive shell, and I'm not sure the error message has anything to do with mounting volumes. So maybe try a non-interactive shell and writing to a file or something easily checkable?

[PeterFoerster · Accepted solution]

Thanks for your help! In short: It now works.

The long version still has me slightly puzzled. I tried copying the VI over to the VI lib, but that caused the container to crash in a similar way. Again, it would have been nice to figure out why, but I didn't. None of the copy operations I tried worked, even though they worked fine on my dev machine.

I then tried copying the quitlabview.vi to my c:\app folder and that ran fine. I then went back to my "Test.vi" and looked at the differences. Two differences were that my VI used Exit with Code and a simple error handler (to force no dialog). I then removed the SEH and changed the Exit with Code to Exit With Error Cluster Code. To my surprise this VI worked fine.

I then added both SEH and Exit with Code back in and it still ran. I also downloaded my original VI from the start of this thread and it also ran. So the cynic solution is "to make it run, change it and change it back". Even copying works now.

It would be nice to understand what was wrong before, as I have literally not changed anything (I know, impossible). I'm just puzzled, but for now, this is resolved for me.