Unable to debug using GDB or LLDB #14904

phanos-engineer · 2022-06-30T22:38:09Z

V version:0.3.0 71ff221
OS:Linux

What did you do?
I compiled a basic hello world and tried to debug it.

module main

fn main() {
	println('Hello World!')
}

I compiled it using v -g . -o myapp

then I ran gdb

gdb myapp

## then i typed run to run the app

The app runs fine on terminal

What did you expect to see?
I expected GDB or LLDB to stop at the breakpoint and show the variables in memory

What did you see instead?

I got a segfault error from the debugger SIGSEGV

Error from GDB

(gdb) run
Starting program: /test/v/myapp/myapp 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000000045ede6 in GC_find_limit_with_bound ()

Error from LLDB

(lldb) run
Process 322569 launched: '/test/v/myapp/myapp' (x86_64)
Process 322569 stopped
* thread #1, name = 'myapp', stop reason = signal SIGSEGV: invalid address (fault address: 0x6b6f00)
    frame #0: 0x000000000045ede6 myapp`GC_find_limit_with_bound + 197
myapp`GC_find_limit_with_bound:
->  0x45ede6 <+197>: movsbq (%rax), %rdi
    0x45edea <+201>: callq  0x45ebed                  ; GC_noop1
    0x45edef <+206>: jmp    0x45ed77                  ; <+86>
    0x45edf1 <+208>: movq   0x26c6c8(%rip), %rsi      ; old_segv_handler

The text was updated successfully, but these errors were encountered:

JalonSolov · 2022-07-01T00:05:20Z

You didn't create a breakpoint for it to stop on.

After your program crashes, gdb should still be running. Just use the bt command to get a backtrace, so you know where the failure occurred.

You may also have more luck using -cg instead of just -g.

phanos-engineer · 2022-07-01T13:31:27Z

I did try that but I got the same error.

breakpoint set -f myapp.v --line 4

I ran the backtrace, here is the output.

(lldb) thread backtrace
* thread #1, name = 'myapp.app', stop reason = signal SIGSEGV: invalid address (fault address: 0x700f00)
  * frame #0: 0x000000000048dea9 myapp.app`GC_find_limit_with_bound + 197
    frame #1: 0x0000000000499d63 myapp.app`GC_init + 1070
    frame #2: 0x000000000048a2d1 myapp.app`main + 64
    frame #3: 0x00007ffff7c29290 libc.so.6`___lldb_unnamed_symbol3123 + 128
    frame #4: 0x00007ffff7c2934a libc.so.6`__libc_start_main + 138
    frame #5: 0x0000000000413de5 myapp.app`_start + 37

pd-giz-dave · 2022-07-06T17:48:13Z

I'm seeing exactly the same issue (but with LLDB) with the game-of-life example:

(lldb) bt
* thread #1, name = 'life', stop reason = signal SIGSEGV: invalid address (fault address: 0x732f00)
  * frame #0: 0x00000000004ad399 life`GC_find_limit_with_bound + 197
    frame #1: 0x00000000004b9253 life`GC_init + 1070
    frame #2: 0x00000000004a9872 life`main + 64
    frame #3: 0x00007ffff7da2290 libc.so.6`___lldb_unnamed_symbol3123 + 128
    frame #4: 0x00007ffff7da234a libc.so.6`__libc_start_main + 138
    frame #5: 0x00000000004177f5 life`_start + 37

This is all happening in the V pre-amble before main__main is hit.

pd-giz-dave · 2022-07-08T12:25:40Z

I don't know if this is a clue but compiling with -cg -keepc -gc none works, whereas -g -keepc -gc none does not.

medvednikov · 2022-07-08T12:47:44Z

Will need a lot more about your OS than "Linux" :)

phanos-engineer · 2022-07-08T14:02:26Z

I use Arch BTW

Here is the info on the linux version and debugger versions.

~ [127]$ uname -a
Linux testmachine01 5.18.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 02 Jul 2022 21:03:06 +0000 x86_64 GNU/Linux


~ $ lldb -v
lldb version 14.0.6
~ $ gdb -v
GNU gdb (GDB) 12.1
Copyright (C) 2022 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.

JalonSolov · 2022-07-08T14:24:23Z

It is simpler to run v doctor. It collects all the relevant info (which is why the template for issues mentions it...).

JalonSolov · 2022-07-08T14:24:51Z

For example:

OS: linux, "Manjaro Linux"
Processor: 32 cpus, 64bit, little endian, AMD Ryzen 9 5950X 16-Core Processor
CC version: cc (GCC) 12.1.0

getwd: /home/jamie
vmodules: /home/jamie/.vmodules
vroot: /home/jamie/git/v
vexe: /home/jamie/git/v/v
vexe mtime: 2022-07-08 12:47:08
is vroot writable: true
is vmodules writable: true
V full version: V 0.3.0 a46bcf3.70890b2

Git version: git version 2.37.0
Git vroot status: 0.3-75-g70890b27
.git/config present: true
thirdparty/tcc status: thirdparty-linux-amd64 827f7452

pd-giz-dave · 2022-07-08T18:56:51Z

In my case running v doctor yields:

>> v doctor

±[●][master] OS: linux, "Manjaro Linux" Processor: 12 cpus, 64bit, little endian, Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz CC version: cc (GCC) 12.1.0 getwd: /home/dave/v/examples/game_of_life vmodules: /home/dave/.vmodules vroot: /home/dave/v vexe: /home/dave/v/v vexe mtime: 2022-07-02 12:06:55 is vroot writable: true is vmodules writable: true V full version: V 0.3.0 b5f2636 Git version: git version 2.36.1 Git vroot status: 0.3-17-gb5f2636b (58 commit(s) behind V master) .git/config present: true thirdparty/tcc status: thirdparty-linux-amd64 827f7452

