0

Following a segfault in my program, I tried using lldb for the first time to debug it and find the problematic line (I tried with valgrind at first, but it wasn't all that helpful), but the trace is less than clear, and I haven't been able to find the resources to decipher it. Could someone help me understand how I'm supposed to read the following :

Process 4476 stopped
* thread #1, name = 'cub3d', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x000000000040369f cub3d`ft_get_start + 321
cub3d`ft_get_start:
->  0x40369f <+321>: movq   (%rax), %rax
    0x4036a2 <+324>: movzbl (%rax), %eax
    0x4036a5 <+327>: testb  %al, %al
    0x4036a7 <+329>: jne    0x403591                  ; <+51>

Thank you all in advance.

ks1322
  • 33,961
  • 14
  • 109
  • 164
Morgade
  • 33
  • 7
  • 1
    The address in register `rax` is ungood. If you compile with debug information, then you can find the line number of `ft_get_start + 321` – stark Jan 18 '21 at 15:22
  • @stark I compiled with gcc and the -g flag, which should probied debug information, unless I am mistaken ? – Morgade Jan 18 '21 at 15:45
  • Good, then you should already be able to get source line number info if you ask the debugger for it. In GDB, `list` would show you the current source line. Or maybe `info frame`. I'd guess LLDB should be similar. – Peter Cordes Jan 18 '21 at 15:56
  • When I use the command "list" it gives me 10 lines of my code. Is that the best precision I can get ? @PeterCordes – Morgade Jan 18 '21 at 17:33
  • @Morgade: Debug info maps each instruction to exactly one C source line (even though optimization can make that a bit unrealistic it still picks one). The current line is probably the first or middle, depending on the debugger config. If it doesn't highlight / indicate one of those lines as the current one in the listing, then use other commands, like `info something`. LLDB has documentation. – Peter Cordes Jan 18 '21 at 17:36
  • Try `bt` for a backtrace, which should include line numbers. – Nate Eldredge Jan 18 '21 at 18:55
  • Is `ft_get_start` your code, or a library? – stark Jan 18 '21 at 18:58
  • @NateEldredge bt gives me more confusing mess, including the same weird ft_get_start + 322 thing. – Morgade Jan 22 '21 at 17:29
  • @stark it is part of my code, yes. – Morgade Jan 22 '21 at 17:30
  • @PeterCordes after investigation, it gives me the 10 lines preceding the function call in which the problem resides. As far as I can ascertain, the problem doesn't come from the call itself, however. And yes, LLDB has doc, but I find incredibly hard to decipher, hence my cry for help. – Morgade Jan 22 '21 at 17:32
  • I think something may be wrong with your compilation process. When I build a segfaulting test program with `gcc -g` and run it under `lldb`, I get a line like `frame #0: 0x0000555555555273 a.out\`main at foo.c:26:8`, showing the source file and line number, and then a listing of surrounding lines with a big prominent arrow pointing to the one in question. The fact that you're only getting an address and a disassembly suggests that the source line debug info is missing from your binary, or else that it doesn't match what lldb is expecting. – Nate Eldredge Jan 22 '21 at 17:47
  • Are you sure you recompiled every source file with `-g` (not only the final link, which won't help)? Are you sure you are actually running the rebuilt binary, and not some stale version from another directory? Please show your complete process for building and running the program. What versions of gcc and lldb are you using, on what OS? How did you install them? – Nate Eldredge Jan 22 '21 at 17:48

0 Answers0