Compiler segfault/core dump with -debug, faulty binary produced without

[Raspberry-Jam]

Context

Operating System & Odin Version:

Odin: dev-2022-08:081e36c9 OS: Fedora Linux 35 (Workstation Edition), Linux 5.18.17-100.fc35.x86_64 CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz RAM: 15847 MiB

Expected Behavior

Produce errors during the checker stage, trigger compiler asserts, or successfully produce a working binary.

Current Behavior

With -debug: malloc(): unsorted double linked list corrupted resulting in core dump. Error message may vary, it has sometimes been smallbin double linked list corrupted, but always results in an abort and core dump.

Without -debug. compiler finishes without error, executing binary produces the following: [1] 15642 segmentation fault (core dumped) ./report

Failure Information

Crash at compile-time seems to only occur for some permutations of the minrep code, and only when -debug is present, but it's consistent. In the circumstance where it completes compilation without crashing, it seems to always produce a bad binary.

Steps to Reproduce

Minimum LoC I could find to produce this behaviour:

Generic_Struct :: struct($Args: typeid) {
    actions: [dynamic] proc(args: ^Args),

    register: proc(using gs: ^Generic_Struct(Args), action: proc(args: ^Args)),
}

_register :: proc(using gs: ^Generic_Struct($Args), action: proc(args: ^Args)) {
    append(&actions, action)
}

Test_Args :: struct {}

main :: proc() {
    gs := Generic_Struct(Test_Args) { register = _register }
}

Compiler crashes seem to occur surrounding the usage of append(), but only under specific circumstances. Using the following main proc will produce a similar error as above:

main :: proc() {
    my_action :: proc(args: ^Test_Args) {
        fmt.println("Test")
    }
    gs := Generic_Struct(Test_Args) { register = _register }
    gs->register(my_action)
}

However, when my_action() is defined globally, the error does not occur:

my_action :: proc(args: ^Test_Args) {
    fmt.println("Test")
}

main :: proc() {
    gs := Generic_Struct(Test_Args) { register = _register }
    gs->register(my_action)
}

The resulting binary still causes a segfault however. The append() call itself does not actually need to be reachable to cause the compiler crash, it just has to exist within the register() virtual proc. It has also caused compiler crashes when only present in the main() proc, although I have been unable to reproduce this behaviour.

[Kelimion]

Minimal example:

• Reproduction on Windows: -- odin run . seems to work fine. It builds and runs. Created .exe doesn't crash under debug. -- odin run . -debug seems to also work fine. It builds and runs. Created .exe doesn't crash under debug.

• Reproduction on Ubuntu: -- odin run . seems to work fine. It builds and runs. Created .bin doesn't crash under debug. -- odin run . -debug fails to create .bin and errors with malloc(): unsorted double linked list corrupted.

[Kelimion]

