Why this code, running repeatedly in a custom object moved to QThread instance, produces memory leak?
void QCustomHTTPManager::compare()
{
// custom code to create request and multiPart content
QNetworkReply *reply = networkaccessmanager->post(request,&multiPart);
connect(reply,&QNetworkReply::finished,eventloop,&QEventLoop::quit);
eventloop->exec();
emit compared();
reply->deleteLater();
}
memory leak is around 8 bytes per call
Platform: Ubuntu 20.04, x86_64 CPU, Qt 5.14.2
To check maybe some other parts of my program belongs to the leak i have remove post() and no memory leak has been detected:
void QCustomHTTPManager::compare()
{
// custom code to create request and multiPart content
QTimer::singleShot(1,loop,&QEventLoop::quit);
eventloop->exec();
emit compared();
}
It was an issue of Qt build 5.14.2. No memory leaks for the requested code above have been reproduced with Qt 5.9.7 and 6.4.1
Related
For example:
void MainWidget::testThreadTask()
{
qDebug() << "On test task";
}
void MainWidget::onBtnClick()
{
QThread *thread = new QThread;
connect(thread, QThread::started, this, testThreadTask);
thread->start();
qDebug() << "Thread START, now we wait 5s";
QElapsedTimer timer;
timer.start();
while (timer.elapsed() < 5000)
{
}
qDebug() << "END";
}
The program output is:
START wait 5s
END
On test task
I want to create a task to handle something after the button is pressed, and then the function will wait for the task to complete before returning.
In fact, it may not be necessary to create a new task and wait for it to execute, because since you have to wait and get stuck there, why not run it directly in the function.
But this is actually a problem when I deal with QT serial data. I want to send the data to the serial port after pressing the button, and then wait for the data (by constantly reading), but I find that when I have been waiting, the serial port can not read the data at all, only when I exit the function the serial port can read the data.
Is there any way to deal with serial data sending and receiving synchronization?
void MainWidget::onBtnClick()
{
serial->write("Test");
if (serial->bytesAvailable())
{
QByteArray data = serialIo->readAll();
// handle the data
}
}
You are mistaken with what is happening in your application. I suggest you read Threads and QObjects (the entire page), Qt::ConnectionType and the detailed description of QThread.
What is happening to you is:
MainWidget does not live in thread. For the slot of a regular object to be called from thread, it first needs to be moved to that thread.Note that subclasses of QWidget cannot be moved to another thread. Because some OS supported by Qt limit where windows can live, they made the choice to force all QWidget to stay in the main thread, in all OS Qt can execute on.
When you connect thread to this (which BTW is incorrect in your question, it should have been with ampersands connect(thread, &QThread::started, this, &MainWidget::testThreadTask);), you create a queued connection, even though the thread has not technically started yet.
When you start the thread:
It fires its started signal.
Because the connection is a Qt::QueuedConnection, the slot will only be executed after returning to the main thread's event loop, i.e. some time after returning from onBtnClick.
Notes:
You would have more useful information in qDebug() about the threads running your code by using QThread::currentThread().Even better than that, your IDE should provide you a window specifically to see what thread has reached a breakpoint (Ctrl+Alt+H on Visual Studio).
At the risk of insisting, keep in mind this warning from the Qt help:
Be aware that using direct connections when the sender and receiver live in different threads is unsafe if an event loop is running in the receiver's thread, for the same reason that calling any function on an object living in another thread is unsafe.
With that said, because you wait 5 seconds before returning to the event loop and because it is only test code (= there should be no bug + it does not matter even if there is one), you should try to create a Qt::DirectConnection, just to see the slot be invoked from the worker thread.
The detailed description of QThread (link above) shows a complete working example of a worker object being moved to the new thread before it is started. The point is:
A worker object is created, then moved to the worker thread.
Connections are created for the controller to send QString to the worker object via signal/slot and for the worker object to return result to the controller via signal/slot too.
All these connections are Qt::QueuedConnection by default since the worker object was moved.
The worker thread is started. Since run was not overriden, it starts an event loop (in exec).
And there you have it.
Remember 1 things: widgets cannot be moved!!! Create your own worker object.
I make some https requests directly from my qml views, for instance for image sources. As I have a self signed certificate server side, I need to tell qt to ignore some ssl errors (I control both the server and the client applications, so this shouldn't really be a problem).
I've made a QQmlNetworkAccessManagerFactory to create NAMs, where I connect to the sslErrors signal.
UltraQmlAccessManagerFactory.h:
#ifndef FACKFACKTORy_H
#define FACKFACKTORy_H
#include <QQmlNetworkAccessManagerFactory>
#include <QObject>
#include <QNetworkReply>
#include <QList>
#include <QSslError>
#include <QNetworkAccessManager>
#include <QDebug>
#include <QSslCertificate>
class UltraQmlNetworkAccessManagerFactory : public QObject,
public QQmlNetworkAccessManagerFactory {
Q_OBJECT
private:
QNetworkAccessManager* nam;
QList<QSslError> expectedSslErrors;
public:
explicit UltraQmlNetworkAccessManagerFactory();
~UltraQmlNetworkAccessManagerFactory();
virtual QNetworkAccessManager* create(QObject* parent);
public slots:
void onIgnoreSslErrors(QNetworkReply* reply, QList<QSslError> errors);
};
#endif
UltraQmlNetworkAccessManagerFactory.cpp:
#include "UltraQmlNetworkAccessManagerFactory.h"
UltraQmlNetworkAccessManagerFactory::UltraQmlNetworkAccessManagerFactory() {
}
UltraQmlNetworkAccessManagerFactory::~UltraQmlNetworkAccessManagerFactory() {
delete nam;
}
QNetworkAccessManager* UltraQmlNetworkAccessManagerFactory::create(QObject* parent) {
QNetworkAccessManager* nam = new QNetworkAccessManager(parent);
QObject::connect(nam, SIGNAL(sslErrors(QNetworkReply*, QList<QSslError>)),
this, SLOT(onIgnoreSslErrors(QNetworkReply*,QList<QSslError>))
);
return nam;
}
void UltraQmlNetworkAccessManagerFactory::onIgnoreSslErrors(QNetworkReply *reply, QList<QSslError> errors) {
for (int i = 0; i < errors.size(); i++) {
qDebug() << "e: " << errors.at(i) << endl;
}
reply->ignoreSslErrors(errors);
}
There is also some glue in main.cpp that sets this factory to be used, I doubt that part is a source of errors as the qDebug prints are visible in the output.
As can be seen in the .cpp file in the function/slot onIgnoreSslErrors, I try to ignore every error (as a test) that I receive, but in the output I do not get the expected results.
Output
e: "The certificate is self-signed, and untrusted"
qrc:/qml/file/ImageView.qml:16:5: QML Image: SSL handshake failed
I have successfully made QNetworkRequests from C++ directly with a QSslConfiguration, specifying TLSV1_0 and a certificate. As I have a suspicion that the handshake fails because one side expects SSL and the other TLS I have also tried to set the QSslConfiguration on the QNetworkRequest object throgh reply->request(); This, however, changes nothing.
(This is a very old one but as I stumbled over this recently and haven't found the answer, I think it's still worth answering)
You don't show the place where you actually setup the factory object but it is extremely likely that it does not belong to the same (actually, any) thread used when its create() method is called. Here's an excerpt from the Qt documentation on the class:
the developer should be careful if the signals of the object to be returned from create() are connected to the slots of an object that may be created in a different thread
It further mentions authenticationRequired() signal but sslErrors() acts in the same way: both signals, among a few others, need either a direct or a blocking queued connection so that by the time of returning to the place of emitting the signal the network reply object has already been configured by the slot.
What happens in your case is (very likely) the following (TL;DR: your slot is called asynchronously by a queued connection because it lives in a different thread, while sslErrors() requires a synchronous change to the running network reply object; despite the order of log lines, the request fails first and ignoreSslErrors() is called later):
The factory object is created, and the QML engine configured, in the main thread.
QML engine spawns a few threads to perform backend stuff, notably network requests for URLs (I'm making the assumption here that your ImageView.qml has an Image component). To perform the network request, these threads call UltraQmlNetworkAccessManagerFactory::create().
create() produces a NAM object and sets up a connection on it. The parent here is either the QQmlEngine object or (specifically for image requests) the backend thread object, as you can see e.g. here. Therefore, this NAM object belongs to the backend thread.
connect() uses Qt::AutoConnection type by default, which, since the threads of the factory and of the NAM object are different, corresponds to Qt::QueuedConnection. As a sidenote, the threads are checked at the time of signal invocation.
Eventually a QNetworkAccessManager::sslErrors() signal is emitted. Since this is a queued connection, the only thing that immediately happens is placing an invocation of onIgnoreSslErrors() on the event queue for the main thread.
If you're very lucky, you may have a context switch to the main thread right after that - but there's literally nothing to ensure that so it's much more likely that control returns to the site where QNetworkAccessManager::sslErrors() was emitted. And since ignoreSslErrors() wasn't called, the request fails the handshake. The backend thread posts relevant data from the (failed) QNetworkReply object back to the main thread - see the postReply call in the middle of the method (or it may do it a bit later - that doesn't matter anymore).
Once the context switches to the main thread ignoreSslErrors() is executed - alas, it's already too late, as the network reply has very likely finished with failure already; but that first log line comes out now.
The main thread goes on through the event loop and finds the QQuickPixmapReply::Event object with the failure data. After some unroll of the calls and signals the failed image ends up in QQuickImageBase::requestFinished() that prints the second log line for you .
As for the fix, it's tempting to just specify Qt::BlockingQueuedConnection as the fifth parameter to connect(). Unfortunately, this will deadlock if a request is ever made from QQmlEngine that runs in the main thread - and uses a NAM instance created by this factory to, e.g., request QML components over the network. Best I could come out with so far is an equivalent of
connect(nam, SIGNAL(sslErrors(QNetworkReply*, QList<QSslError>)),
this, SLOT(onIgnoreSslErrors(QNetworkReply*,QList<QSslError>)),
currentThread() == this->thread() ? Qt::DirectConnection
: Qt::BlockingQueuedConnection
);
I have 2 processes.
The first one creates a QSharedMemory, with a key.
The creation is successful, as no error is returned.
In the second process, I try and attach to the shared memory, having done setKey() with the same key name as the first process, and then try and attach() to the memory.
The attach() fails. Using errorString() on the shared memory, the following string is returned :
QSharedMemory::handle: doesn't exist
Platform is Windows.
What could I be missing here? Kindly advise, thanks.
Have you looked at the shared memory example?
http://doc-snapshot.qt-project.org/4.8/ipc-sharedmemory.html
Below are some code snippets from that example.
Here is what the first process does to put a buffer of "size" into the shared memory:
if (!sharedMemory.create(size)) {
ui.label->setText(tr("Unable to create shared memory segment."));
return;
}
sharedMemory.lock();
char *to = (char*)sharedMemory.data();
const char *from = buffer.data().data();
memcpy(to, from, qMin(sharedMemory.size(), size));
sharedMemory.unlock();
Here is what happens when the second process wants to access the shared memory:
if (!sharedMemory.attach()) {
ui.label->setText(tr("Unable to attach to shared memory segment.\n" \
"Load an image first."));
return;
}
QBuffer buffer;
QDataStream in(&buffer);
QImage image;
sharedMemory.lock();
buffer.setData((char*)sharedMemory.constData(), sharedMemory.size());
buffer.open(QBuffer::ReadOnly);
in >> image;
sharedMemory.unlock();
sharedMemory.detach();
ui.label->setPixmap(QPixmap::fromImage(image));
Note also that in the example, both processes must be running and still have their instance of QSharedMemory. Here is how it is described in the documentation:
Windows: QSharedMemory does not "own" the shared memory segment. When
all threads or processes that have an instance of QSharedMemory
attached to a particular shared memory segment have either destroyed
their instance of QSharedMemory or exited, the Windows kernel releases
the shared memory segment automatically.
Hope that helps.
Encountered same problem. Make sure that QSharedMemory object still lives when second binary tries to attach.
If you want to block ability to run 2 instances of same QT binary, just make QSharedMemory object using dynamic memory which will live until app exit.
I have created my own HTTP class that utilizes QNAM and provides means for sending HTTP requests. It uses QEventLoop for synchronization and QTimer for timeouts.
I'm facing few problems with my solution. On certain Symbian platforms my QTimer signals timeout too fast (e.g. like after 1 sec when timeout is 30 secs). This happends usually if my HTTP Post playload is large or if I'm downloading a file via GET (request takes some time to complete). I want to note that same code works fine on certain devices (S60 3rd ed.) but on the other hand some devices (5th edition) get this error almost all the time.
Here is a code snippet:
MyHttp::MyHttp(QObject *parent) : QObject(parent)
{
m_Timer.setSingleShot(true);
connect(&m_Manager, SIGNAL(finished(QNetworkReply*)), SLOT(OnFinished(QNetworkReply*)));
connect(&m_Timer, SIGNAL(timeout()), SLOT(OnTimeout()));
}
void MyHttp::Post(const QString &data)
{
m_RetCode = 0;
QNetworkRequest request(url);
m_Reply = m_Manager.post(request, data.toAscii()); // QPointer<QNetworkReply> m_Reply
m_Timer.start(30*1000);
m_EventLoop.exec(); // Synchronization point
}
void MyHttp::OnFinished(QNetworkReply * reply)
{
// Handle response / Timeout / Errors
reply->deleteLater(); // Use deleteLater() as adviced in the documentation
StopWaiting();
}
void MyHttp::StopWaiting()
{
m_Timer.stop();
m_EventLoop.exit();
}
void MyHttp::OnTimeout()
{
m_RetCode = TIMEOUT; // #define TIMEOUT 50000
if(m_Reply.isNull() == false)
{
// Abort reply
m_Reply->abort();
}
}
Personally I think that one of the following might cause the problem:
re-entering local event loop messes up the signals
I'm utilizing same QNAM multiple times (several request during same session). This is required because if I destroy the QNAM my session goes down on the server side.
Is anyone able to see some errors that might cause this behavior?
Platform: Symbian S60 3rd/5th edition
Tools: Nokia Qt SDK
I've exactly that sort of problems as well. Using local to the method QEventLoop produces strange results, like blocking some events to be processed (and then loop never exits), or like explained, provoking QTimer to fire too fast before timeout (and then loop exits too early).
Using an instance field for the loop initialized once in the constructor of parent object of the loop, seems to solve the problem.
I'm on Qt 4.6.3 and Symbian S60/5th Edition.
I have an Qt application for symbian that receives gps data, stores it into a database and tries to post it to a server. First two steps work fine but continuous posting either crashes my application or kills my internet connection.
I have modified my application for debugging purposes so it only does post data to a server in every 10th second. Application runs fine for about 45-90min without any significant memory increase.
After that that I'll get an error from QNetworkReply saying "Cannot allocate memory".
Same time memory usage increases approximately 63500(bytes?).
On next upload I'll get reply that says "Invalid socket descriptor" and after that my QtCreator debug output is filled with "exception on 7 [will do setdefaultif(0) - hack]"
Anyone know what is going wrong here? I can't find errors from my upload code that could be causing this.
Here is my upload script.
void MainWindow::upload() {
//Content of postData below. Using same data on every upload now when tracking the bug
//[{"timestamp":"2010-10-01T17:10:27","latitude":62.1823321,"longitude":25.73226825,"user":6}]
QByteArray postData;
QNetworkRequest request;
request.setUrl(uploadUrl);
this->qnam->post(request, postData);
}
void MainWindow::serviceRequestFinished(QNetworkReply* reply) {
QByteArray bytes = reply->readAll();
if (reply->error() == QNetworkReply::NoError)
{
//nothing in here when debugging
} else {
qDebug() << "-------Reply error: " + reply->errorString();
}
reply->deleteLater();
updateHeapStats();
}
void MainWindow::updateHeapStats() {
#ifdef Q_OS_SYMBIAN
TInt mem, size, limit;
User::Heap().AllocSize(mem);
size = User::Heap().Size();
limit = User::Heap().MaxLength();
qDebug() << "**DEBUG MEMORY - > Memory: " << QString::number(mem);
qDebug() << "**DEBUG MEMORY - > Heap limit: " << QString::number(limit);
qDebug() << "**DEBUG MEMORY - > Heap size: " << QString::number(size);
#endif
}
Allmost forgot, I have tested this with Nokia N97mini, 5230 and 5800 and they all behave same way.
edit. Forgot to mention that when internet connection "dies" I still can see that 3G is on but connecting to internet with web-browser fails. When I close the application and try to connect to internet with browser it says "Web: Memory full, ..."(web requests from apps works fine) I'm using Nokia Energy profiler and it doesn't show any signs of memory being full. Even tested this and started 2 games, ovi maps and tons of other applications and they worked fine even though they consumed over 40MB of memory.
With the caveat that the only networking code I do in Qt is on a desktop platform and even then I need to look it up, I don't see anything obvious. I also know that in my own code deletelater() sometimes has a different idea of what "later" is than I do. I don't have time to look it up and may be wrong here, but I think deletelater() actually runs on the event thread, and if your event thread is always busy, when will it have time to delete the object? For debug purposes, I would replace deletelater() with delete (and really, there's no reason to use deletelater() unless you've got a parent/child relationship that you need to clean up, and there might be a way to manually remove the child from the parent so you don't need to worry about dangling pointers when you call delete).
I also don't know the accuracy of your memory consumption test. Does the allocated memory test refer to the current thread? The current process? Does a program received a "chunk" of memory from the heap that it simply managers on its own and it isn't permitted to use more than? I think you know this framework much better than I do; these are just some thoughts for you to try.