Allocation failure on parsing of BLOSC compressed VDB data

[EmilioLaiso]

The uncompressed and zip code paths are correctly loading, the BLOSC code path results in what looks like wrong data loading / interpretation.

let num_compressed_bytes = reader.read_i64::<LittleEndian>()?;

[src\reader.rs:141] num_compressed_bytes = -1143914305352105984

Example assets:
Uncompressed: fire from https://www.openvdb.org/download/ ✅
Zip: bunny_cloud from https://www.openvdb.org/download/ ✅
BLOSC: Tornado Looping from https://jangafx.com/software/embergen/download/free-vdb-animations/ ❌

[Jasper-Bekkers]

Notice a few things:

• Upstream OpenVDB does read an i64 here: https://github.com/AcademySoftwareFoundation/openvdb/blob/9a57c7e68e5de9ecfd05a98364dcfb8063f71186/openvdb/openvdb/io/Compression.cc#L272
• Embergen has it's own writer of the OpenVDB file format that also may contain bugs.

So potentially, try reading an i32 here instead and see what happens?

[EmilioLaiso]

Nice! Thank you for the pointers! :)
Need to check if I can find a BLOSC compressed asset in the OpenVdb page, to exclude the second option

[EmilioLaiso]

Little update on this as I'm putting it on pause: reading 32 or 64 bits before reading num_compressed_bytes gets us out of this assert, but we end up failing further down the line probably due to the shifted reader pointer. Also, the asset requires MultiPass I/O so we cannot even validate it at the moment, making any attempt into solving this unverifiable.

Let's pick this up in the future (either after MultiPass I/O or when we have a BLOSC asset that doesn't require it, maybe we can make one in EmberGen) :)