…

On Fri, 8 Jul 2022 at 15:25, JalonSolov ***@***.***> wrote: For example: OS: linux, "Manjaro Linux" Processor: 32 cpus, 64bit, little endian, AMD Ryzen 9 5950X 16-Core Processor CC version: cc (GCC) 12.1.0 getwd: /home/jamie vmodules: /home/jamie/.vmodules vroot: /home/jamie/git/v vexe: /home/jamie/git/v/v vexe mtime: 2022-07-08 12:47:08 is vroot writable: true is vmodules writable: true V full version: V 0.3.0 a46bcf3.70890b2 Git version: git version 2.37.0 Git vroot status: 0.3-75-g70890b27 .git/config present: true thirdparty/tcc status: thirdparty-linux-amd64 827f7452 — Reply to this email directly, view it on GitHub <#14904 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEEESADUJHB2C3HKIGAH35DVTA237ANCNFSM52K3TJVQ> . You are receiving this because you commented.Message ID: ***@***.***>

packysauce · 2022-08-12T04:35:19Z

Chased this around a bit; sounds like it's expected, and we just need to find a way around it (Crystal's is here)

looks like libgc sets up a fault handler and just bumps into it for a "done" signal 😄, GDB and LLDB see this - they're debuggers, after all - and notify you that your program received a signal. The fact that it's SIGSEGV is irrelevant in this case (for once! 😂)

EchoPouet · 2022-09-17T12:08:25Z

I have the same issue. Ma configuration:

$ v doctor
OS: linux, Ubuntu 20.04.5 LTS (WSL 2)
Processor: 12 cpus, 64bit, little endian, AMD Ryzen 5 5600X 6-Core Processor
CC version: cc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

getwd: /mnt/c/Users/Arnaud/Developpement/popit
vmodules: /home/armour/.vmodules
vroot: /home/armour/v
vexe: /home/armour/v/v
vexe mtime: 2022-09-16 19:52:46
is vroot writable: true
is vmodules writable: true
V full version: V 0.3.1 7e69619.0992914

Git version: git version 2.25.1
Git vroot status: weekly.2022.37-20-g0992914b (5 commit(s) behind V master)
.git/config present: true
thirdparty/tcc status: thirdparty-linux-amd64 827f7452

srackham · 2022-09-20T20:28:31Z

Same issue:

OS: linux, Ubuntu 22.04.1 LTS (VM)
Processor: 8 cpus, 64bit, little endian, Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz
CC version: cc (Ubuntu 11.2.0-19ubuntu1) 11.2.0

getwd: /home/srackham/local/projects/hello-v
vmodules: /home/srackham/.vmodules
vroot: /home/srackham/local/bin/v
vexe: /home/srackham/local/bin/v/v
vexe mtime: 2022-09-19 19:31:14
is vroot writable: true
is vmodules writable: true
V full version: V 0.3.1 ac64318.e6e3751

Git version: git version 2.34.1
Git vroot status: weekly.2022.37-42-ge6e37519 (8 commit(s) behind V master)
.git/config present: true
thirdparty/tcc status: thirdparty-linux-amd64 827f7452

$ cat hello.v
module main

fn main() {
        println('Hello World!')
}

$ v -g hello.v         

srackham@gnome-2204 ~/local/projects/hello-v
$ gdb --args hello
GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
    :
Reading symbols from hello...
(gdb) r
Starting program: /home/srackham/local/projects/hello-v/hello 
[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.
0x000000000045e292 in GC_find_limit_with_bound ()
(gdb)

phanos-engineer added the Bug This tag is applied to issues which reports bugs. label Jun 30, 2022

packysauce mentioned this issue Aug 12, 2022

Add launch.json for debugging when vscode is installed vlang/vscode-vlang#454

Open

div72 mentioned this issue Aug 15, 2022

Using GDB fails for programs using the GC #15429

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unable to debug using GDB or LLDB #14904

Unable to debug using GDB or LLDB #14904

phanos-engineer commented Jun 30, 2022 •

edited

Loading

JalonSolov commented Jul 1, 2022

phanos-engineer commented Jul 1, 2022

pd-giz-dave commented Jul 6, 2022

pd-giz-dave commented Jul 8, 2022

medvednikov commented Jul 8, 2022

phanos-engineer commented Jul 8, 2022 •

edited

Loading

JalonSolov commented Jul 8, 2022

JalonSolov commented Jul 8, 2022

pd-giz-dave commented Jul 8, 2022 via email

packysauce commented Aug 12, 2022

EchoPouet commented Sep 17, 2022

srackham commented Sep 20, 2022

Unable to debug using GDB or LLDB #14904

Unable to debug using GDB or LLDB #14904

Comments

phanos-engineer commented Jun 30, 2022 • edited Loading

JalonSolov commented Jul 1, 2022

phanos-engineer commented Jul 1, 2022

pd-giz-dave commented Jul 6, 2022

pd-giz-dave commented Jul 8, 2022

medvednikov commented Jul 8, 2022

phanos-engineer commented Jul 8, 2022 • edited Loading

JalonSolov commented Jul 8, 2022

JalonSolov commented Jul 8, 2022

pd-giz-dave commented Jul 8, 2022 via email

packysauce commented Aug 12, 2022

EchoPouet commented Sep 17, 2022

srackham commented Sep 20, 2022

phanos-engineer commented Jun 30, 2022 •

edited

Loading

phanos-engineer commented Jul 8, 2022 •

edited

Loading