hamburg-hackweek.txt Hackweek 2025 notes
Original Author: Sahil Gautam <printfdebugging@gmail.com>
Homepage: <https://printfdebugging.in/>
License: GNU GPL v2
==============================================================================
CONTENTS
1. Hackertools hackertools
2. Time Travel Debugging time-travel-debugging
3. Profiling profiling
4. Common Sense common-sense
5. Asking Questions asking-questions
6. Not too Far, Not too Close far-close
==============================================================================
Hackertools hackertools
- make ctags and :tsel are very important for libreoffice sourcecode
- read the manpages of common tools like git, grep, ripgrep...
- use gitgrep, probably multiple piped together to find relevant entries
- create aliases for commonly used commands eg: grep -Flir filename
- have real world tests and documents to see the real picture
==============================================================================
Time Travel Debugging time-travel-debugging
using rr, the big brother of gdb, one can time travel through the source
code and go in both the forward and backword directions of execution. so
one can set a breakpoint on the destructor, print and remember the this
pointer and set a conditional breakpoint on the constructor for the
instance being same as the pointer one, and start execution in the reverse
direction... so cool!
- dis n: removes/discards the n'th breakpoint
- b class::function(): set breakpoint at a function
- p /r obj.prop: print raw objs/ptrs without pretty printers messing up
- watchpoints: breaks at code if the vaule changes
- conditional watchpoints also work, with an if condition at the end
- f n for navigating to the nth frame in the callstack
==============================================================================
Profiling profiling
callgrind simulates the system and records the state of code at all
times. so if some memory was initialized and not accessed, callgrind will
warn about that. same in the case of out of bounds memory access as
callgrind knows which memory was allocated by the program and which
wasn't. cachegrind is another such tool.
VALGRIND=callgrind ./instdir/program/soffice start libreoffice in a
simulated callgrind env. valgrind by default looks for segmentation
faults.
kcachegrind is a visualizer for callgrind files, usually the largest one
has the most important bits. requires graphviz as a dependency. it shows
the callgraph of the program which is quite helpful (but some people find
the flamegraphs more readable).
perf generates some files which are used other tools to show flamegraphs
to visualize the data in a nicer, more interactive way. the flamegraphs
have various search/find features...
but profiling doesn't tell much, it's a fuzzy method. using printf time
logs is still the simplest, most reliable method of knowing whether
things got a whole lot slower or not. one can print absolute or relative
timestamps, depending on the usecase.
core/include/sal/log.hxx has all the functionalities required to print
time logs in libreoffice. SAL_LOG_FILE allows to log entries to a file
rather than stdout or stderr.
==============================================================================
Common Sense common-sense
- iterations on a patch should be seen in context of the whole change
- soft reset, unstage all and step through each line of code
- helps avoid irrelevant comments and code from getting merged
- helps reviewers avoid confusion and get done with it quickly
- some comments/code might be outdated, missleading...
- simple but not that obvious solutions
- make clean might help as outdated obj files might break the build
- objectdump, nm (binutils) shows all the exported symbols
- check if the dynamic/static lib was linked against or not
- git log -- filePath.ext also finds old, deleted files ;)
- debug build is not same as a release build
- a git status can save hours of debugging
- sometimes the problem is just some code that we forgot about
- if the error message seems cryptic, check the code
- never blame the language and the codebase for your mistakes ;)
- don't stash the change, find out what's wrong now, don't run away
- never use master for any branch project
- always keep separate projects in separte branches
- this way switching becomes easy
- push [wip] patches instead of stashing to save them, sep branches
- don't pretend that you know stuff
- a little humility goes a long way, code doesn't forgive the arrogant
- pretending confident, one falls straight on the face
- if you don't know something, or see it working out, go ask for help!
- wasting time, delaying a project is the worst thing one can do
- don't be out for an easy solution, understand the problem
- the brain always wants the easy way out of any situaiton
- find out what's wrong and don't just start asking when it fails
- learn to embrace the problems, don't be scared of them
- read others patches on a daily basis (5 a day)
- gives a lot of perspective on what's going on in the project
- introduces one to various coding styles or development workflows
- one can ask other's about their changes and gain perspectives
- cut the losses and move on
- there's no point dragging something which is not working
- after a final timeboxed attempt, after some failures, one should move on
==============================================================================
Asking Questions asking-questions
- asking good follow-up questions while listening others speak
- listen to others carefully and ask then thoughtful cross questions
- don't ask unneccessarily, noone likes talking for talking's sake
- ask when you don't understand anything, don't let the oppor.. go
- learn to connect the dots ...
- noone knows the answers to what if i implement it this way
- of-course we are not talking about generic situations here
- in such cases it's best to build a hacky prototype and then iterate
- the first solution/implementation won't be the final one for sure
==============================================================================
Not too Far, Not too Close far-close
while working on bugs, it's easy to get really focused on to the problem
and keep thinking about it without reaching anywhere. one can think
endlessly of how would hitting a golf ball from a sand pit work, but
one actually never knows until they start hitting it. it might not even be
a sand pit in the first place.
the idea is to not be too invested into the problem and have a playful
approach. this way when something fails, one has both a close and a
faraway perspective. then one can try a few things and if they don't work,
one can think of searching for the solution on the internet. if that
doesn't work either, one can ask others for help and share the logs.
==============================================================================
vim:tw=78:ts=8:ft=help:norl:fdm=marker:fmr=<<<,>>>:ma:noro