os.read_le[u64]()! crashing on -prod on Alpine Linux (musl)

[tankf33der]

trafficstars

Describe the bug

Code works on v run burger.v but -prod crashing this way:

$ v -prod burger.v
$ ./burger
signal 11: segmentation fault
backtrace_symbols is missing => printing backtraces is not available.
Some libc implementations like musl simply do not provide it.
$

Reproduction Steps

import os

fn main () {
    mut f   := os.open("/dev/urandom")!
    a       := f.read_le[u64]()!
    println(a)
    f.close()
}

Expected Behavior

print u64 number.

Current Behavior

Crashing on -prod.

Possible Solution

No response

Additional Information/Context

No response

V version

V 0.4.9 b60966c

Environment details (OS name and version, etc.)

|V full version      |V 0.4.9 515d78d.b60966c
|:-------------------|:-------------------
|OS                  |linux, N/A
|Processor           |8 cpus, 64bit, little endian, 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
|Memory              |9.38GB/15.37GB
|                    |
|V executable        |/home/mpech/v/v
|V last modified time|2025-03-05 18:34:18
|                    |
|V home dir          |OK, value: /home/mpech/v
|VMODULES            |OK, value: /home/mpech/.vmodules
|VTMP                |OK, value: /tmp/v_1000
|Current working dir |OK, value: /home/mpech/v
|                    |
|Git version         |git version 2.47.2
|V git status        |weekly.2025.10-17-gb60966cd
|.git/config present |true
|                    |
|cc version          |cc (Alpine 14.2.0) 14.2.0
|gcc version         |gcc (Alpine 14.2.0) 14.2.0
|clang version       |Alpine clang version 19.1.4
|tcc version         |tcc version 0.9.27 mob:d3e940c (x86_64 Linux)
|tcc git status      |thirdparty-linuxmusl-amd64 a3e24da2
|emcc version        |N/A
|glibc version       |Error: musl libc (x86_64)
Version 1.2.5
Dynamic Program Loader
Usage: /lib/ld-musl-x86_64.so.1 [options] [--] pathname

[!NOTE] You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote. Other reactions and those to comments will not be taken into account.

[huly-for-github[bot]]

Connected to Huly®: V_0.6-22275

[tankf33der]

Reading not into a variable, but into an array by index works without a crash.

        mut seed := []u32{len: 1}
        seed[0] = file.read_le[u32]()!
        println(seed)

crashing:

        mut seed := []u32{len: 1}
        seed << file.read_le[u32]()!
        println(seed)

[spytheman]

Are you compiling in a docker container?

[spytheman]

Try also compiling with -cc clang -prod and -cc gcc -prod .

Another combination to try is compiling with -cc gcc -prod -cflags -fno-inline-small-functions .

[tankf33der]

Are you compiling in a docker container?

No.

[tankf33der]

Try also compiling with -cc clang -prod and -cc gcc -prod .

Another combination to try is compiling with -cc gcc -prod -cflags -fno-inline-small-functions .

o) clang can NOT compile in any combination(s). o) gcc CAN compile in but crashes.

alpine:~# v -cc clang -prod t1.v
./================== C compilation error (from clang): ==============
cc: ld-temp.o:(.text.GC_with_callee_saves_pushed+0x4a): undefined reference to `getcontext'
cc: clang: error: linker command failed with exit code 1 (use -v to see invocation)
...
cc: clang: error: linker command failed with exit code 1 (use -v to see invocation)
(note: the original output was 3 lines long; it was truncated to its first 2 lines + the last line)
===================================================================
(You can pass `-cg`, or `-show-c-output` as well, to print all the C error messages).
builder error:
==================
C error found. It should never happen, when compiling pure V code.
This is a V compiler bug, please report it using `v bug file.v`,
or goto https://github.com/vlang/v/issues/new/choose .
You can also use #help on Discord: https://discord.gg/vlang .

alpine:~# v -cc clang -prod -cflags -fno-inline-small-functions t1.v
================== C compilation error (from clang): ==============
cc: ld-temp.o:(.text.GC_with_callee_saves_pushed+0x4a): undefined reference to `getcontext'
cc: clang: error: linker command failed with exit code 1 (use -v to see invocation)
...
cc: clang: error: linker command failed with exit code 1 (use -v to see invocation)
(note: the original output was 4 lines long; it was truncated to its first 2 lines + the last line)
===================================================================
(You can pass `-cg`, or `-show-c-output` as well, to print all the C error messages).
builder error:
==================
C error found. It should never happen, when compiling pure V code.
This is a V compiler bug, please report it using `v bug file.v`,
or goto https://github.com/vlang/v/issues/new/choose .
You can also use #help on Discord: https://discord.gg/vlang .

gcc part below:

alpine:~# v -cc gcc -prod t1.v
alpine:~# ./t1
signal 11: segmentation fault
backtrace_symbols is missing => printing backtraces is not available.
Some libc implementations like musl simply do not provide it.

[spytheman]

Try doing apk add gcompat gc-dev, then retry the compilation.

[spytheman]

clang may need also installing libucontext-dev, judging by the error message (afaik getcontext is defined by that library package)

[tankf33der]

all above installed, no progress.

o) reading to variable - crash. o) reading to array - works

[spytheman]

Thanks for checking.

I am out of ideas for the moment.

[tankf33der]

