4 ms·

> Use a damned debugger! Take a traffic dump! Use strace! I have encountered a fair amount of cases where that does not work. - debugging a super large progr

> Use a damned debugger! Take a traffic dump! Use strace! I have encountered a fair amount of cases where that does not work. - debugging a super large program ? loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds. - not an admin on the machine you are and the person with the admin account is not around ? sorry, you can't debug on macos (and likely in some linux distros) - likewise, no traffic dump (and I'd assume no strace) if you don't have root access

SCHiM 6y ago
And how about highly congested multi threaded programs? I've got a program with log statements like that all over the place. Since stepping through it with a debugger would not even be possible. My IDE takes care of hiding the debug statements, since they're all encapsulated in different regions and if-def statements to log different types of things.
- coddle-hark 6y ago
  Isn’t that what tracepoints are for though? Flipping your argument, you’re basically saying that you can’t debug multithreaded code if the program doesn’t log.
  - SCHiM 6y ago
    I certainly wouldn't want to debug this ball of mud if there were no log statements, no :) But, I think we're depending on different programs in our workflow. I much prefer a logfile with statements that focus on what I want to inspect at the time. I'm quite proficient with debuggers on both Windows and Linux, but I tend to use them less when dealing with my own multi-threaded code.
  - merb 6y ago
    that works maybe with multi threaded code but not with greenthreads that are all over the place. the calls stacks are a pain in the ass.
coddle-hark 6y ago
> loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds To be clear I’m not talking about adding some specific print statements to the code while debugging, I’m talking about keeping those statements in production code. Of course, there’s cases where logging might be your only option. In that case: Go for it!
MaulingMonkey 6y ago
> - debugging a super large program ? loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds. Relinking a super large program may take minutes, whereas loading gdb can get me a backtrace in 3-4 seconds! VS natvis files and other visualizers can hot-reload while I'm looking at a crash dump from production that took hours to trigger/gather/repro! There are cases for logs - where sufficiently efficient conditional breakpoints are particularly painful to setup, for example - but the only time I've waited minutes for a debugger to respond has been with VS after major system updates as it refreshes a universe of symbols from the symbol server. Do you have some really slow python scripts auto-loading in GDB or something?
- jcelerier 6y ago
  > Relinking a super large program may take minutes, whereas loading gdb can get me a backtrace in 3-4 seconds! well, we have definitely opposite experiences :) the main software I work on creates a ~1gb binary in debug mode and lld links that in a few seconds. Bud gdb and lldb, even with gdb-index, and all the optimizations I could find, both make startup slow enough that I can go for a coffee and it's not always finished loading when I'm back

SCHiM 6y ago

And how about highly congested multi threaded programs? I've got a program with log statements like that all over the place. Since stepping through it with a debugger would not even be possible. My IDE takes care of hiding the debug statements, since they're all encapsulated in different regions and if-def statements to log different types of things.

coddle-hark 6y ago
Isn’t that what tracepoints are for though? Flipping your argument, you’re basically saying that you can’t debug multithreaded code if the program doesn’t log.
- SCHiM 6y ago
  I certainly wouldn't want to debug this ball of mud if there were no log statements, no :) But, I think we're depending on different programs in our workflow. I much prefer a logfile with statements that focus on what I want to inspect at the time. I'm quite proficient with debuggers on both Windows and Linux, but I tend to use them less when dealing with my own multi-threaded code.
- merb 6y ago
  that works maybe with multi threaded code but not with greenthreads that are all over the place. the calls stacks are a pain in the ass.

coddle-hark 6y ago

> loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds To be clear I’m not talking about adding some specific print statements to the code while debugging, I’m talking about keeping those statements in production code. Of course, there’s cases where logging might be your only option. In that case: Go for it!

MaulingMonkey 6y ago

> - debugging a super large program ? loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds. Relinking a super large program may take minutes, whereas loading gdb can get me a backtrace in 3-4 seconds! VS natvis files and other visualizers can hot-reload while I'm looking at a crash dump from production that took hours to trigger/gather/repro! There are cases for logs - where sufficiently efficient conditional breakpoints are particularly painful to setup, for example - but the only time I've waited minutes for a debugger to respond has been with VS after major system updates as it refreshes a universe of symbols from the symbol server. Do you have some really slow python scripts auto-loading in GDB or something?

jcelerier 6y ago
> Relinking a super large program may take minutes, whereas loading gdb can get me a backtrace in 3-4 seconds! well, we have definitely opposite experiences :) the main software I work on creates a ~1gb binary in debug mode and lld links that in a few seconds. Bud gdb and lldb, even with gdb-index, and all the optimizations I could find, both make startup slow enough that I can go for a coffee and it's not always finished loading when I'm back