Segfault when calling `module.to_string`

[wyj2006]

Describe the Bug
segfault when calling module.to_string
exception occured at the end of LLVMString::drop on my machine and this does not always happen.

To Reproduce

use inkwell::builder::Builder;
use inkwell::context::Context;
use inkwell::module::Module;

struct CodeGen<'ctx> {
    context: &'ctx Context,
    module: Module<'ctx>,
    builder: Builder<'ctx>,
}

impl<'ctx> CodeGen<'ctx> {
    fn build(&self) {
        let i32_type = self.context.i32_type();
        let fn_type = i32_type.fn_type(&[], false);
        let function = self.module.add_function("main", fn_type, None);
        let basic_block = self.context.append_basic_block(function, "entry");

        self.builder.position_at_end(basic_block);

        self.builder
            .build_return(Some(&i32_type.const_int(0, false)))
            .unwrap();
    }
}

fn main() {
    let context = Context::create();
    let module = context.create_module("test");
    let codegen = CodeGen {
        context: &context,
        module,
        builder: context.create_builder(),
    };

    codegen.build();

    println!("{}", codegen.module.to_string());
}

Expected Behavior
the program should not segfault after calling module.to_string function

LLVM Version (please complete the following information):

• LLVM Version: 21.1.8
• Inkwell Branch Used: llvm21-1

Desktop (please complete the following information):

• OS: Windows11

[my4ng]

Before it segfaults, does it print the correct output? Also do you mean running the same code, it only fails sometimes but not others, or do you mean different code? Can you provide the failing output?

ATM can't reproduce on LLVM 21 Linux.

[wyj2006]

It doesn't print the correct output. But if using module.print_to_string().to_string() directly, it can print the correct output but still segfaults.
I mean some codes fails but others not.
But for the same code, it also fails sometimes.

error: process didn't exit successfully: `target\debug\test.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

this is the only output.
I also couldn't reproduce it today.

[my4ng]

Can you try Module::verify before printing, and also try to print to file instead?

[wyj2006]

They didn't work

[my4ng]

What do you mean they didn’t work? Did they fail to compile? Or did they return Err and if so whats the error

[wyj2006]

still segfaults at the end of LLVMString::drop

use inkwell::OptimizationLevel;
use inkwell::builder::Builder;
use inkwell::context::Context;
use inkwell::module::Module;
use inkwell::targets::{
    CodeModel, FileType, InitializationConfig, RelocMode, Target, TargetMachine,
};
use std::path::Path;

struct CodeGen<'ctx> {
    context: &'ctx Context,
    module: Module<'ctx>,
    builder: Builder<'ctx>,
}

impl<'ctx> CodeGen<'ctx> {
    pub fn new(context: &'ctx Context, module: Module<'ctx>) -> CodeGen<'ctx> {
        CodeGen {
            context,
            module,
            builder: context.create_builder(),
        }
    }
}

fn main() {
    Target::initialize_all(&InitializationConfig::default());
    //if comment the following line, segfault will never occur.
    let target_triple = TargetMachine::get_default_triple();

    let context = Context::create();
    let module = context.create_module("a");
    let codegen = CodeGen::new(&context, module);

    let path = Path::new("a.ll").to_path_buf();
    codegen.module.print_to_file(path).unwrap();
}

this is the new code I'm using.
(the system library libxmls.lib is built by myself from vcpkg)

[my4ng]

In the new code you pasted there is no LLVMString::drop since you are printing to a file, so where is the segfault occuring? I would suggest using lldb to step through the program and locate precisely which C API call is causing the segfault, as well as what other calls have been made before then. I suspect it might be either a malformed module (which given your build function I don't think it is), or the given LLVMString has some use-after-free or double-free stuff going on.

As a last resort, you might try downgrading your LLVM stack to an earlier 21.1.x version and see if that helps.

[ErisianArchitect]

What OS are you on? LLVM's implementation is a bit different on different OSes, and some functionality is broken on Windows.

But try calling module.verify() first, that can at least tell you if something is malformed.

[TheDan64]

Not certain its the same issue, but in the past I've seen segfaults trying to print invalid modules. Running module.verify as others said may indicate whether or not it's safe to print.

We may want to change the string printing methods to be fallible and run verify internally. Not sure if there's a cheaper option, though

[ErisianArchitect]

We may want to change the string printing methods to be fallible and run verify internally. Not sure if there's a cheaper option, though

That would probably be the best course of action, but then that introduces the problem where someone may want to call verify ahead of time to do either one thing or another after, and we wouldn't want verify to be called twice. That could slow down compilation processes. So perhaps there could be additional functions that could perform verification, then the functions that don't perform verification could be marked as unsafe.

[wyj2006]

I am using the Windows 11 and the version of llvm is 21.1.8.

use inkwell::context::Context;

fn main() {
    let context = Context::create();
    let module = context.create_module("a");

    module.verify().unwrap();
}

I found even this simple code will also segfault.
The image below is a screenshot of my debugging session.

[ErisianArchitect]

That's a null pointer dereference. I'll look into it right now.

[ErisianArchitect]

Oh, I can already see the problem.

if code == 1 && !err_str.is_null()

If either code isn't 1, or the error string is null, then it will go on to call LLVMDisposeMessage. I'm surprised this wasn't caught before.