(gdb) run build .
Starting program: /mnt/w/Odin/odin build .
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff21f3700 (LWP 1772)]
[New Thread 0x7ffff19f2700 (LWP 1773)]
[New Thread 0x7ffff11f1700 (LWP 1774)]
[New Thread 0x7ffff09f0700 (LWP 1775)]
[New Thread 0x7ffff01ef700 (LWP 1776)]
[New Thread 0x7fffef9ee700 (LWP 1777)]
[New Thread 0x7fffef1ed700 (LWP 1778)]
[New Thread 0x7fffee9ec700 (LWP 1779)]
[New Thread 0x7fffee1eb700 (LWP 1780)]
[New Thread 0x7fffed9ea700 (LWP 1781)]
[New Thread 0x7fffed1e9700 (LWP 1782)]
[New Thread 0x7fffec9e8700 (LWP 1783)]
[New Thread 0x7fffec1e7700 (LWP 1784)]
[New Thread 0x7fffeb9e6700 (LWP 1785)]
[New Thread 0x7fffeb1e5700 (LWP 1786)]
[Detaching after vfork from child process 1787]
[Thread 0x7fffec1e7700 (LWP 1784) exited]
[Thread 0x7fffeb1e5700 (LWP 1786) exited]
[Thread 0x7fffeb9e6700 (LWP 1785) exited]
[Thread 0x7fffec9e8700 (LWP 1783) exited]
[Thread 0x7fffed1e9700 (LWP 1782) exited]
[Thread 0x7fffed9ea700 (LWP 1781) exited]
[Thread 0x7fffee1eb700 (LWP 1780) exited]
[Thread 0x7fffee9ec700 (LWP 1779) exited]
[Thread 0x7fffef1ed700 (LWP 1778) exited]
[Thread 0x7fffef9ee700 (LWP 1777) exited]
[Thread 0x7ffff01ef700 (LWP 1776) exited]
[Thread 0x7ffff09f0700 (LWP 1775) exited]
[Thread 0x7ffff11f1700 (LWP 1774) exited]
[Thread 0x7ffff19f2700 (LWP 1773) exited]
[Thread 0x7ffff21f3700 (LWP 1772) exited]
[Inferior 1 (process 1771) exited normally]
(gdb) run build . -debug
Starting program: /mnt/w/Odin/odin build . -debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff21f3700 (LWP 1791)]
[New Thread 0x7ffff19f2700 (LWP 1792)]
[New Thread 0x7ffff11f1700 (LWP 1793)]
[New Thread 0x7ffff09f0700 (LWP 1794)]
[New Thread 0x7ffff01ef700 (LWP 1795)]
[New Thread 0x7fffef9ee700 (LWP 1796)]
[New Thread 0x7fffef1ed700 (LWP 1797)]
[New Thread 0x7fffee9ec700 (LWP 1798)]
[New Thread 0x7fffee1eb700 (LWP 1799)]
[New Thread 0x7fffed9ea700 (LWP 1800)]
[New Thread 0x7fffed1e9700 (LWP 1801)]
[New Thread 0x7fffec9e8700 (LWP 1802)]
[New Thread 0x7fffec1e7700 (LWP 1803)]
[New Thread 0x7fffeb9e6700 (LWP 1804)]
[New Thread 0x7fffeb1e5700 (LWP 1805)]
malloc(): unsorted double linked list corrupted

Thread 1 "odin" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff2ad6859 in __GI_abort () at abort.c:79
#2  0x00007ffff2b413ee in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff2c6b285 "%s\n")
    at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff2b4947c in malloc_printerr (str=str@entry=0x7ffff2c6dad8 "malloc(): unsorted double linked list corrupted")
    at malloc.c:5347
#4  0x00007ffff2b4c46c in _int_malloc (av=av@entry=0x7ffff2c9cb80 <main_arena>, bytes=bytes@entry=104) at malloc.c:3744
#5  0x00007ffff2b4e419 in __GI___libc_malloc (bytes=104) at malloc.c:3066
#6  0x00007ffff7d37b39 in operator new(unsigned long) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007ffff38a850f in llvm::MDNode::operator new(unsigned long, unsigned int) () from /lib/x86_64-linux-gnu/libLLVM-11.so.1
#8  0x00007ffff38294f1 in llvm::DIDerivedType::getImpl(llvm::LLVMContext&, unsigned int, llvm::MDString*, llvm::Metadata*, unsigned int, llvm::Metadata*, llvm::Metadata*, unsigned long, unsigned int, unsigned long, llvm::Optional<unsigned int>, llvm::DINode::DIFlags, llvm::Metadata*, llvm::Metadata::StorageType, bool) () from /lib/x86_64-linux-gnu/libLLVM-11.so.1
#9  0x00007ffff3818a13 in llvm::DIBuilder::createMemberType(llvm::DIScope*, llvm::StringRef, llvm::DIFile*, unsigned int, unsigned long, unsigned int, unsigned long, llvm::DINode::DIFlags, llvm::DIType*) () from /lib/x86_64-linux-gnu/libLLVM-11.so.1
#10 0x0000000000598a22 in lb_debug_complete_types (m=0x7fff99d61e58) at src/llvm_backend_debug.cpp:744
#11 0x00000000005fc120 in lb_generate_code (gen=0x7fff99d61d70) at src/llvm_backend.cpp:1804
#12 0x0000000000617768 in main (arg_count=4, arg_ptr=0x7fffffffdd48) at src/main.cpp:2852
(gdb)

[JesseRMeyer]

Is the malloc corruption only repeatable under Linux with LLVM 11?

[Beefster09]

I'm not sure if this is the same issue, but I'm getting inconsistent compiler crashes with the -debug flag and have quite a lot of parapoly structs in my project.

I haven't looked at any of the compiler code, so I'm not sure if this is helpful, but I would guess that there is a buffer overrun that happens when generating debug symbols in some circumstances, possibly related to parapoly structs.

[Beefster09]

This still appears to be an issue. Doesn't seem to be any rhyme or reason to it, and sometimes varies between windows and linux.

Only certain code permutations cause issues when generating debug builds.