linuxdcpp-team team mailing list archive
-
linuxdcpp-team team
-
Mailing list archive
-
Message #02207
[Bug 654040] Re: Handle leak with mingw, but not msvc (r2251)
Sorry was busy and forgot about this, but I just ran some tests now.
These were over LAN, 2 clients both connected to 2 ynhub servers on the same LAN. Handle testing was done on a dc++ instance on a client running Win XP 32 bit.
Test procedure was to download a file from the affected DC++ instance. After downloading the file (instance being tested is uploading), I dumped the results from handle.exe -s -p and handle.exe -a -p.
Then I download the same file again, and again dump the output of handle.exe.
Results are as follows:
Using r2251 MSVC: normal handle count
Using r2176 Mingw (0.770): normal handle count
Using r2260 Mingw: abnormal (increased) handle count: see attached txt file with results.
It appears to be semaphore handles that are getting leaked, and as in my
first post, it seems to be that two are leaked for each segment of a
file that is uploaded.
Note: I haven't tested handle counts when downloading (test client is
primarily for uploads).
** Attachment added: "r2260 mingw handle counts: after one file uploaded, and after the same file uploaded again"
https://bugs.launchpad.net/dcplusplus/+bug/654040/+attachment/1707066/+files/dcpphandles.txt
--
Handle leak with mingw, but not msvc (r2251)
https://bugs.launchpad.net/bugs/654040
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
Status in DC++: Incomplete
Bug description:
Running r2251 mingw release build on Windows XP, there seems to be a handle leak associated with uploading files (and possibly downloading, I haven't checked).
Using process explorer to monitor, it can be observed that when a segment of a file completes uploading in DC++, the handle count decreases by one, then increases by three handles as the next segment starts uploading. This means a net increase in handles, which after 12-24 hours puts DC++'s handle count at over 10,000 (if you have lots of users downloading from you).
This may possibly be an issue after longer periods of time, as it may lead to resource (handle) starvation in the OS. I am not sure when this started happening, I cannot replicate the problem with the x86 MSVC release build on XP, or when using the x64 MSVC release build on Win7.
So I'm guessing its something to do with mingw?
Note:
According to process explorers property page, these are not GDI or USER handles, for example, at the moment the affected process says:
handles: 6504
GDI handles: 417
USER handles: 206
if that helps.
References