"Error receiving header: Header bytes missing, received 0 of 4 bytes" while starting LabVIEW with recovery option about g-cli HOT 36 CLOSED

I'm sorry that I seem to have missed this for so long. I'll try some testing on this.

Unfortunately LabVIEW doesn't allow for bypassing of the dialogs (that I have ever been able to find) so this will always cause issues.

from g-cli.

Have you managed to get any further with this? As an extra datapoint I am getting this error when running from Jenkins, but not when I run from the Command Line. I have edited the LabVIEW settings to "Do not notify of internal warnings on exit"

from g-cli.

Just saw this again myself with the recovery option. Which is the first time I've been able to recreate it.

Now I can recreate it I can try again but I doubt I can make it work - but at least handle the error condition better.

from g-cli.

I am also facing the same issue, when I build a Jenkins job that invokes a VI this error happens after some time. The VI starts executing, this error happens when copying a folder from one location to another, I have also done proper error handling. I can observe the execution never goes to error case in LabVIEW, but I get this error in Jenkins.

from g-cli.

Hi Sree,

Let me understand your case more.

So do you say, with this VI if you leave it long enough this error always occurs? Or just sometimes after a while? How long does it take to fail?

from g-cli.

Hi James,

In my case, I have a build which will call a VI through the LabVIEW-CLI.exe. When I trigger this build, the VI starts executing but when it comes to the case where I copy a folder from a custom location to the workspace location, I get the above error after a second or so. This happens everytime.

Thanks,
Sree

from g-cli.

from g-cli.

It is LabVIEW code, I restarted my system and I am not getting the error now.

from g-cli.

Hey Folks,

This issue looks strange. I have a Jenkins Server Setup for building vipm packages. I was able to build the packages well for quite a few days. Suddenly, I am facing this issue reported by the jobs on my Jenkins Server. When I went deep into this to understand the issue I figured out the issue occurs only when I try to use VIPM APIs. I have created a VI which just opens CLI, writes something to Jenkins and exits CLI. When I called this VI from my Jenkins job, I don't see the error there. But, I am not really sure why this has occurred all of a sudden and would like to understand more on how I can solve this issue. For me, restarting the PC has not solved the issue. Temporarily, I have solved this issue by uninstalling and installing the LabVIEW. I would be happy to know if there is an easy way to solve this issue.

Thanks,
Bhargavi.

from g-cli.

I should have a chance to investigate this further on Friday.

The fact that things work and this can come up occasionally makes me thing this could be a race condition with closing the connection. At the very least I'll take a close look at the error handling in this section and see if there isn't some more useful information available.

from g-cli.

Hi @JamesMc86,

That would be more helpful !!

Thanks,
Bhargavi.

from g-cli.

I still don't see a precise purpose for this but it is likely to be that the connection has dropped by the LabVIEW library without an exit command. Therefore I have:

• Improved the error handling so we get more detail on the failure.
• Disabled Nagle on the LabVIEW connection to remove buffering and see if it prevents the race condition.

I'll probably put it up as a pre-release today if you want to test it. I've made a few structural changes so want to run it for a few days to check before I mark it as release.

from g-cli.

The new version has run a few of my build successfully so if you want to try it I have it at https://github.com/JamesMc86/G-CLI/releases/tag/v2.2.0

from g-cli.

@Bhargavi-Gowri @SreeRanjani have you had a chance to attempt this with the new release to see if it has changed things for you?

from g-cli.

Hi @JamesMc86,

I didn't get a chance to try out the new code sent by you. I will try it out and get back to you.
But I had a chance to change the CLI APIs in my code to G-CLI APIs and this didn't show me the error("Error receiving header: Header bytes missing, received 0 of 4 bytes").

Thanks,
Bhargavi Gowri.

from g-cli.

Hi @JamesMc86 ,

The issue has not yet resolved after installing the new package provided by you. Currently, I get the below error. Do you have any solution for this error? Please suggest.
"Read Error
: No bytes at port. Client probably closed the connection prematurely
Since the network stream will be out of sync the application will now exit.
Forcing LabVIEW to terminate...
LabVIEW exited with code -1"

Thanks,
Bhargavi.

from g-cli.

Hi @JamesMc86 ,

I tried to reinstall LabVIEW and now if I run through command prompt, G-CLI is getting stopped when I try to run it.
I am not sure what caused this error. Please let me know if you know the reason behind this and the fix.

Thanks,
Bhargavi.

from g-cli.

HI @Bhargavi-Gowri

What do you mean that it is getting stopped? Is it crashing or hanging?

Are you able to share the LabVIEW VI you are calling so I'm able to test for this error as well?

Cheers,
James

from g-cli.

Hi @JamesMc86 ,

Currently I restarted my PC and re-installed the new G-CLI package and I get the below error.
"Connection to LabVIEW timed out!
LabVIEW exited with code -1"

Please note that when I run it from the command prompt I don't see any error. When I run from Jenkins I am seeing the above error.
So, I don't suspect the VI that I am calling as it is running fine from the Command Prompt.
Also, I have another question, are all these issues because of kill command that we use to kill LabVIEW?

Please help me in solving this James.

Thanks,
Bhargavi Gowri

from g-cli.

There are a handful of cases that could cause this:

