Unable to open trace files when profiler is built in RelWithDebInfo

[slomp]

In the current master, I saved a large trace to a file, and later when I tried to reopen it, I got the following:

I noticed this behavior on Windows/Intel.

[wolfpld]

What's the hex dump of first 4 bytes?

[slomp]

74 72 FD 50

[wolfpld]

That looks to be garbled uncompressed data stream (TracyWorker.cpp:584). Can you check if any of the initial data blocks (FileRead::GetNextDataBlock()) contains the expected header (FileHeader)?

[slomp]

Sure, I'll try to get a debug build later to check.

I forgot to mention that I used Zstd with compression level 3, and concurrency 4.
With the non-Zstd modes, the trace file opens as expected.

[slomp]

Update: it works when I build profiler in the Debug configuration.
It's probably some uninitialized variable somewhere. I'll try to find it.

[slomp]

ZSTD_decompressStream() returns code 0xff...ffec (-20) which reads: "Frame requires too much memory for decoding"

[slomp]

Bizarre... The error only occurs in RelWithDebInfo builds...
Debug and Release work just fine.
Maybe ZSTD has problems when it gets built with that configuration?

[wolfpld]

Hmm... There is a similar problem with emscripten, where some traces fail to load when set as initial, but load correctly when another trace is loaded first and then closed. One of the ways this can manifest itself is runaway memory consumption. This is probably related.

[slomp]

Yeah, I'll try to step through the ZSTD_decompressStream again later.

(I just tried opening a non-zstd trace file first, close it, and then open the zstd trace file, and it also fails.)

[slomp]

I also believe this is a Windows-only thing (could be MSVC related, even).
(I don't recall having trouble with Zstd trace files in RelWithDebInfo on Mac and Linux, but I'll double-check later.)

[jkriegshauser]

Just came here to report this as we're also running into it (on 11.1)