|
|
|
i was roaming through references to a function in typescript trying to find which functions call it. i finally realized that i could just have set a breakpoint on that function and found out everything about it. this is very common knowledge but a debugger is quite far from the editor and starting takes time, maybe that's why it's not in the instincts.
debugging also requires some amount of street smartness to find your way in situations which look confusing from above. i was trying to debug an uno command call from online into calc and it was crashing, i saw a lot of processes related to cool in btop and i didn't know which one was the one i should attach the debugger to. then i thought of making some changes to the browser and i noticed one process was showing cpu and memory spikes, and i knew this is it. then i attached gdb to that process and paused at the breakpoint, found the issue. same goes for finding the right code to modify from the application like finding some string related to that etc.
just don't do that, every now and then you might forget to update to pasted code and the worst thing is that it might still work :). then you get to know about this in production. and worst when someone else creates a commit titled copy paste error and adds you as the reviewer, have been there myself, not a good place to be in.
some errors might look cryptic because that's your first time writing that error. in such cases it's often better to go to the irc channels and ask what it is about. when you read more about the language or search on the internet, you get to learn about such errors. i put the template declaration and definition in separate files and got a wierd linker error. turns out that they should be in the same file.
raw tools are quite easy specially when the man pages have examples, i learnt sed today and it was quite simple. learn to read the man pages and don't rely on random articles on the internet serving you adds and videos making you dumb and the horrible ai :|. in-fact while i was writing shell script, i got to know about https://www.shellcheck.net/ which tells you errors in your shell script.
it's actually a good thing to ask for help when you are stuck as it
might take you days what someone can help you with in minutes and they
know more than what you would ask. but make sure that you don't ask
them to solve it for you but rather share what you plan next to fix
the issue and ask their help in that. like my dotfiles script wasn't
working anymore so i asked the bash guys about some verbose mode and
they shared set -x.
every program has some kind of verbose switch, specially those which run as daemons/clients/listeners. it enables various levels of logging which helps us understand what's actually going on and fix our issues. while writing your own programs, it's quite important to add such log statements at key points such as conditionals and data state check points so that if anything goes wrong, the users of your program get to know exactly what's going on.
when a program is crashing, enable stack traces and you would know exactly which part is causing the issue. this way you get a good starting point to expand from.
often there are bugs which do not show up when you are testing them with an empty document or one with a few pages. so it's important to keep in mind that the tests should be based in reality.
these are quite delicate, one small sign off the place and you have a needle in the hay stack situation. so while writing bit operations, take care that you put the bit operations right. languages like c and c++ don't even complaint about this. types are another concern in such languages as you can often use wrong type like equating/assigning to/from different sized integers. these are also a nightmare to debug.
it's an important lesson that i learnt while debugging libreoffice. there are a lot of classes around the code that we are trying to debug. it's easy to get lost in the surrounding code trying to make sense out if it without actually solving the problem. therefore one should make their way through the code to the core of the problem, to the code which is causing the issue and then expand from there as much as required.
