Bug: Shader path length exceeds kGfxConstant_NumNameLength (64) about capsaicin

[gboisse]

Thanks for taking the time to report, the program name in this case gets truncated, so there should be no overflow/crash.

An object's name (for programs, kernels, textures, etc.) is only used for making debugging easier, so resources can be easily identified like, for instance, in a Pix capture.

Under the hood, the full file path is being stored in a regular string so there is no risk of the information getting lost:
https://github.com/gboisse/gfx/blob/f06e3f2408db8e998203ab22c553ee58b4954eec/gfx.h#L1077-L1078

[Hineven]

Yes, I missed the real cause of the crash...
Seemingly the crash is caused by a problem of the gfx library. While compiling shaders, dxc_utils_->LoadFile does not set a '\0' value at the end of the shader source string indicating the termination of the source (it returns a length of the shader code instead). However, in the later dxc_compiler_->Compile function call gfx has not specified the true size of shader source code. Eventually when the shader source code string is not zero initialized the program crashes by chance.

[Hineven]

Yes, I missed the real cause of the crash... Seemingly the crash is caused by a problem of the gfx library. While compiling shaders, dxc_utils_->LoadFile does not set a '\0' value at the end of the shader source string indicating the termination of the source (it returns a length of the shader code instead). However, in the later dxc_compiler_->Compile function call gfx has not specified the true size of shader source code. Eventually when the shader source code string is not zero initialized the program crashes by chance.

oops, seems that's still not the cause. The shader source size is passed in correctly... Anyway there are chances the program crashes every time compiling the shaders on my computer. Mysterious.