Closed draivin closed 6 years ago
If @retep998 doesn't beat me to it, I'll get around to fixing this after labor day (thesis deadline).
Is there any news about this?
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.
Any updates on this? I'm seeing some weird behavior on windows, and it'd be nice to eliminate this as the cause.
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.
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.
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.
All
WinConsole
methods start by callingconout
, which in turn callskernel32::CreateFileA
, this creates a new file handle that is not destroyed.I've solved this locally by wrapping the handle in a struct that calls
kernel32::CloseHandle
on drop.UMDH log:
Tagging @retep998.