Make sure "this" still exists when we're done sending the
readNotification.
The crash manifested itself when connecting to certain websites as they
would reply with status 403, then close the connection. On our end we
would then handle this "remote host closed" followed by handling the
data we received. The http code handles the data successfully and sees
we are done and there is nothing more to do, so it closes the
connection. Which leads to closing QAbstractSocket, which closes
native socket again and then deletes it.
Fixes: QTBUG-75620
Change-Id: I233c67f359aa8234f1a2c4ea9463108b08c9165f
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Change-Id: I4dde73423111ca4af386fa76ac26d1a1161fe493
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
If data is received and the remote immediately closes the connection,
it was possible that data was lost. If a remote closes the connection
make sure that any pending data is processed, before signaling closing
of the socket.
Change-Id: Ia94a616a31184fd28695919baaff99811fe0f1dd
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Change-Id: Iaf5f5d93cd07429626d5c500ac04e67daada8e6e
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
According to the documentation, datagrams that were
not completely read are discarded.
Change-Id: Id3a038d8aeeba05e8c8f92b70877f5f5297b89ca
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
The initial settings are done for other socket engines too.
The state checks return a message when they fail. Socket engine
auto tests rely on these messages to be shown.
Change-Id: If7734b453a24ecee4c3a028395ecdbb12859c871
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Change-Id: I62f3abcabf1a0e5f909c603cbdcf407e36bd0402
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Buffer handling is now completely moved to the worker. Instead of
moving data around all the time, the worker is responsible for
buffer handling. When reads happen, the data that is read is used
directly from the worker and its buffer is updated.
With the previous approach it was possible, that transfers never
completed. It was possible, that new data was read between calls
of bytesAvailable and read and the availability of that data was
never communicated to the user. If a read that does not read all
the data happens, we signal, that there is still data available,
so that the user is notified about that fact. At the same time
we avoid unnecessary readyRead calls by blocking them until a read
happens.
To make future debugging sessions easier, categorized logging
(including verbose) was added to the socket engine.
Task-number: QTBUG-65556
Change-Id: I12020ffcccf8eb3efec9c36dc5b0e6c0ebef7eb5
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
This allow retrieving the value of the known PMTU for the current
socket. This works on Linux (IPv6 and IPv4) and FreeBSD (IPv6 only) --
the other OSes don't have the necessary API.
Note: do we need add IP_MTU_DISCOVER?
Change-Id: I6e9274c1e7444ad48c81fffd14dcaf97a18ce335
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Remaining uses of Q_NULLPTR are in:
src/corelib/global/qcompilerdetection.h
(definition and documentation of Q_NULLPTR)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Change-Id: I5a2758065d3155f4f33b76c022c43955a9b096c2
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The old SDK does not consider the macro value a constant expression, so
the build fails.
Change-Id: I95bdcd9ad34ee4da81016ff07e70439ed229f853
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Instead of defering one more time by emitting the signal, we can add
the data to the list of available data/pending datagrams. For TCP
readNotification can be invoked directly so that emission of the
readyRead signal is tightly coupled to the availability of new data.
For UDP sockets calling readNotification directly stops handling of
more data and thus cannot be done.
With the old approach it was possible, that the last bit of TCP data
was lost, because the socket was closed while the data was still being
processed/transferred from the worker to the engine.
Task-number: QTBUG-61078
Change-Id: I9330b87876be853d310dc9e8e817ab344939d5dd
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Same as with receiving data, the "newConnection callback" might be
triggered late and cause a crash if it accesses data of a destroyed
object. By moving the handling of this callback to a worker without
much logic we can prevent these late callbacks from doing any harm.
The signals are no longer connected and thus do not trigger any
problems.
Change-Id: Ic61584f12a46506abe12d7b21403d0c0970c0aae
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
[ChangeLog][QtBase][General] Removed support for WinRT/Windows Phone 8.1.
Task-number: QTBUG-57288
Change-Id: Ifd6d6780cbbdb710d99556ba3d2fb2e514d4f789
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Similar to the way datagrams are handled for udp sockets the worker now
takes care of tcp data. Thus we avoid race conditions which stopped data
processing. It could happen that data was read from the socket into the
buffer and before readyRead was emitted the buffer was completely read.
In this case readNotification is set to false and no new data is processed
afterwards.
Additionally the buffer was replaced by a vector of QByteArray. The buffer
kept growing and was never cleared (and there is no obvious way for
clearing the buffer), so that an overflow happened eventually.
pendingReadOperations (and its mutex) could be removed as well. There is
only one situation where they could clash and that's the initial read.
Having two members is preferred over having a list of operations and a
mutex.
Task-number: QTBUG-56438
Change-Id: Idbad58e47785996023748c310530892163f24594
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Windows Information Protection is used for splitting corporate and
personal data, requiring connections to be established in a different
way instantiating ThreadNetworkContext.
Usage is enabled via the QT_WINRT_USE_THREAD_NETWORK_CONTEXT environment
variable.
Change-Id: I3aaa097b66fc616d42cd05a1e20bbcb004f6e467
Reviewed-by: James Tong
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
We first hide identifier 'hr' and then later we check the one that was never
correctly initialized.
Task-number: QTBUG-57226
Change-Id: Ibbf1bb99aa752c2e4090caf4533dc5f5b71b5e41
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Commented its purpose and the guarded members for
readMutex.
Fixed places where guarded members were accessed without
using the mutex.
Use QMutexLocker instead of manually (un-)locking the
mutex.
Task-number: QTBUG-44357
Change-Id: I3049bb0df30f00659dc284c8e30ad7503c11e7c6
Reviewed-by: David Faure <david.faure@kdab.com>
At the point in time when the callback is called it is very
unlikely that another thread sets the state or error of
the socket engine. Other members (readBytes, bytesAvailable)
are protected by readMutex.
Change-Id: I76cf12fbc9019d1b42846c4b40e0cd1c06bbb220
Reviewed-by: David Faure <david.faure@kdab.com>
As the list is changed inside a native callback
(handleReadyRead) which can be run inside another
thread it has to be protected by a mutex.
Change-Id: I145a866a36a12b7ea9bfa9f99ad9f7add872a021
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
Commented its purpose and the guarded members for
readMutex.
Fixed places where guarded members were accessed without
using the mutex.
Use QMutexLocker instead of manually (un-)locking the
mutex.
Task-number: QTBUG-44357
Change-Id: I0d46f9592d5a9d1b52e73df961785a6f6c9e80be
Reviewed-by: David Faure <david.faure@kdab.com>
As the function runs on the XAML thread it can make the app
unresponsive/wait forever on a socket close. Thus we should not wait
forever but have a timeout. If the timeout is hit the socket is not
closed properly but hard reset.
Change-Id: I82e9425c0f8195e3465027fdc2417a93f1c1ad91
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
When a client connects and sends data immediately it was possible that
initial data was lost as the state was set too late. If the callback was
called before the state was set the socket engine just discarded the
data. So the state has to be set before the callback is registered.
The new implementation needs a list of pending read operations. It can
happen that the "readyRead" callback is triggered directly while
"put_Completed" is called. The callback reassigns readOp which causes a
"function not implemented" exception when it jumps back to the
"put_Completed" call in "initialize"
Task-number: QTBUG-55889
Change-Id: I5f52e3377b6176f1f90f227ac0bf52b60ee2d95a
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Instead of calculating the bytesAvailable in place, the value should
be stored and only retrieved in the function itself. Otherwise it is
possible that bytesAvailable is called between the data having been
read and readyRead is emitted. In this case it's possible, that the
client reads all the data before the signal is emitted. Triggering
readyRead without any data being available will stop the socket.
Task-number: QTBUG-44357
Change-Id: I81d6ab094c5fdd71f30b9ceba9d790153cc92439
Reviewed-by: Harald Meyer <dev@meh.at>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
We may only emit the readReady signal once for every event loop
iteration. The previous implementation lead to the situation that the
socket engine stopped reading socket data when bursts of data was
received. In this case several readReady signals were fired. The socket
engine obtained the pending datagrams (not only the first one) and for
the following readReady signal no datagram was present. In this case the
socket engine stops reading and the engine stalls.
The new approach emits the readyRead signal at the most once every event
loop iteration. The list of new pending datagrams is queued to be added
to the "real" pending datagram list at the same time as the readyRead
signal. Thereby we avoid the situation that a client can read all the
datagrams before readyRead is emitted.
One more advantage of having the worker handle the pending datagrams
is that we no longer have to access the socket engine's members inside
the callback. Thus we avoid the situation, where a late callback can
make the application crash when the socket engine has already been
deleted.
Task-number: QTBUG-53472
Task-number: QTBUG-53471
Task-number: QTBUG-55895
Change-Id: Ia6d21cb635a40e7bd9e0213bb3a5c54ebc1220eb
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
And blacklisted a few tests in tst_QUdpSocket.
Conflicts:
src/android/jar/src/org/qtproject/qt5/android/QtNative.java
src/corelib/global/qglobal.cpp
src/corelib/global/qsystemdetection.h
src/corelib/io/qfileselector.cpp
src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_egldevice/qeglfskmsegldeviceintegration.cpp
tests/auto/network/socket/qudpsocket/BLACKLIST
Task-number: QTBUG-54205
Change-Id: I11dd1c90186eb1b847d45be87a26041f61d89ef6
There is no need for the functions to assert. By returning false they
show that something went wrong and the error will be handled
gracefully.
Change-Id: Ib026adf5c6fb23b5e6b5598533caec3b3669220c
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
If runOnXamlThread returns anything but S_OK an exception is thrown
which might cause the application to terminate. So we give the lambda
a reference to hr and check that reference instead of runOnXamlThread's
return value for errors.
Change-Id: I1188ea720c63f6fdf43400f2f3ff928b72afc58e
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
runOnXamlThread should always return S_OK (causes exceptions otherwise)
so we need another way of error reporting to the outside (hr reference).
A failed hr is reported to the outside (of the lambda) and interpreted
as an unknown error.
Specific error cases like the given address not being a local address
or the given address being in use already are handled inside the lambda.
The specificErrorSet variable is necessary in these cases so that the
error is not overwritten by unknownError.
Change-Id: I198d66fe97726d5127bf31e50c7eff3363d5259c
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
The two functions are merged and also renamed.
handleConnectionEstablished indicates that the
operation succeeded, but that is not necessarily
the case.
Change-Id: I66a4181a5693353fc9507785a6e6bbb8d5300a4b
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
This merge also blacklists a flaky tst_QGL::clipTest test on
OpenSUSE 13.1.
Conflicts:
src/network/socket/qnativesocketengine_winrt.cpp
tests/auto/opengl/qgl/BLACKLIST
Task-number: QTBUG-53133
Change-Id: I14b431aa5a189b7dd1d3e2dfff767d15df20fde3
If no read was established before (no IO pending) the function
will fail. In this case there is no need to assert though.
Change-Id: Iaa18e4124389783fc2b8363a85c60a308903a713
Task-number: QTBUG-53424
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
As the functionality is not available for udp sockets trying to
call it will cause a crash on socket close.
Task-number: QTBUG-53424
Change-Id: Id80b36a248d12bf360135b2374c0a0efdab3a1f0
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Mårten Nordheim
Oliver Wolff
Thiago Macieira
Kevin Funk
Maurice Kalinowski
Liang Qi
Timur Pocheptsov
Oliver Wolff
Harald Meyer
Alex Trotsenko