Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Error receiving header: Header bytes missing, received 0 of 4 bytes" while starting LabVIEW with recovery option #45

Closed
kosist opened this issue Mar 19, 2018 · 36 comments

Comments

@kosist
Copy link

kosist commented Mar 19, 2018

If LabVIEW was terminated, and on the next start it asks user to recover files, and we try to launch LabVIEW by CLI command, it gives the following error:
"Error receiving header: Header bytes missing, received 0 of 4 bytes
Read Error"
And it is difficult to realize what is the problem, b/c if CLI runs from Jenkins service, then LabVIEW windows are not visible (at least, I have it somehow like this, I guess it's because of user context).

But, anyway, is it possible to force LabVIEW on start from CLI to skip recover option?

Thanks a lot in advance,
Sincerely, kosist90.

@JamesMc86
Copy link
Collaborator

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.

@MikeeeB
Copy link

MikeeeB commented Mar 5, 2019

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"

@JamesMc86
Copy link
Collaborator

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.

@SreeRanjani-Soliton
Copy link

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.

@JamesMc86
Copy link
Collaborator

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?

@SreeRanjani-Soliton
Copy link

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

@JamesMc86
Copy link
Collaborator

JamesMc86 commented Jul 22, 2019 via email

@SreeRanjani-Soliton
Copy link

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

@Bhargavi-Gowri
Copy link

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.

@JamesMc86
Copy link
Collaborator

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.

@Bhargavi-Gowri
Copy link

Hi @JamesMc86,

That would be more helpful !!

Thanks,
Bhargavi.

JamesMc86 added a commit that referenced this issue Jul 26, 2019
… indication that the client terminated the connection. Check for this for #45
@JamesMc86
Copy link
Collaborator

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.

@JamesMc86 JamesMc86 added this to the 2.2 milestone Jul 26, 2019
@JamesMc86
Copy link
Collaborator

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

@JamesMc86
Copy link
Collaborator

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

@Bhargavi-Gowri
Copy link

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.

@Bhargavi-Gowri
Copy link

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.

@Bhargavi-Gowri
Copy link

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.

@JamesMc86
Copy link
Collaborator

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

@Bhargavi-Gowri
Copy link

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

@JamesMc86
Copy link
Collaborator

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.

@Bhargavi-Gowri
Copy link

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.
Jenkins Error
Below is the VI that I have called from Jenkins.
VIPM API With G-CLI

Please let me know the solution if you have any.

Thanks,
Bhargavi Gowri.

@JamesMc86
Copy link
Collaborator

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?

@Bhargavi-Gowri
Copy link

Hi @JamesMc86 ,

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

Thanks,
Bhargavi Gowri.

@JamesMc86
Copy link
Collaborator

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

@Bhargavi-Gowri
Copy link

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.
image

Thanks,
BHargavi.

@JamesMc86
Copy link
Collaborator

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

@Bhargavi-Gowri
Copy link

Bhargavi-Gowri commented Dec 16, 2019

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.
image

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

Thanks,
Bhargavi.

@Bhargavi-Gowri
Copy link

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.
image

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.

@JamesMc86
Copy link
Collaborator

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.

@Bhargavi-Gowri
Copy link

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..
image

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.

@JamesMc86
Copy link
Collaborator

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.

@JamesMc86
Copy link
Collaborator

Hi @Bhargavi-Gowri

Did you solve this in the end?

@Bhargavi-Gowri
Copy link

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.

@Bhargavi-Gowri
Copy link

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.
image

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.

@JamesMc86
Copy link
Collaborator

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

@JamesMc86 JamesMc86 removed this from the 2.2 milestone Feb 14, 2020
@JamesMc86
Copy link
Collaborator

Closing as original issue is solved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants