addr2line: 'v': No such file

[nkoehring]

Often, when there is an error, I get a lot of addr2line: 'v': No such file. Is that something fixable in my setup?

In case it helps, here's the output of v doctor:

V full version: V 0.4.4 a79a9cb.410bd9d
OS: linux, Linux version 6.6.13-200.fc39.x86_64 (mockbuild@72f11b2996ed4699b0f705186172808f) (gcc (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6), GNU ld version 2.40-13.fc39) #1 SMP PREEMPT_DYNAMIC Sat Jan 20 18:03:28 UTC 2024
Processor: 16 cpus, 64bit, little endian, AMD Ryzen 7 PRO 5850U with Radeon Graphics

getwd: /home/n/src/pkg/gitly
vexe: /home/n/pkg/v/v
vexe mtime: 2024-02-08 18:03:24

vroot: OK, value: /home/n/pkg/v
VMODULES: OK, value: /home/n/.vmodules
VTMP: OK, value: /tmp/v_1000

Git version: git version 2.43.0
Git vroot status: weekly.2024.06-21-g410bd9db (4 commit(s) behind V master)
.git/config present: true

CC version: cc (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6)
thirdparty/tcc status: thirdparty-linux-amd64 12f392c3

and addr2line --version:

GNU addr2line version 2.40-13.fc39

[JalonSolov]

How did you install V?

[JalonSolov]

When V compiles, it puts the output in the same directory as the source, unless you tell it to do otherwise. I would expect the parent paths to be the same.

The temp file path you are seeing from the REPL is because it's not an interpreter... V's REPL compiles your code to a temporary exe then runs it, so that's the path you're seeing.

[nkoehring]

Exactly, so things look correct. Is that error maybe happening when the build somehow fails? Is v maybe deleting (or not even saving) the output in this case?

[JalonSolov]

I'm not sure. I've never seen this problem reported before, so have no idea what's happening. All I can do at the moment is make suggestions.

[nkoehring]

What I do is to try to build the following code, which triggers a bug in V's ORM module:

module main

import db.sqlite

@[table: 'visits']
struct Visit {
        id   int    @[primary; sql: serial]
        site string
}

@[table: 'sites']
struct Site {
        hostname string  @[primary]
        owner    int
        visits   []Visit @[fkey: 'site']
}

@[table: 'users']
struct User {
        id    int    @[primary; sql: serial]
        name  string
        sites []Site @[fkey: 'owner']
}

fn init_db(path string) !sqlite.DB {
        mut db := sqlite.connect(path)!

        sql db {
                create table User
                create table Site
                create table Visit
        }!

        return db
}

Running v src/dbtest.v results in following output on my machine:

signal 11: segmentation fault
addr2line: 'v': No such file
v() [0x6cff71]
addr2line: 'v': No such file
v() [0x6cfd12]
addr2line: 'v': No such file
v() [0x482afd]
addr2line: 'v': No such file
v() [0x47ddbb]
addr2line: 'v': No such file
v() [0x4a2d48]
addr2line: 'v': No such file
v() [0x475101]
addr2line: 'v': No such file
v() [0x6c83fe]
addr2line: 'v': No such file
v() [0x602a17]
addr2line: 'v': No such file
v() [0x60660a]
addr2line: 'v': No such file
v() [0x608dba]
addr2line: 'v': No such file
v() [0x40272a]
                                                        | 0x7ff3970cd14a | /lib64/libc.so.6(+0x2814a) 
                                                        | 0x7ff3970cd20b | /lib64/libc.so.6(__libc_start_main+0x8b) 
addr2line: 'v': No such file
v() [0x402765]

[JalonSolov]

I get a failure here, but nothing about addr2line:

/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:47430: at v__ast__Scope_find: RUNTIME ERROR: invalid memory access
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:47469: by v__ast__Scope_find_var
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:11543: by v__checker__Checker_check_field_of_inserting_struct_is_uninitialized
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:11166: by v__checker__Checker_sql_stmt_line
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:11174: by v__checker__Checker_sql_stmt_line
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:11045: by v__checker__Checker_sql_stmt
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:62955: by v__checker__Checker_stmt
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:63403: by v__checker__Checker_stmts_ending_with_expression
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:63379: by v__checker__Checker_stmts
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:4835: by v__checker__Checker_fn_decl
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:62913: by v__checker__Checker_stmt
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:60965: by v__checker__Checker_check
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:61032: by v__checker__Checker_check_files
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:50880: by v__builder__Builder_middle_stages
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:50914: by v__builder__Builder_front_and_middle_stages
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:53360: by v__builder__cbuilder__gen_c
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:53343: by v__builder__cbuilder__build_c
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:53333: by v__builder__cbuilder__compile_c
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:53239: by v__builder__Builder_rebuild
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:52344: by v__builder__compile
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:53674: by main__rebuild
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:53622: by main__main
/tmp/v_1000/v2.01HP6XQK1AQ2T2CXFDNASBPEYW.tmp.c:54331: by main

[JalonSolov]

I think this needs to be entered as an issue. I also think the addr2line bit is spurious noise, specific to Fedora Code 39 (which isn't obvious in your v doctor output, but can be deduced from bits in there).

Note that the traceback I got shows that the failure is in V itself, possibly in the ORM code.