1. LabVIEW doesn't start - do you see it launch in both cases?
2. LabVIEW starts but too slowly - perhaps getting stuck searching for VIs or toolkits. Are there any dialogs that appear? You could try setting the --timeout flag to something very high i.e. --timeout: 600000 for 10 minutes.
3. LabVIEW starts but your VI fails to connect - does it load broken? Could anything prevent connect being called?

You say you only get this when running through Jenkins. I would recommend running Jenkins as a user (even temporarily) so you can see LabVIEW launching and see if anything is causing problems when running as Jenkins.

from g-cli.

Hi @JamesMc86 ,

I have looked into the issue more. This is the same problem that I was facing before. If I call a VI which just has 'CLI Start', 'CLI Write' and 'CLI Close', I don't see any error. The moment I use VIPM API in my VI I see the below error.

Below is the VI that I have called from Jenkins.

Please let me know the solution if you have any.

Thanks,
Bhargavi Gowri.

from g-cli.

Awesome that is really helpful.

If you add -v (verbose mode) - does it show "Recieve Exit Code 0" before that error?

Also just to check - do you have a pro license for VIPM?

from g-cli.

Hi @JamesMc86 ,

I have VIPM Pro license.
I could not understand verbose mode could you please explain more on that?

Thanks,
Bhargavi Gowri.

from g-cli.

If you add a -v argument to g-cli it will print out way more information about what it is doing. So it becomes:
g-cli -v --kill --lv-ver 2019 "my.vi"

For example

from g-cli.

Hi @JamesMc86 ,

I have added '-v' and tried to run the job again. Below is the result. Please let me know if you could get any more insights from this to solve the issue.

Thanks,
BHargavi.

from g-cli.

Perfect - so here is what I see:

1. We never recieve the stop command from the VI.
2. Wen we try and check on LabVIEWs status - it throws an exception.

All signs seem to point to a LabVIEW crash of some form. How are you running Jenkins? My next step would be to run Jenkins as a user so that you can see the user interface.

The simplest way for debugging is to stop the service and run the program directly - but it depends how you have your Jenkins set up

from g-cli.

Hi @JamesMc86 ,

When I run the command from Command prompt, there are no issues. I face this issue only when I run from Jenkins. From the below image, I assume the job is started by me, but running as system. Please correct me if I am wrong.

Could you please let me know how I can run it as user?

Thanks,
Bhargavi.

from g-cli.

Hi @JamesMc86 ,

I have tried to run as user but I don't see any user interface in the PC. Below is the screenshot where I see that console shows running as user.

As I said earlier, I can see the user interface when I run through command prompt and the job runs successfully there.

Please advice in solving this.

Thanks,
Bhargavi Gowri.

from g-cli.

Hi,

You need to run the jenkins agent directly. Is it running as a service now?

If so you need to stop the service first.

The way to run it may depend on how you have installed it. If it is a separate agent it is easy - use the command given to run the agent directly.

On the server, I've just looked at mine and it looks like the exe is C:\Program Files (x86)\Jenkins\jenkins.exe so I would try running this directly (by double clicking it in windows explorer) and run the job again.

from g-cli.

Hi @JamesMc86 ,

Yes, Jenkins was running as service and the machine is the Slave Node and hence Jenkins is not installed in the machine. When I try to run the jenkins.exe file I get below error..

When I run the Jenkins Job command directly in the machine through command prompt, I see LabVIEW up but the job passes successfully in this case.

Thanks,
Bhargavi Gowri.

from g-cli.

Hi Bhargavi,

Sorry for the slow response - I've been on holiday.

So it looks like there is a seperate agent service. We may have to try a different route.

1. Stop the service.
2. On the slave - navigate to jenkins and to the slave node under Manage Jenkins -> Manage Nodes
3. Click the launch button.

Basically step 4 of https://wiki.jenkins.io/display/JENKINS/Step+by+step+guide+to+set+up+master+and+agent+machines+on+Windows

This should run it as the user instead - then try the build again.

from g-cli.

Hi @Bhargavi-Gowri

Did you solve this in the end?

from g-cli.

Hi @JamesMc86 ,

I am yet to try the steps that you have mentioned above. Temporarily, I have added few LabVIEW INI keys to suppress dialogs and I was able to build the jobs successfully. Two days ago, Jenkins again started showing me the error - "LabVIEW Connection Time out".

I am still not sure why CLI APIs are throwing these errors often. I will try the steps in a week's time and get back to you with my observations.

Thanks,
Bhargavi Gowri.

from g-cli.

Hi @JamesMc86 ,

I have tried running Jenkins in Slave node and I was able to see LabVIEW up in the PC. When I run the job, it runs the LabVIEW VI properly and once the LabVIEW VI closes I see below error from Java.

Hence I wasn't able to get much observations from running job as user.

I have given a try by removing "--kill" (Kills LabVIEW) from the command and the builds were successful as of now. But still, this again looks like a temporary fix :( I would like to understand and confirm the issue and fix it permanently.

Thanks,
Bhargavi Gowri.

from g-cli.

Removing kill will mean that LabVIEW is already open so that saves a lot of time and may be why the timeouts are better.

No idea on those jenkins errors - I've not seem them before

from g-cli.

Closing as original issue is solved.

from g-cli.