Potential handle leaks in dup_worker
Mon Feb 8 17:39:26 GMT 2021
I've had occasion to work through dtable::dup_worker, and I'm seeing the
potential for leaks of path_conv handles. I haven't seen any evidence that the
leaks actually occur, but the code should probably be cleaned up if I'm right.
dup_worker calls clone to create newfh from oldfh. clone calls copyto, which
calls operator=, which calls path_conv::operator=, which duplicates the
path_conv handle from oldfh to newfh. Then copyto calls reset, which calls
path_conv::operator<<, which again duplicates the path_conv handle from oldfh to
newfh without first closing the previous one. That's the first leak.
Further on, dup_worker calls newfh->pc.reset_conv_handle (), which sets the
path_conv handle of newfh to NULL without closing the existing handle. So
that's a second leak. This one is easily fixed by calling close_conv_handle
instead of reset_conv_handle.
As a practical matter, I think the path_conv handle of oldfh is always NULL when
dup_worker is called, so there's no actual leak.
I may well be confused and/or missing something.
More information about the Cygwin-developers