v

v copied to clipboard

Describe the bug

There is a handled segfault exception on the runtime, not sure if its intended but just in case I send it. It doesn't affect the program execution because it's handled.

` ~/s/v ❯❯❯ v --version V 0.3.3 9c511e0

~/s/v ❯❯❯ ltrace -i -e asdf ./test [0x466882] --- SIGSEGV (Segmentation fault) --- hello world! [0xffffffffffffffff] +++ exited (status 0) +++ `

Expected Behavior

don't segfault.

Current Behavior

segfaults in a controlled way.

Reproduction Steps

fn main() { println('hello world!') }

v test.v ltrace -i -e asdf ./test [0x466882] --- SIGSEGV (Segmentation fault) --- hello world! [0xffffffffffffffff] +++ exited (status 0) +++

Possible Solution

No response

Additional Information/Context

~/s/v ❯❯❯ gdb test GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git

(gdb) r Starting program: /home/sha0/soft/v/test [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault. 0x0000000000466882 in GC_find_limit_with_bound () (gdb) bt #0 0x0000000000466882 in GC_find_limit_with_bound () #1 0x000000000047273c in GC_init () #2 0x0000000000463185 in main (___argv=0x7fffffffe2a8, ___argc=1) at /tmp/v_1000/../../../../../../tmp/v_1000/test.6810973398473868652.tmp.c:17325

(gdb) list 17307 17308 #line 68 "../../../../../../home/sha0/soft/v/vlib/builtin/rune.v" 17309 if (code <= 0x7FU) { 17310 17311 #line 69 "../../../../../../home/sha0/soft/v/vlib/builtin/rune.v" 17312 return 1; 17313 } else if (code <= 0x7FFU) { 17314 17315 #line 71 "../../../../../../home/sha0/soft/v/vlib/builtin/rune.v" 17316 return 2;

(gdb) x/i $pc => 0x466882 <GC_find_limit_with_bound+197>: movsbq (%rax),%rdi

(gdb) i r rax rdi rax 0x680f00 6819584 rdi 0x2 2

(gdb) x/x $rax 0x681f00: Cannot access memory at address 0x681f00

(gdb) main info sect Exec file: `/home/sha0/soft/v/test', file type elf64-x86-64. [0] 0x00400190->0x004001ac at 0x00000190: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS [1] 0x004001b0->0x00406d68 at 0x000001b0: .dynsym ALLOC LOAD READONLY DATA HAS_CONTENTS [2] 0x00406d68->0x0040c17d at 0x00006d68: .dynstr ALLOC LOAD READONLY DATA HAS_CONTENTS [3] 0x0040c180->0x0040e37c at 0x0000c180: .hash ALLOC LOAD READONLY DATA HAS_CONTENTS [4] 0x0040e380->0x0040e3c8 at 0x0000e380: .rela.bss ALLOC LOAD READONLY DATA HAS_CONTENTS [5] 0x0040e3c8->0x0040efe0 at 0x0000e3c8: .rela.got ALLOC LOAD READONLY DATA HAS_CONTENTS [6] 0x0040efe0->0x0040f9b8 at 0x0000efe0: .rela.plt ALLOC LOAD READONLY DATA HAS_CONTENTS [7] 0x0040f9c0->0x004786e0 at 0x0000f9c0: .text ALLOC LOAD READONLY CODE HAS_CONTENTS [8] 0x004786e0->0x00478700 at 0x000786e0: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS [9] 0x00478700->0x00478704 at 0x00078700: .rodata.cst4 ALLOC LOAD READONLY DATA HAS_CONTENTS [10] 0x00478708->0x0047ceb0 at 0x00078708: .eh_frame ALLOC LOAD READONLY DATA HAS_CONTENTS [11] 0x0047ceb0->0x0047cec7 at 0x0007ceb0: .init ALLOC LOAD READONLY CODE HAS_CONTENTS [12] 0x0047cec8->0x0047ced1 at 0x0007cec8: .fini ALLOC LOAD READONLY CODE HAS_CONTENTS [13] 0x0047ced1->0x0048033e at 0x0007ced1: .rodata.str1.1 ALLOC LOAD READONLY DATA HAS_CONTENTS [14] 0x00480340->0x00480364 at 0x00080340: .rodata ALLOC LOAD READONLY DATA HAS_CONTENTS [15] 0x00480368->0x004803a8 at 0x00080368: .note.gnu.property ALLOC LOAD READONLY DATA HAS_CONTENTS [16] 0x004803a8->0x00480a48 at 0x000803a8: .plt ALLOC LOAD READONLY CODE HAS_CONTENTS [17] 0x00480a48->0x00481342 at 0x00080a48: .gnu.version ALLOC LOAD READONLY DATA HAS_CONTENTS [18] 0x00481348->0x00481468 at 0x00081348: .gnu.version_r ALLOC LOAD READONLY DATA HAS_CONTENTS [19] 0x00681470->0x00683720 at 0x00081470: .data.ro ALLOC LOAD DATA HAS_CONTENTS [20] 0x00684000->0x00684168 at 0x00084000: .data ALLOC LOAD DATA HAS_CONTENTS [21] 0x00684168->0x006b57b8 at 0x00084168: .stab ALLOC LOAD DATA HAS_CONTENTS [22] 0x006b57b8->0x006c6771 at 0x000b57b8: .stabstr ALLOC LOAD DATA HAS_CONTENTS [23] 0x006c6778->0x006c67c0 at 0x000c6778: .data.rel.local ALLOC LOAD DATA HAS_CONTENTS [24] 0x006c67c0->0x006c67e0 at 0x000c67c0: .data.rel.ro ALLOC LOAD DATA HAS_CONTENTS [25] 0x006c67e0->0x006c6820 at 0x000c67e0: .data.rel.ro.local ALLOC LOAD DATA HAS_CONTENTS [26] 0x006c6820->0x006c6b20 at 0x000c6820: .data.rel ALLOC LOAD DATA HAS_CONTENTS [27] 0x006c6b20->0x006c6b28 at 0x000c6b20: .init_array ALLOC LOAD DATA HAS_CONTENTS [28] 0x006c6b28->0x006c6cb8 at 0x000c6b28: .dynamic ALLOC LOAD DATA HAS_CONTENTS [29] 0x006c6cb8->0x006c7420 at 0x000c6cb8: .got ALLOC LOAD DATA HAS_CONTENTS [30] 0x006c7420->0x00705c08 at 0x000c7420: .bss ALLOC [31] 0x00000000->0x00000058 at 0x000e31d0: .comment READONLY HAS_CONTENTS (gdb)

V version

V 0.3.3 9c511e0

Environment details (OS name and version, etc.)

Baremetal Debian 11 64bits with i3

~ ❯❯❯ cat /etc/issue Debian GNU/Linux 11 \n \l

~ ❯❯❯ uname -r 5.10.0-21-amd64

~ ❯❯❯ gcc --version gcc (Debian 10.2.1-6) 10.2.1 20210110

The 'list' command is pointing to runes object, but not sure if it's well synced with the source.

Hi; looks like V runtime sets up some SIGSEGV handlers, so I've got this working by executing handle SIGSEGV pass nostop in gdb. (random link to stackoverflow).