os._alloc_command_line_arguments segfaults when mixing optimization flags.

[nobodyspecial1553]

Context

• Operating System & Odin Version:

Odin: dev-2024-07:1770e3a9a  
OS: Fedora Linux 40 (KDE Plasma), Linux 6.9.7-200.fc40.x86_64  
CPU:  AMD Ryzen 5 7600X 6-Core Processor  
RAM: 79562 MiB  
Backend: LLVM 18.1.6

Current Behavior

Program segfaults when both using os.args and calling a foreign procedure from a shared object compiled with different optimization flags from the executable.

Steps to Reproduce

1. Write module with a procedure

package hellope

import "core:fmt"

@(export)
print_hellope :: proc() {
	fmt.println("Hellope!")
}

2. Write application to interface with it, call the procedure and use os.args in some way

package main

import "core:os"

foreign import hellope "hellope.so"

foreign hellope {
	print_hellope :: proc() ---
}

main :: proc() {
	_ = len(os.args)
	print_hellope()
}

3. Compile hellope with -build-mode:shared -opt:speed and main with -opt:none thereby mixing the optimizations
4. Run the program to encounter segfault

Failure Logs

Program received signal SIGSEGV, Segmentation fault.
0x00000000004011d8 in os._alloc_command_line_arguments () at Odin/core/os/os_linux.odin:1025

Return code: 139

[Kelimion]

Trying to rule something out: Does this go away if you replace fmt.println with runtime.print* in the shared library, whether on default calling convention, c or contextless?

[nobodyspecial1553]

Just to clarify, this was the original procedure I discovered this with:

@(export)
calculate_distance :: proc "contextless" (x0, y0, x1, y1: f64, radius: f64 = 6372.8) -> f64 {
	lat1, lat2: f64 = y0, y1
	lon1, lon2: f64 = x0, x1

	dlat: f64 = math.to_radians(lat2 - lat1)
	dlon: f64 = math.to_radians(lon2 - lon1)
	lat1 = math.to_radians(lat1)
	lat2 = math.to_radians(lat2)

	a: f64 = square(math.sin(dlat / 2.0)) + math.cos(lat1) * math.cos(lat2) * square(math.sin(dlon / 2.0))
	c: f64 = 2.0 * math.asin(math.sqrt(a))

	return radius * c
}

Segfaults on this too. Don't think it has anything to do with that. But I can still try if you want.

I just simplified it for the example.

[Kelimion]

No, that's fine. Interesting bug. Thanks for the find and report both.

[jasonKercher]

I stepped through this in gdb, and it looks like the context pointer gets clobbered. This appears to fix the issue:

diff --git a/base/runtime/entry_unix.odin b/base/runtime/entry_unix.odin
index 7d7252625..fa277150d 100644
--- a/base/runtime/entry_unix.odin
+++ b/base/runtime/entry_unix.odin
@@ -8,7 +8,7 @@ import "base:intrinsics"
 when ODIN_BUILD_MODE == .Dynamic {
        @(link_name="_odin_entry_point", linkage="strong", require/*, link_section=".init"*/)
        _odin_entry_point :: proc "c" () {
-               context = default_context()
+               context = #force_no_inline default_context()
                #force_no_inline _startup_runtime()
                intrinsics.__entry_point()
        }

[laytan]

Probably another amd64sysv abi issue related to #3817, #3762 and probably more issues