adelie linux (musl) - crash void linux (libc) - crashing even if reading to array

[tankf33der]

checked alpine linux in DOCKER: o) 3.16-3.18 - ok o) problem starts from 3.19

latest production is 3.21

[tankf33der]

crashing voidlinux (libc), any crashing alpine linux HELPS adding -g

[root@void ~]# v -prod ./burger.v && ./burger 
signal 11: segmentation fault
                                                        | 0x55fbb0cffe77 | ./burger(+0x15e77) 
                                                        | 0x55fbb0cec56e | ./burger(+0x256e) 
                                                        | 0x7f2a7a7e7c4c | /usr/lib/libc.so.6(+0x29c4c) 
                                                        | 0x7f2a7a7e7d05 | /usr/lib/libc.so.6(__libc_start_main+0x85) 
                                                        | 0x55fbb0cec5f1 | ./burger(+0x25f1) 
[root@void ~]# v -prod -g ./burger.v && ./burger 
1327937122465276500
[root@void ~]# ldd ./burger
        linux-vdso.so.1 (0x00007f99a0173000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f999ff7f000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f99a0175000)
[root@void ~]# cat burger.v 
import os

fn main () {
        mut f := os.open("/dev/urandom")!

        seed := f.read_le[u64]()!

        println(seed)
        f.close()
}

[tankf33der]

fedora:rawhide - ok debian:sid - crash

[tankf33der]

amazonlinux - ok archlinux - crash

[JalonSolov]

Hmm... on Manjaro linux (desktop, no docker involved):

$ v run ./burger.v
13694760995115306507
$ v -prod run ./burger.v
Note: building an optimized binary takes much longer. It shouldn't be used with `v run`.
Use `v run` without optimization, or build an optimized binary with -prod first, then run it separately.
signal 11: segmentation fault
                                                        | 0x65088bf08f75 | /home/jalon/burger(+0x16f75) 
                                                        | 0x65088bef455e | /home/jalon/burger(+0x255e) 
                                                        | 0x7689f9c27488 | /usr/lib/libc.so.6(+0x27488) 
                                                        | 0x7689f9c2754c | /usr/lib/libc.so.6(__libc_start_main+0x8c) 
                                                        | 0x65088bef45e5 | /home/jalon/burger(+0x25e5) 
$ v -g -prod run ./burger.v
Note: building an optimized binary takes much longer. It shouldn't be used with `v run`.
Use `v run` without optimization, or build an optimized binary with -prod first, then run it separately.
11230623671502441057
$

[JalonSolov]

So -g seems to be making the difference between hitting the segfault or not...

Here it is again, compiling then running the compiled object, no run involved. Note the only difference on the 2nd time is that -g was added to the command line:

$ v -prod ./burger.v && ./burger
signal 11: segmentation fault
                                                        | 0x6294e148ef75 | ./burger(+0x16f75) 
                                                        | 0x6294e147a55e | ./burger(+0x255e) 
                                                        | 0x71b4b1500488 | /usr/lib/libc.so.6(+0x27488) 
                                                        | 0x71b4b150054c | /usr/lib/libc.so.6(__libc_start_main+0x8c) 
                                                        | 0x6294e147a5e5 | ./burger(+0x25e5) 
$ v -g -prod ./burger.v && ./burger
5582263410164645813
$

[tankf33der]

crash under GDB in ArchLinux:

[root@ea9b16f5a9b5 ~]# gdb ./burger
GNU gdb (GDB) 16.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./burger...
(No debugging symbols found in ./burger)
(gdb) run
Starting program: /root/burger 
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007f0ee5de4a61 in fread () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007f0ee5de4a61 in fread () from /usr/lib/libc.so.6
#1  0x000055cd3825ef75 in main.main ()
#2  0x000055cd3824a55e in main ()
(gdb) 

[tankf33der]

openbsd 7.6 - ok freebsd 14:

freebsd:~# ./burger
V panic: result not set (Inappropriate ioctl for device)
v hash: 2c3e278
0x2310ff <panic_result_not_set+0x8f> at /root/burger
0x236d6f <main__main+0xcf> at /root/burger
0x236f79 <main+0x49> at /root/burger
0x823b9cc3a <__libc_start1+0x12a> at /lib/libc.so.7

[tankf33der]

i did a progress:

pub fn (mut f File) read_le_mike() !u64 {
        mut serialized := u64(0)
        C.errno = 0 // needed for tcc
        println(serialized)
        check_fread(C.fread(voidptr(&serialized), 8, 1, f.cfile))!
        $if big_endian {
                return swap_bytes(serialized)
        }
        return serialized
}

if you create this NON-generic function it will work in -prod

if you remove println it will crash again in -prod

[tankf33der]

Should we add a new label based on what I found in the latest comment?

[tankf33der]

@spytheman

I did research, there is result - 0. problem in LTO with high optimization

1. only musl (!) systems affected, libc is ok.
2. gcc version doesn't matter (13 and 14)
3. tested on two distros - Alpine v3.20 and latest and Adelie latest.

How to repeat:

$ gcc --version | grep gcc
gcc (Adelie 13.3.0) 13.3.0
$ ~/v/v -o mike.c burger.v
$ gcc -O3 mike.c -lgc
3291283988160806760
$ gcc -O1 -flto mike.c -lgc
6709842535770989307
$ gcc -O3 -flto mike.c -lgc
CRASH