Post

How often do people run into the SetFinalizer footguns in Go? (Accidental cycle, for example.) Would a GODEBUG that does something slow but tells you when you've made a mistake be useful to you? (Maybe even just for tests, to prevent a regression?) Sketch: go-review.googlesource.com/c/go/+/634599

go-review.googlesource.comgo-review.googlesource.comGerrit Code Review

24/12/24, 8:53 pm4 reposts6 likes

Michael Pratt

@prattmic.com

25 Dec 2024

I wonder how often such mistakes are even noticed. E.g., if you fail to close an FD, probably nothing bad happens in the vast majority of cases.

Michael Knyszek

@michael.express

25 Dec 2024

Agreed. It's already a niche tool and having it actually cause a real problem is likely even rarer than that. It could be useful to us working on std, I guess?

Michael Knyszek

@michael.express

24 Dec 2024

If such a debugging mode would be useful, what would be the most helpful information for debugging? Stack trace where the finalizer was applied? The object's type?

Dario Castañé 🏴‍☠️

@dario.cat

25 Dec 2024

Not often, but that sounds useful!

thepudds

@thepudds.bsky.social

25 Dec 2024

So would this replace the desire for a GODEBUG to disable the tiny allocator to help troubleshoot a finalizer/cleanup issue (because this would flag a finalizer or cleanup that isn’t firing because of the tiny allocator)? Would this CL also help for weak pointer tiny allocator related issues?

Michael Knyszek

@michael.express

25 Dec 2024

The sketch doesn't currently report issues related to the tiny allocator, but yeah, I'm thinking that such a GODEBUG could.