Demonstrated by
crash.zip
I think it's over-allocating. On my Mac, ptxinfo just says:
opening it with a different app using the Ptex API (not actually running ptxinfo) gives me a slightly more descriptive
libc++abi: terminating due to uncaught exception of type std::length_error: vector
Abort trap: 6
This is obviously a corrupted file, and probably the partial header it contains specifies data sizes that cause an enormous allocation that is destined to fail.
In addition to, you know, not crashing on this or other corrupt input, it would be interesting to contemplate if a future version of the API might supply a call that would allow an app to get just the vital data about a ptex file in a way that was very inexpensive, bullet-proof, and only needed to read the first... is it 64 bytes for the main header? This could be helpful to apps looking to quickly inventory Ptex textures, as well as to do some kind of sanity check on it ("a billion faces with 10000 color channels? that can't be right, I'm not going to load that, it's probably dangerous").
Demonstrated by
crash.zip
I think it's over-allocating. On my Mac, ptxinfo just says:
opening it with a different app using the Ptex API (not actually running ptxinfo) gives me a slightly more descriptive
This is obviously a corrupted file, and probably the partial header it contains specifies data sizes that cause an enormous allocation that is destined to fail.
In addition to, you know, not crashing on this or other corrupt input, it would be interesting to contemplate if a future version of the API might supply a call that would allow an app to get just the vital data about a ptex file in a way that was very inexpensive, bullet-proof, and only needed to read the first... is it 64 bytes for the main header? This could be helpful to apps looking to quickly inventory Ptex textures, as well as to do some kind of sanity check on it ("a billion faces with 10000 color channels? that can't be right, I'm not going to load that, it's probably dangerous").