Vaxry's blog

a programming blog!

A Ramble About Typos in Hyprland

28 VII 2022

1.8k

I think I have to start this with a preface explaining what I classify as a "typo" in programming. In my opinion, a typo in programming is not when you misspell a name of the variable, for example from MyVar to MyVae, as that would be quickly caught by the linter, or the compiler. What I mean by a typo here is a small brain lag that results in theoretically valid code, but one that you didnt intend. For example:

if (pObject->visible() && pObject != pSomeOtherObject);
    markObjectVisible();

At first glance, it looks perfectly fine, but I've once made that mistake and it took another person to spot it. As you can see, I put a semicolon at the end of the if, which means that the next line, markObjectVisible(); is not a part of the if block and will be executed regardless of the condition.

Such "typos" are usually very, very hard to spot and fix, and that's why linters and compilers often warn us of such oopsies. However, some oopsies are not detectable by them.

It's been 2 days since the last, second, typo with major consequences in Hyprland. Both of the typos have resulted in crashes out of the blue, and both were caused by, well, me.

The first none of you probably remember, as it was really early in development, when I accidentally passed a listener that expected a LayerSurface to a Subsurface. Oops. The second though, was pretty recent, and for a handful of people resulted in instant crashes when pretty much anything happened with a layerSurface. The typo?

layerSurface->hyprListener_destroyLayerSurface.initCallback(&WLRLAYERSURFACE->surface->events.destroy,
        &Events::listener_destroyLayerSurface, layerSurface, "layerSurface");

Did you spot it yet? No wonder. I've looked over this bit of code and its surroundings multiple times while trying to find the cause of the issue and I haven't spotted it either.

The issue is in WLRLAYERSURFACE->surface->events.destroy This is incorrect. In the destroy handler, I unregister a few event handlers. The problem is, that the surface destroy event is emitted after the layerSurface destroy event, meaning nothing about the events is guaranteed anymore. It's a typo, because I obviously meant WLRLAYERSURFACE->events.destroy, but somehow got it wrong.

As this is the second typo I've made that had major consequences, I think I'll from now on look REALLY closely to such places when another "random memory issue" springs up.

Unfortunately, the 2 weeks of debugging this will not be returned.


Questions, comments, mistakes? Ping me a mail at vaxry [at] vaxry.net and I'll get back to ya.