Out of range exception about g-cli HOT 13 CLOSED

I'm not going to be clever - will change our packetisation to 1024 bytes and be done with it. I guess the solution on the C# side would be a slight delay from reading the size to the full stream to ensure all the packets have landed but reducing our write size just guarantees future success with the same behaviour.

Hooray for integration testing managing to dig this up again!

from g-cli.

Comment from James:

The size out of range error is that we have tried to read the wrong number of bytes from the network stream. This could be: a) LabVIEW sends a zero or negative size or b) LabVIEW sends a size that is too large or c) We have had an unclean read previously which means we read the wrong data.

With the other problems as well I am slightly inclined towards c) (a) should be impossible and the code to handle b) seems robust). Do you know if you could ever write an empty output string? I’m looking at the code and thinking that could cause a problem. Alternatively do you commonly write strings of 8992 bytes or larger?

from g-cli.

I think I’m writing too much data in one chunk - 17000 characters in this case. I go through all VI Analyzer test results and print out any VI that failed, together with the name of the test that failed. Depending on how many VIs fail, this string can become fairly long. I’ll move the CLI write function into the loop iterating through the results, that should fix the problem at hand.

from g-cli.

Comment from James:

That’s interesting. Please try the new version before making your change because it should give more information on the fault. I believed that case should be correctly handled (if you look in the write function in LabVIEW I automatically break it out to 8992 chunks which is the max size the CLI app can use at once)

from g-cli.

So the new version 1.5.1 does give a better message for this error:

C:\Multi-Runner\builds\df1e0484\0\hampel-soft\cmdRead Error
: Bad Length Read: 1548580204
Since the network stream will be out of sync the application will now exit.
LabVIEW/App exiting...
LabVIEW exited with code 0
process tracking thread finished
ERROR: Job failed: exit status 1

I'm still at a loss as to why the error occurs in the first place?

from g-cli.

Can you save the output you are trying to write to a file so I can test it and see if there is something specific to the output (email privately if you prefer?) I can generate 17000 random characters without issue and it all works.

from g-cli.

Email is on its way. Its size is 18.682 Bytes.

from g-cli.

Do you remember if this was as an exe or VI? Just seen a similar error when running code as EXE which works fine as VI

from g-cli.

Scratch that, it isn't so simple.

I've written some integration tests as a batch file (since we need some test coverage to avoid bugs if we change how we launch LV). This was showing the same failure on a large output from an EXE. However the error is sporadic. Whats the money that as soon as I try to debug it then it works!

from g-cli.

I saw that error when running the VIs in the development environment (triggered automatically on my build server). As you already know, I also couldn't reproduce the behaviour...

from g-cli.

Well, of course now I have a packet sniffer it won't crash again! Will have it automatically try for the afternoon to see if I can catch it in the act.

from g-cli.

So, here is what I have found from a packet capture. The issue is in the middle of the block from a single TCP write in LabVIEW.

Each write can contain 9000 characters. The idea being this is a multiple of a standard 1500 byte MTU (I now see that to be flawed).

When this is written the driver splits this to several 1460 byte (1500 - header?) packets. What has happened in my case is that only the first few packets are read and then it attempts to read one of these packets as a new header which is where it gets the rediculous read.

I guess the TCP read in C# is not waiting for all of the packets. The simple solution will be to split down the packet sizes in LabVIEW to below 1460 bytes. I will investigate if this is a C# issue though so we don't break it again in the future

from g-cli.

Hell to the yeah ;-)

from g-cli.