Possible memory corruption in GarbageCollect2Stack pass about ldc HOT 6 CLOSED

Okay, this turned out to be my own fault. In llvm/llvm-project@6255157d24e2 I turned on trivial std::pair copy constructors for FreeBSD >= 14. Which was a bad idea, in hindsight, because the ABI changes. The idea at the time was to bump the libc++ version to be able to break the ABI, but we never got to that.

Long story short, because of the mismatch a libLLVMnn.so compiled against a "new ABI" libc++ tends to crash in interesting ways, when you use it from a precompiled ldc2 executable, that was originally compiled against the "old ABI" libc++.

In DimitryAndric/freebsd-src@4c0e8f6 I reverted that, rebuilt the FreeBSD world and ports, and now lang/ldc builds just fine, at least without any crashes! I haven't extensively tested the resulting ldmd2 and ldc2, but if they are able to build the D runtime, I assume they are OK.

from ldc.

ping @alonsobsd who is maintainer of the lang/ldc port.

from ldc.

Thx for the report. AFAICT, the relevant code (in master, but shouldn't have changed significantly since v1.35) looks as harmless as it gets wrt. inserting some pointers into a stack-allocated and default-initialized llvm::SmallSet<llvm::Use *, 16> Visited. We have been using v15.0.7 as primary LLVM version for a while (incl. extensive CI coverage), but I've never seen any issues when building the little ldc-build-runtime tool.

from ldc.

Oh and our current FreeBSD CI does use the LLVM v15.0.7 port too, and its clang as C++ host compiler: https://cirrus-ci.com/task/5161765764333568

from ldc.

Yeah, the mystery here is that the devel/llvm15 port, when compiled by clang 17.0.6, does seem to work, whereas if the devel/llvm15 port is compiled by clang 18, it does not.... I just built a ldc2 binary with debug info on a FreeBSD 15-CURRENT machine with clang 17.0.6 and copied it over the the FreeBSD machine with a clang-18 compiled libLLVM15.so, and for some reason it is now allocating ~25 GiB of data in the "SmallPtrSet". :)

I'm thinking that some sort of optimization has messed up the assumptions under which such SmallPtrSets can be used, but I can't see the problem with other ports that use llvm15, so I'm still not sure whether the problem is in GarbageCollect2Stack, in llvm15, or in clang18...

from ldc.

Oh wild. I'd make sure that the same clang that was used to compile libLLVM is used as C++ host compiler for LDC too.

from ldc.