Maybe you should be debugging that other library instead

Ever wondered why your code changes seem to have absolutely no effect? I encountered a new variation to the theme recently. The reasons below are old, I’ve done every one of those mistakes myself and seen several people repeat at least one or more:

• forgetting to save the file before compiling
• running make install in different directory
• running the binary from different directory
• forgetting to run make install before running the installed application

But that’s just when you’re writing applications. When you’re working on libraries there are even more ways to get all confused, I learned.
Two more things to pay attention to:

• make sure the libgtk-x11-2.0.so.0 link points to the right library (and not the libgtk-x11-2.0.so.0.600.4.orig copy you made just in case)
• check that valgrind isn’t actually a wrapper shell script conveniently prepending /usr/lib/debug to the LD_LIBRARY_PATH

The first case seems to happen because ldconfig isn’t too bright, it’ll just happily update the link to point wherever when run during package/library installation. Usually I just do cp .libs/libgtk-x11-2.0.so.0.600.4 /usr/lib to save time and also to avoid such issues.

The second point was another surprise, though quite understandable in retrospect. /proc/$PID/maps of course had the explanation why the abort() I had planted in the middle of everything was doing nothing whatsoever. All I should’ve done was to have a look.

So the obviously missing NULL-check was the right fix after all. I was just running the wrong damn library when testing and went on to a wild goose chase. I’ve had better days.