GPUOpen-LibrariesAndSDKs / RadeonProRenderSDK

AMD Radeon™ ProRender is a powerful physically-based path traced rendering engine that enables creative professionals to produce stunningly photorealistic images.
https://gpuopen.com/radeon-prorender-suite/
Other
221 stars 47 forks source link

Segfault in rprLoadMaterialX_free #38

Closed SimonDanisch closed 1 year ago

SimonDanisch commented 2 years ago

I get this segfault from time to time:

Exception: EXCEPTION_ACCESS_VIOLATION at 0x7fff8fff1917 -- memcpy at C:\Windows\SYSTEM32\VCRUNTIME140.dll (unknown line)
memcpy at C:\Windows\SYSTEM32\VCRUNTIME140.dll (unknown line)
unknown function (ip: 00007fff3a90dc0b)
unknown function (ip: 00007fff3a90e49b)
rprLoadMaterialX_free at C:\Users\sdani\.RadeonProRender64.dll (unknown line)
rprLoadMaterialX_free at C:\Users\sdani\.RadeonProRender64.dll (unknown line)
rprContextCreateMesh at C:\Users\sdani\.RadeonProRender64.dll (unknown line)

I wouldn't be surprised if this is my fault - but I'm not actually doing anything with MaterialX, so I'm not sure what MaterialX it's trying to free when I create a new mesh.

I wanted to look at the source to see what it's doing, since then it would likely be easy to figure out what's happening, but I just realized that you only open source the headers :(

Can you point me to some likely causes of why rprContextCreateMesh would just try to free some material I haven't created?

RichardGe commented 2 years ago

Hi @SimonDanisch , yes RadeonProRender and Northstar are closed-source. Concerning your crash, I'm surprised to see rprLoadMaterialX_free called while doing a rprContextCreateMesh. I don't see case where that can happen. Can I ask you to double check that you are using the correct latest libs and dlls. I suggest you take them from master/RadeonProRender/binWin64 and master/RadeonProRender/libWin64

If you still have this issue, could you do a trace of your scene and upload it here ( or send if to my email : richard (dot) geslot (at) amd dot com ) so that I can test on my side ? doc on tracing can be found here: https://radeon-pro.github.io/RadeonProRenderDocs/en/sdk/tutorials/tracing.html

Thanks -

RichardGe commented 1 year ago

closing because no updates on that - please re-open it if you want more help.

SimonDanisch commented 1 year ago

Finally found some time to revisit this. I made an MWE repository with install instructions: https://github.com/SimonDanisch/RPRMWE.jl It also contains the traces: https://github.com/SimonDanisch/RPRMWE.jl/raw/master/rpr_trace.zip It seems to be Julia related since I can run the mwe fine with julia 1.6.7, but not with the newer versions... But I think it's just less often on 1.6.7, so I suspect the rare segfaults I see with 1.6.7 are related, since they have similar stack traces. If I find some more time, I could try to pin point the working julia versions more accurately.

There are two mwe's, one uses https://github.com/JuliaGraphics/RadeonProRender.jl and is a bit more high level, the other (rpr_mwe_basic.jl) just uses plain ccall, and could work with a local dll ( i put some comment into the mwe). It would be really helpful, what's corrupted to narrow down the segfault and therefore the julia problem at play here.

SimonDanisch commented 1 year ago

I checked the latest released julia version (1.8.5), which also segfaulted, and also opened a Julia issue: https://github.com/JuliaLang/julia/issues/48865

SimonDanisch commented 1 year ago

Ok I think we can leave this closed since it seems to be a bug in the automatically generated wrapper code, which honestly made me a bit blind for the translated types since it has been stable and used for so many projects at this point: https://github.com/JuliaInterop/Clang.jl/issues/417