Hamburg Hackweek 2025

Hackertools

• use make ctags and :tsel to create tags file and to navigate keywords
• 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

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

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

• 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 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

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.