All Terminal methods leak memory on Windows about term HOT 7 CLOSED

bugging intensifies

edit: For the record, the weird behavior turned out to be caused by unrelated buffering errors, but this amount of leakage still makes me uncomfortable.

from term.

I'm not familiar with Windows debugging tools, so I had a really "fun" time reproing this on Windows 10. I wasn't able to get UMDH to work, so I followed https://blogs.technet.microsoft.com/yongrhee/2011/12/19/how-to-troubleshoot-a-handle-leak/ .

Condensed steps I took, not all of which I'm sure are necessary:

1. Install Debugging Tools for Windows following https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/ .
2. Checkout and build https://github.com/facebookincubator/fastmod, which uses term for colored output.
3. Launch Application Verifier (installed via Debugging Tools for Windows). Enable "Basics" for fastmod.exe by pressing Ctrl-A, navigating to fastmod\target\debug\fastmod.exe, and then making sure "Basics" is checked in the right pane of Application Verifier.
4. From fastmod's root directory, run target\debug\fastmod.exe fn fun. It's important to use cmd.exe and not bash or something, because otherwise a TerminfoTerminal will get created instead of the Windows-specific one.
5. Start windbg (cmd-r windbg) and use File > Attach to Process to attach to fastmod.exe.
6. In windbg, run !htrace -snapshot and then g.
7. In fastmod, press n to reject the first change.
8. In windbg, select Break from the Debug Menu and then run !htrace -diff. Note that there are about 2 outstanding handles since the last snapshot, indicating a leak. Run g to resume fastmod.
9. Repeat steps 7 and 8 a few times and note that the number of outstanding handles grows.

I have a local patch that creates a wrapper struct that calls CloseHandle and stops the number of outstanding handles from growing, as suggested in the original issue. I hope to send a PR sometime in the near future. The irritating thing about patching this is that auto-dereferencing for the wrapper I wrote didn't quite work (perhaps because HANDLE is a raw pointer?), so I had to write *handle instead of handle everywhere.

from term.

If @retep998 doesn't beat me to it, I'll get around to fixing this after labor day (thesis deadline).

from term.

Is there any news about this?

from term.

Other than it completely fell off my radar? No, sorry. I'll try to fix it tomorrow. If I don't fix it in a few days, please bug me.

from term.

Any updates on this? I'm seeing some weird behavior on windows, and it'd be nice to eliminate this as the cause.

from term.

I'm unlikely to get around to fixing this any time soon as I don't have access to a windows machine and debugging with wine is a real pain. If anyone has a Windows machine, I'd be happy to review a patch.

from term.