Hacker News new | past | comments | ask | show | jobs | submit login

Very curious about this wonderful magic. How were you able to get the call stack from the strace line?

I basically set up my GDB with commands to stop on a specific pattern of "lseek, then close", and if the pattern isn't met it just automatically continues the program.

This is what the gdb script looks like:

    set height 0

    catch syscall close
    catch syscall read
    catch syscall lseek
    disable 1 2

    commands 2
     disable 1 2

    commands 3
     if $rdi == 31
      enable 1 2
The lseek catchpoint (3) enables both read and close catchpoints; if the read catchpoint (2) is hit first it disables both and continues. This way we look for lseek followed by close without intervening reads.

It generates a few false positives but otherwise fairly quickly stops on the right syscall, at which point I could backtrace and prod the live program.

This is fantastic. I thought I was pretty good at gdb, but this is next level (and it isn't complicated).

I've never seen any resource on "how to gdb a really gnarly bug"; this is a great example.

Debuggers are great! They're printf debugging, except that your printf can respond to the program state almost arbitrarily at runtime; not only that, they can modify the program state and can do so from a lot more lenient environment than your compiler would usually allow you to do. An advanced user can end up doing more programming in the debugger than outside of it.

Glad to see people writing in C-like languages finally get a taste of lisp programs ;)

This is very nice and interesting. Does that also work for lldb? Would sth like this also be possible with dtrace?

Can you recommend any good resources to learn more about this? Should I just study the LLDB/GDB references? Or maybe if you think there are not much good resources on this, maybe it would be a good idea if you could write a blog post about this?

> Does that also work for lldb?

LLDB doesn't appear to have a way to set a breakpoint at syscalls, unfortunately. If it's dynamically linked, however, it will probably go through your platform's libc so you can probably achieve the same effect by breaking on all of the syscall wrapper functions.

I am also interested in this. So far this video [0] from CPPCon'18 is the most complete and fresh I managed to find. Other than that, GDB manual is okay (LLDB's is not complete, as seems to be the case with most LLVM-based tools).

[0] <https://youtu.be/V1t6faOKjuQ>

and you can do it in a rr trace on linux I think if its hard to reproduce which sometimes happen with similar programs

... wow. For other people, RR is a debugging tool for recording and playing back program execution. During the replay phase, you get great gdb debugger support, including running code backwards to find bugs.

It's not a toy: it can debug Google Chrome, Libre Office, and QEMU. However, RR is Linux-only.

Thanks alehander42!

Ref: https://en.wikipedia.org/wiki/Rr_(debugging)

Applications are open for YC Summer 2021

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact