Thursday, April 23, 2020
Of course talking about a bug means its easier to find and fix the bug. Odd how that happens
Of course, after I point the finger to LibreSSL for the memory leak, I find the leak … in my own code.
Sigh.
Not knowing what else to do,
I thought I would go through my TLS Lua module to make sure I didn't miss anything.
That's when I noticed that I was keeping a reference to a connection so that I can deal with the callbacks from libtls.
I was expecting the __gc() method to clean things up,
but with a (non-weak) reference,
that was never going to happen.
Yes, just because you are using a garbage collected language doesn't mean you can't still have memory leaks.
I verified that, yes indeed, the references were being kept around after the request was finished. It was then straightforward to fix the issue.
That's not to say that libtls still isn't leaking memory—it is,
but (it seems) only when you initialize it
(which means it's not as bad).
But I'll know in a day or two if I fixed the leak.
I hope that was it.
Gopher selectors are OPAQUE people! OPAQUE!
Despite warning that gopher selectors are opaque identifiers and even setting up a type of redirect for gopher there are still gopher clients making requests with a leading “/”. This is most annoying with the automatic clients collecting phlog feeds. I expected that after six months people would notice, but nooooooooooooooo!
Sigh.
So I decided to make the selector /phlog.gopher valid,
but to serve up a modified feed with a note about the opaque nature of gopher selectors.
Yes,
it's passive aggressive,
but there's not much I can do about people not getting the memo.
Maybe this will work …
