Intermittent crash in LLVM when used from OSL (Open Shading Language) in interactive use case (seemingly due to insufficient 32 bit relocation offsets?)

[ZapAndersson]

I reported this bug first as an OSL bug here: AcademySoftwareFoundation/OpenShadingLanguage#1712 but it seems the "bug" is in LLVM itself.

TL;DR - in a heavey interactive session when compiling OSL shaders while rendering high-resolution images, we sometimes, super-intermittently, seemingly randomly, end up crashing (= fatal error aborting) here:

Basically, whatever assumptions is being made of memory blocks being within 2Gb of each other, do not hold (probably cause other threads have been allocating multi-gigabyte chunks in the meantime).

This of course explains the intermittent behavior of the bug, and that it only happens while heavy things are happening concurrently in other threads (which has made it quite difficult to track down.)

Not understanding much of LLVM, but realizing that 32 bit offsets is highly likely not to be enough, as a test, I made an ugly hackaround and replaced the use of IMAGE_REL_AMD64_ADDR32NB relocations (which seems to be the 32 bit offsets) with IMAGE_REL_AMD64_ADDR64 (which looks to my eye as full 64 bit offsets?) and the problem goes away!!

But being an utter LLVM coding noob, I sincerely doubt this is the "right solution".

For the "long explanation", see the issue in the OSL GitHub linked above, including my "godawful hackaround".

What is the "right solution" here, or are we doing something fundamentally wrong somewhere?

[ZapAndersson]

This "godawful hack" does, indeed, make the problem go away. But does it make ANY sense?

[efriedma-quic]

Messing with the relocations is just going to corrupt your code. You need to fix the code generation to choose instructions that have operands with the right width.

I think JIT compilation tries to default to the large code model, which should avoid relocations like this, but maybe you're somehow setting the wrong code model, or maybe there's some code in LLVM that isn't checking the current code model correctly.

[llvmbot]

@llvm/issue-subscribers-orcjit

[efriedma-quic]

Looked briefly for what might be generating that particular relocation, and mostly what comes up is stuff related to exception-handling. So maybe not fixable by just making the fields wider; I think those datastructures actually require a 32-bit offset. So maybe you need to rearrange memory so the relevant bits are actually within 2GB.

Or maybe if you don't need exception-handling, you can disable it.

[lhames]

@ZapAndersson your hack replaces a relocation that writes a 32-bit value with one that writes a 64-bit value, so it'll be trashing the following 4 bytes everywhere. If IMAGE_REL_AMD64_ADDR32NB is only used in exception tables and you don't need those you might get away with that, but it's definitely dangerous and not a viable long-term solution.

I think the canonical Right Answer here is for LLVM to use JITLink (the new JIT linker) by default for COFF/x86-64, and for OSL to use a slab-based allocator that reserves a 2Gb chunk of address space up front. If it's a long-running shader session OSL would need to either free unused JIT'd code to stay under the 2Gb limit, or distribute JIT'd code amongst multiple JITDylibs so that each stays under its respective 2Gb limit.

Disabling or stripping out exception tables (if that's the only place this relocation comes up) is also an option, but seems more brittle to me.

@sunho Do you happen to remember where IMAGE_REL_AMD64_ADDR32NB gets used?

[lhames]

@ZapAndersson We should also check out the large code model option as @efriedma-quic suggested. If it's not the default then switching to it may be an easy fix for now.

[sunho]

Note that IMAGE_REL_AMD64_ADDR32NB relocation is only used for seh frame (i.e. for stack walking) and debugging. If you don't use the windows exception or debug info, you can just disable those relocations on the RuntimeDyLD side as hack. (only IMAGE_REL_AMD64_ADDR32NB though, disabling other relocation will indeed break the code) If you want to be correct about these, you do need to use JITLink which does guarantee the offsets to be within 32 bit. I think hacking on codegen side is incorrect even as a hack since It will modify more bytes than intended. Just comment out the line you are seeing in the first screenshot.

[ZapAndersson]

Thank you guys!

Yeah I need to be clear, I have absolutely no idea what I am doing here ;)

So can I have a bit of an "explain like I'm five" explanation of how to

a) "disable exceptions"
or
b) "choose a large code model"

To me, though, it doesn't seem like the code itself is large (it kinda isn't) but when other code in other threads are allocating huge chunks of memory (because it's rendering Godzilla stomping a skyscraper with gazillions of polygons) we happen to get allocations that are far apart?

But I have no idea whatsoever how LLVM's memory handling works, there's the cryptic (to me) comment in the code about the "The MemoryManager can make sure this is always true by forcing the memory layout to be: CodeSection < ReadOnlySection < ReadWriteSection", which sadly is greek to me.

To be clear, I didn't write this code, I know pretty much less than zero about this code, I'm just running into this bug, been stabbing at it with a glowy stick for a workaround, and need help from anyone who actually knows sometihing, so any gem of wisdom is HIGHLY APPRECIATED, and THANK YOU ALL for any insight you can give me.

[ZapAndersson]

Just comment out the line you are seeing in the first screenshot.

So are you saying that if we con't need debugging or stack walking (as far as I know, we don't) this message is pointless and won't actually break anything, so I can just comment out the fatal error itself and be on my merry way, or what are you actually telling me? (Total LLVM Noob warning, sorry).

Again, thank you for all the answers, they are just a hair over my LLVM understanding (which is zero)

[ZapAndersson]

I think I figured out where (inside OSL) the code model is picked, there is currently a commented out line that says https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/blob/main/src/liboslexec/llvm_util.cpp#L1442

//engine_builder.setCodeModel(llvm::CodeModel::Default);

...and I see no other place in OSL where it references the "CodeModel". I will poke at this with a blunt stick and see if it changes anything.