Also, the memory leak occurs regardless of logging state.

Originating discussion.

Apologies: I said I would add the steps, but didn't. They are currently listed on [[:w:en:User talk:Tom.Reding]] but can be listed here if anyone else is interested.

The leak starts at revision 12852. My immediate suspicion is the closure on the LMaker local variable in FixSyntax.cs. I have no idea how C# implements the currying, and I don't see why it wouldn't get released, but I'll try a fix (there are various ways of avoiding the closure). If I'm right, the ironies are (a) LMaker is only there because it provides an object to call NormalizeTitle() with (b) the delegate is rarely called anyway.

Settings / steps to reproduce:

1. File > Reset settings to original default settings
2. Options > Preferences > uncheck "Enable Logging"
3. Options > Use pre-parse mode
4. Source > Category > Year of birth missing > Make list
5. Options tab > uncheck "Auto tag" & uncheck "Unicodify whole page"
6. Options tab > Auto changes skip options > check "Human category changes"
7. Skip tab > uncheck "Only genfixes"
8. Start tab > Start

A quick fix: make LMaker static. That works in the above testcase. A more robust solution would be to move the body of NormalizeTitle() to Tools as a static, and wrap it in the existing method in ListMaker for signature compatibility.

I still don't understand why the separate closures don't get GC'd, but don't really need to. I also noticed that the full run incrementally uses a lot of Windows handles, but that doesn't seem to cause a problem.

I realized it wasn't directly an issue with the lambda function. Processing each article creates a ListMaker object, and the constructor hooks it into provider infrastructure, meaning it doesn't get GC'ed when it goes out of scope. That static-with-wrapper solution looks better.