search

grag38 / qextserialport

Automatically exported from code.google.com/p/qextserialport
0 stars 0 forks source link

Increasing handle count on windows xp #47

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Has anyone noticed that on the event driven example, every call to
port->write increases the process handle count by 1 or 2.
Could this be a memory leak?

Original issue reported on code.google.com by cata_dan...@yahoo.co.uk on 24 Mar 2010 at 1:39

GoogleCodeExporter commented 8 years ago 
This may be related to the other report that write() is not completing - if it 
doesn't complete, the outstanding 
write handle will not be closed. In general, to avoid the case in which there 
are too many open handles, you can 
always check bytesToWrite() which lets you know how many oustanding bytes are 
waiting to be written.

Original comment by lst...@gmail.com on 24 Mar 2010 at 2:52

GoogleCodeExporter commented 8 years ago 
Sometimes ,after the bytesWritten() signal is emited , bytesToWrite() returns 
non 0.
write() always returns DWORD-1.
Could this be compiler related?
Has anyone experienced the same problem on Linux?

Original comment by cata_dan...@yahoo.co.uk on 25 Mar 2010 at 9:16

GoogleCodeExporter commented 8 years ago 
It's not likely to be too similar on Linux I think, since this code is so 
platform specific.  Hopefully I'll get a chance 
to look at it in more depth soon!

Original comment by lst...@gmail.com on 25 Mar 2010 at 3:01

GoogleCodeExporter commented 8 years ago 
I get same issue (VS2010 on Windows 7). Handles increase because of OVERLAPPED* 
newOverlapWrite created but not deleted after WriteFile (that obviously and 
correctly makes the handles number increasing). The file is 
win_qextserialport.cpp. Although, the delete cannot be done because the exit 
point is a "pending" write point.
I've experienced that even if the function QextSerialPort::writeData exit 
because of (GetLastError() == ERROR_IO_PENDING), all the bytes have been 
written....

Original comment by andrea.b...@gmail.com on 16 Feb 2012 at 2:06

GoogleCodeExporter commented 8 years ago 
...all because QextSerialPort::onWinEvent does not receive (for some unknown 
reason), the EV_TXEMPTY event (just the EV_RXCHAR), so the handles are not 
deleted, causing memory leak because of handle increasing. The only solution 
without changing library code is to the Polling instead of Event in the serial 
management. However, changing the library deleting the "overlapsToDelete" 
objects in a deferred way fix the issue. Any better suggestion from developers? 
Any help is appreciated.

Original comment by andrea.b...@gmail.com on 17 Feb 2012 at 8:29

GoogleCodeExporter commented 8 years ago

Original comment by dbzhang...@gmail.com on 16 Mar 2012 at 8:47