PDAL allocates all RAM with invalid LAS file

[phma]

Describe the bug
I created a LAS file with some code that wasn't working right yet and tried to open it with CloudCompare. It grabbed all the RAM it could and was killed. Because of an uninitialized variable, nVariableLength had a floating-point number in it instead of zero.

I submitted a bug report to CloudCompare, but was told that the bug is in PDAL. Daniel Girardeau-Montaut provided this code to fix the bug:

if (!in.good())
{
        throw LasHeader::error("End of file reached (file seems corrupted)");
}

I have submitted a pull request with the corrupt file as a test case.

Trying nonzero values in nExtendedVariableLength did not result in grabbing all RAM. PDAL threw bad_alloc to CloudCompare.
System/installation information:
Please provide information on your PDAL version (pdal --version) and system (e.g., uname -a or ver).

Linux mooncat 5.4.0-7634-generic #38~1596560323~20.04~7719dbd-Ubuntu SMP Tue Aug 4 19:12:34 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

pdal 2.0.1 (git-version: Release)

[abellgithub]

The file you submitted isn't a valid LAS file. Are you just asking for an error message instead of the current behavior?

[phma]

I'm asking that the library throw an error, at least if an app tries to read the variable-length records. It would also be good to add a test to check that it throws an error.

I ran pdal info garbage_nVariableLength.las, and the same thing happened as with CloudCompare: It grabbed all the RAM, and the kernel killed it. There's no way a 15 kB file should do that, unless it's a pathological file passed to a decompression program.

[abellgithub]

The complaint here is that a bad LAS file doesn't always throw an error.

[abellgithub]

Addressed by #3237