Details
Description
A QLocalSocket on Win32 will not actually be closed when deleted
If you have a QLocalSocket which has unflushed data to be written, QLocalSocket::close(), which is called from the destructor, diverts to disconnectFromHost. However, as this is done from the desctructor and the object is now deleted, the pipewriter will never signal the deleted object that it has finished writing, meaning things like CloseHandle(d->handle) never gets called, leaking local resources and incorrectly giving the other end of the pipe the impression the connection is still maintained.
Furthermore, QLocalSocket::abort() just calls close(), meaning that instead of disconnecting immediately, it disconnects as soon as all data has been written, which is the opposite of what it's documentation states.
To work around this, you need to have an object call close() on the socket, then wait for it to emit its disconnected signal before actually deleting the socket.