Comments by "Vitaly L" (@vitalyl1327) on "I Do Not Use A Debugger | Prime Reacts" video.

@thebluriam these days most of the systems are very complex and contain multiple parts, some are software, some purely hardware, and there is very little tools available for simulating such systems. Try to find a decent mixed signal simulator that will simultaneously let you debug software running on an MCU and debug how an anaolog circuit will respond to this software behaviour, all in properly simulated time. So, until we have such simulators, the only real way to debug such systems will be to run them physically, in real time, and then collect as much data as you can while they run - pass all the trace data through available pins if you have any, even blink LEDs and record slow-motion video (I did it a few times, was quite fun), use analog channels to log more data... What is not possible in such scenarios is to pause system at any moment you like and inspect it with a debugger. And these are systems this world runs on - dozens to hundreds of MCUs in any modern car, MCUs running a lift in your building, MCUs in medical equipment in your hospital, etc. It means, if we want to sustain the very foundations of our civilisation, we should not train programmers who might eventually end up supporting such systems with an emphasis on interactive debugging. Much better to teach everyone debugging the hard way, and only then tell them that there's such a thing as a debugger that can be handy if your system is not time-sensitive and if all the usual debugging methods failed. Not the other way around. So, my point is, the hard methods should always be the default, interactive debugging as only a last resort. We'll have better developers this way.
6
I never had any good experience with NSight. And it's not really a debugger, it's just a way to access performance counters, something akin to gperf for CPUs. My most fulfilling experience with debugging a GPU code was when I had a complete RTL model of the said GPU running in Verilator, and I could instrument the hardware as much as I like to monitor code performance for my specific use cases. Obviously, if you're not the GPU vendor, this option is not for you...
5
"Real time", really? Debuggers disrupt the time behaviour of your code, there is no way around it. If your code runs on a number of communicating devices simultaneously, (e.g., a few MCUs communicating over i2c or CAN), no freaking way attaching a debugger to any of them will be of any use at all. Just learn to debug the right way, without any of those debuggers. Even if debugging involves flipping a pin and connecting an oscilloscope to it. In my well over 30 years career I never had a singe use case for a debugger. Not even once.
5
Just use proper static code analysis tools to map the flows. No need to watch them step by step in a debugger.
3
well, developers who build on top of vast third-party "frameworks" are just doing it wrong. In the vast majority of cases using a third party dependency is rather a liability than help, and can hardly be justified. The programming culture went down the gutter in the recent decades, with developers thinking it's acceptable to drag dozens or even hundreds of third party dependencies for even tiniest of functionality. It's all utterly disgusting. So, yes, attitude towards debuggers is a good marker of what culture programmer is more aligned with, and yes, I'm using this as an interview question to filter out undesirables.
3
Lol. Good luck "setting breakpoints" if a few milliseconds disruption breaks the logic of the code completely. Guess debuggers are only useful for toy code like web and such...
2
@nitsujism You need to maintain FPS for a human user. It's not going to break the logic of you're running at 0.001FPS instead - the rest of the system will behave the same way, user himself is an understanding part. For audio - again, it's quite easy to bag the data and to test on historic data, so real-time is not always required. Delay line is trivial to simulate. As for logging, of course it'll be extremely dumb to use io steams, to use any kind of system calls, etc. All the proper logging frameworks use lock-free communication from real-time threads to non-realtime logger threads, with potentially quite large buffers accumulating the logged data. I'm in no way advocating for just sprinkling printfs here and there, it'd be barbaric. As for segfaults, quite often simply running a debug build can make your segfault go away (or to mainfest somewhere else). Valgrind, or address sanitiser, or just a more elaborate logging would be far more precise in locating where exactly your data got corrupted (which can be very far away from where the segfault happened). Debuggers only delay finding the root cause of the problem by diverting your attention to unrelated code paths.
2
@daniilpintjuk4473 That's not always possible. Either your code is heavily concurrent, or you're wasting the hardware capacity. Having said that, yes, you must always do your best to avoid concurrency where it's not needed. E.g., a single FSM with predictable timing is better than an interrupt-driven system, as you can always reason about the worst case timing and make sure it meets the hard real-time requirements. No way to do it with concurrency present. Yet, there's a form of concurrency that's even harder to debug and that's pretty much unavoidable in any modern system - multiple communicating devices, e.g., a number of MCUs communicating, each can be perfectly single-threaded and sequential, but their interaction still only makes sense in real-time and cannot be paused.
2
So, an incompetent code monkey confirmed. GDB can be scripted, making your code monkeying in an interactive debugger truly laughable. GDB allows plugins that decode various complex data structures in a readable way, good luck doing it with your IDE. And, more importantly, any IDE with a debugging functionality is still just a UI with, most often, the same GDB inside. Code monkeys are so funny, especially when they are arrogant.
1
@metaltyphoon look, monkey, you're out of your depth Go away, pitiful kid, and don't interfere again when adults are talking.
1
not to mention that games are literally a toy code. Can't get more toy than this. But of course for a little dumb kid like you games are a pinnavle of software. Go away, play your dumb games, and never dare to voice your worthless opinions again.
1
@metaltyphoon more like you don't have any idea. Let me guess, you're some kind of a web code monkey? Think of a case when your code runs on multiple MCUs, all communicate via various media, like RS485, I2C, CAN, etc. Protocols are time-sensitive. All MCUs workload is hard real-time. All logic depend on properly processing the data external to your system, that you have no control over. Now, good luck debugging any of this with your puny toy approaches, like stop and step through.
1
@wassafshahzad8618 even Clang comes with a lot of tools you can use for this. For example, it's quite convenient to build the project with LTO enabled, it'll allow to link everything into one single LLVM bitcode file, on which you can run a call-graph pass with llvm opt tool. No stepping through for hours, you'll immediately have a nearly complete call graph, giving you an idea of how different parts of the system depend on each other.
1
@temper8281 have your kernels dump into dedicated areas of some large array, of course. Then have another kernel that wilp aggregate and descramble the log data.
1
Don't put a bunch of print statements. Instrument your code automatically (trivial to do with LLVM), use static analysis to extract call graphs, use profilers to see where most of the time is spent, etc. Interactive debugging is such a barbaric and unjustified approach when there's a lot of fine tools available.
1
@xybersurfer where they don't exist, they can be created. I wrote a Fortran-77 static code analysis tool once, spent like 4-6 hours on it, and it was enough to build a call graph of a huge code base, and also to extract BNF syntax from a hand-written parser in this Fortran code. I would have spent months stepping through all of these in a debugger.
1
@xybersurfer if your language is very limited (say, MISRA-C level of limited), proving theorems is way easier than for something too generic.
1
@xybersurfer I ask them how they'll debug a hypothetical problem (or a real one, if I have time to give them a real environment set up with some deliberately broken code). If they reach for a debugger as a first tool, I'm getting suspicious immediately. A few more questions usually prove I'm right, and they are cavalier, cowboy coders who avoid any systematic, slow, steady approaches. If they're trying to add logging (or, if it's already there, to use it properly), if they're reaching for an address sanitiser, for Valgrind, or try to instrument the code (even with simple preprocessor macros, if setting up Clang toolchain is an overkill) - I'm pleased, this person clearly knows how to systematically narrow down problems and how to find optimal solutions. Yes, debuggers can be useful if you need to inspect some black box code (or otherwise code that's impractical to instrument and modify in any way), which is often the case with third party dependencies. But it's again just a case against third party dependencies in general. Having to depend on an OS, a compiler and a system library is already too much (and yes, there were cases where it was better to avoid even these dependencies, running on a bare metal instead).
1
Quite evidently you're very incompetent. Let me guess - a web "develpper"? Maybe, some bootcamp graduate? Or, even worse, "self-taught"?
1
@Asto508 all modern systems are distributed, besides the most trivial and dumb ones. Again, I never once had a use case for a debugger. Not a single time in my whole life.
1
@ricardoamendoeira3800 for this you need a tool to bag and replay all the external communication this subsystem is receiving, both analog and digital. In general it is very hard to do. More available in soft real time systems (see the bagging functionality in ROS for example), but nearly impossible in hard real time, where simply adding the bagging feature exceeds the system capacity.
1
@donkeyy8331 you need a profiler to find such things, not a debugger.
1
@nitsujism games? real-time? Lol. There's nothing real-time there. Nothing bad will happen if you skip a frame or two. Nothing will crash if you pause rendering altogether and inspect. It's a soft real-time at most, nothing interesting. Audio processing - yes, can be hard real-time, but essentially it's just a stream in, stream out, no complex feedback, so you can just bag all the input and process it at any pace you like. Now, try a proper hard real-time system. Like, automotive, or industrial control, where there's a physical component that won't wait for your code to catch up. And, no, I have no pity for people who fix segfaults with debuggers. They're beyond salvation. They cannot even use memory sanitisers properly.
1
@nitsujism that depends on what kind of logging you're doing. There's a lot of zero-overhead logging and signalling techniques.
1
@nitsujism there's Google's capture-thread library (but it's using a mutex, so not quite real-time), there's perfectly lock-free iris library by zxjcarrot, and dozens more. I just drag my own small logging library with me everywhere I go. There a lot of advantages in logging vs. debugging. Disciplined logging documents the system further, and forces you to think of what you're doing. It allows to pinpoint problems where they happen more likely than where they manifest, while debuggers usually do the latter (at least when you start investigation). Logging does not change the code behaviour, while merely compiling in a debug mode changes a lot.
1
@Asto508 and? Programmers who have this dumb habit of jumping on a debugger every time they see a problem may (barely) get through the bugs in such primitive non-distributed systems. But they'll be totally lost the moment they need to debug something more complex, as they have no idea how to debug properly. So what's the point in getting such a habit in the first place instead of learning the hard way?
1
@Asto508 Far more often than not, in my experience, every developer who have a habit of using debuggers end up being helpless when debugger is not available. Never seen it working the other way around. Yes, debuggers can be potentially useful, especially if you need to inspect some black-box third party pile of code, but for every single case in my practice when I considered reaching for a debugger I always ended up doing something else, and every time it was more efficient than an interactive debugger. That's my problem with the debuggers - their usefulness is vastly overrated, but a lot of people don't know any better.
1
@nitsujism a lot of "successful coders" do a lot of cargo cult things, they're awfully inefficient. Did not you notice how deeply broken this entire industry is, how awful the vast majority of code is? So, no, popularity is not an argument in a slightest. Once again, the biggest problem with the debuggers is that you'll end up inspecting the symptom, not the cause. They have nothing to offer you to help finding the cause of a problem. You still need to use other tools. So why bother with debuggers at all, to start with?
1
@nitsujism firstly, if you got yourself into such a predicament in the first place, in your own code, you have a far bigger problem than a mere bug. Your code is just bad. Secondly, the regular multi-level logging should give you more than enough insight into all state changes throughout life cycle, by default, from the moment you wrote this code. If you need to add more logging, you did it wrong.
1
@nitsujism this is what conditional logging and ring buffer kogging is for. Same as you'd have to do with a debugger anyway as you won'r step through thousands of iteratiins manually. I even do ring buffer logging on MCUs, and when some crash condition happens I extract the log for the final few milliseconds of its life.
1
@PapaVikingCodes it means you developed bad habits, you debug in a clumsy and inefficient way, and you may get quite confused in a situation where you need to debug, but debuggers are impossible.
1
@PapaVikingCodes keep demonstrating your incompetence. Say, you observe a segfault. Go on, use your debugger. You will get a stack trace at a point where segfault happened. You, for being an uneducated code monkey, will likely spend a ton on time stepping through that code. But the real cause of the sagfault is somewhere else, where the memory this code refers to accidentally was actually corrupted. Half an our of runtime ago. Your debugger will not be of any use here, yet you'll waste time anyway, since you don't know any better ways.
1
If you're working with a low-level language and rely on debugger to catch your mistakes, I don't want you anywhere near any mission-critical code. Not in automotive, not in medical robotics, not in aerospace, not in industrial automation. Your way is guaranteed to introduce a lot more bugs than it's possible to tolerate. Firstly, debuggers do not show you where the problem is. They let you see where the problem manifested. Especially if it's a memory-related problem, you can see its effects far away from the real cause. Then you'll find some hackish workaround and trot away happily, thinking you fixed the bug. The real developers never rely on debuggers. We'd rather stick to MISRA-C harsh rules, use all possible static analysis tools we can find, build extensive testing infrastructure, build zero-overhead logging wherever it's possible. Debuggers will never replace any of this, and will never be of any real added value when you should do all the above anyway.
1
@Spirrwell use a certified compiler (like CompCERT) to make sure that it does what it says on the tin. And, yes, I routinely find bugs in compilers. Never once I had to use a debugger for this, it would not have been useful at all. And often you cannot even debug the compilers, e.g., I found a couple of bugs in CUDA - had to treat it as a black box and did not even attempt disassembling the compiler itself. Logging, instrumentation and fuzzying helps. Learning to jump on a debugger as a first knee-jerk reaction to any bug is really a bad thing. I wish most programmers never knew debuggers exist. Learning the hard way is better. You did not waste time, you gained experience that early debugger users would have never had a chance to earn. As for the older code - I did not have to use debuggers when working on ancient (even back then already ancient) Fortran 77 code base, with barely any static analysis and instrumentation tools available, so I'm not sure why would I need a debugger for a modern MISRA-C loaded with tons of very powerful tooling. Better discipline trumps debuggers massively.
1
how funny, when an ignorant code monkey dares to have a dumb opinion and calls rhose who are orders of magnitude more capable than the said monkey "idiots".
1