"corrupted size vs. prev_size" when calling ExecutionSession::lookup()

Hi, I wrote a compiler that generate IR code and run it on the JIT, and there randomly crashed due to “corrupted size vs. prev_size” depends on the IR code generated from the source code.

Here’s how I created the JIT:




// create jit

llvm::orc::ExecutionSession ES;

llvm::orc::RTDyldObjectLinkingLayer ObjectLayer(ES,

{ return std::make_uniquellvm::SectionMemoryManager(); });

auto JTMB = llvm::orc::JITTargetMachineBuilder::detectHost();

auto DL = JTMB->getDefaultDataLayoutForTarget();

llvm::orc::IRCompileLayer CompileLayer(ES, ObjectLayer, llvm::orc::ConcurrentIRCompiler(std::move(*JTMB)));

llvm::orc::MangleAndInterner Mangle(ES, *DL);



// … large part to generate IR code


if (llvm::verifyModule(*AST::getModule(), &llvm::errs())) {

return 0;

} else {

std::cout << “Verified success\n”;


// run the generated IR code




auto symbol = llvm::cantFail(ES.lookup({&ES.getMainJITDylib()}, Mangle(“main”)));

int (*entry)() = (decltype(entry)) symbol.getAddress();

std::cout << entry() << std::endl;

and the “corrupted size vs. prev_size” will happen if the IR code is this:

; ModuleID = ‘top’
source_filename = “top”

@0 = global [3 x i32] [i32 1, i32 2, i32 3]

define i32 @main() {
%1 = alloca i32
store i32 0, i32* %1
br label %2

; :2: ; preds = %0
%3 = load i32, i32* %1
ret i32 %3

I put this IR code to lli, and it works fine.

So any idea why I get “corrupted size vs. prev_size” when calling calling ExecutionSession::lookup()?

Hi Yafei

What JIT backend do you use in lli? The default is still MCJIT!

Hello Yafei,

Could you open a bug report with the reproducer? This may expose an issue that shares the same root cause with PR35547 which gets a little bit tricky to reproduce.


HI Stefan, I’m new to llvm JIT, I think I used the ORC JIT, because I use the library orcjit in CmakeList, and the namespace of JIT is llvm::orc, any change I got MCJIT be mistake?

Hi Yuanfang, I used the apt-get install llvm-8 to get the llvm library, and I’m pretty sure this library(or libraries) is not the latest version, so is that ok I share a not up-to-date reproducer?