3 ms·

Unless you write in some crazy, rapidly changing env. Then you learn debugger like once? twice? thrice? And still they are not this complex >but one has to ba

Unless you write in some crazy, rapidly changing env. Then you learn debugger like once? twice? thrice? And still they are not this complex >but one has to balance the time spent learning & managing fancier tools versus the time spent getting the job done. There is funny saying which goes like this You can save 2h of reading debugger docs with 12 years of using prints

toast0 4y ago
Maybe I'm weird, but when I'm debugging, the problem could be in my code, library code, runtime code, or kernel code. Usually the first two can use the runtime debugger, but the runtime code needs a different debugger (usually gbd/lldb), and the kernel needs a third debugger (if you even get one). And sometimes I care about the frontend, so there'a a web debugger and maybe a windows debugger for the browser. Thankfully, I've never needed to debug the windows kernel, that would be a whole nother level. Sometimes I'm working on projects with multiple languages, so then I need to debug in Erlang, Perl, PHP, Javascript, hopefully not much Python, userland C, kernel level C. My degree from the printf school of debugging works on all of those. But still, sometimes, printf isn't enough, and you've got to spend the half day figuring out how to get the debugger to work in your current environment, and then the situation often just pops right out (but sometimes it doesn't and you're still just wondering... but now in a much more powerful and dangerous tool). Personally, tcpdump is my favorite debug hammer, but printf is second. FreeBSD's kernel debugger is pretty neat (especially over an IPMI serial console), but fills me with dread when I need it.