Weird crash of QNetworkAccessManager::post()

[MemphisWang]

• OSX 10.12.3 (16D32)
• Clang 800.0.42.1 (Qt default)
• LLDB 360.1.70 (Xcode default)

Migrated from Qt 5.7 to Qt 5.8 several days ago, my QNetworkAccessManager::post() stop working.
What more weird is that it does work if the url you set is a loopback address.
here i find a minimal way to reproduce it:

#include "mainwindow.h"
#include "ui_mainwindow.h"

#include <QNetworkAccessManager>
#include <QNetworkReply>

MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);

    this->mNetworkReply = NULL;
    this->mNetworkAccessManager = new QNetworkAccessManager();
}

MainWindow::~MainWindow() { delete ui; }

void MainWindow::on_btn_crash_clicked() {

    // QUrl url = QUrl("http://127.0.0.1:5000/api");  // it's ok to post to a loopback address
    QUrl url = QUrl("http://192.168.1.103:5000/api"); // crash on specific ip address or domain name address

    QNetworkRequest networkRequest;
    networkRequest.setUrl(url);
    networkRequest.setHeader(QNetworkRequest::ContentTypeHeader, "application/x-www-form-urlencoded");

    if (this->mNetworkReply != NULL) delete this->mNetworkReply;

    this->mNetworkReply = this->mNetworkAccessManager->post(networkRequest, "");

    connect(this->mNetworkReply, &QNetworkReply::readyRead, [=](){ qDebug() << "readyRead"; });
    connect(this->mNetworkReply, &QNetworkReply::finished, [=](){ qDebug() << "finished"; });
}

Is there some thing wrong with my implement?
why it can't work on the new version?
Is it a bug?

[dheerendra]

Program looks ok. When does it crash ? After you post or while constructing URL ? Also IP address u specified is pingable? IP address displayed when u run ifconfig command ?

[MemphisWang]

@dheerendra
After post. it crashed in moc code i guess:
when i step over this code on debug mode. it went to moc_mainwindow:

• qt_static_metacall
• case 0: _t->on_btn_crash_clicked(); break;
• qt_metacall

and then go straight to Disassembler, which i can't handle with

here is my crash report if it might help: http://paste2.org/Ecn72PgG

[jsulm]

@MemphisWang Not related: are you coming from Python? :-)
Because you prefix everything with this->, it is not needed in C++.

Another note: there is no need to allocate mNetworkAccessManager on the heap.

[MemphisWang]

@dheerendra
'192.168.1.103' is my local machine's IP address. (on ifconfig of course: it is in en0: )
I had a python flask server on port 5000. normally these two IP did not tell from each other.
but on this code snippet, they do.

[J.Hilk]

I'm not quite sure, but:

if (this->mNetworkReply != NULL) delete this->mNetworkReply;

    this->mNetworkReply = this->mNetworkAccessManager->post(networkRequest, "");

you delete your NetworkReply object here and in the next line, try to access the object via the pointer -> This usually results in a crash.

[MemphisWang]

@jsulm
I personally like to user this->, it can help me find out if it is a local variable.
but yeah~ I use python :P wrote Qt for ui, script for data handling.

and thanks for allocate advice.

[jsulm]

@J.Hilk No, that is not the case: he deletes the object mNetworkReply (not mNetworkReply itself) is pointing to and then assigns a pointer pointing to the new object. This is perfectly valid.
delete this->mNetworkReply does not delete mNetworkReply - it deletes the object mNetworkReply is pointing to.

[MemphisWang]

@J.Hilk
I don't think so.
first I free the memory of a pointer, it's the value (represents some memory address) of pointer not available, pointer itself can be access.
then I assign a new memory address as the value for the pointer. now it get a new memory to point to.

those code works in the old day, and still works if the url is 127.0.0.1, I just don't why others can't work.

[jsulm]

@MemphisWang It works for 127.0.0.1? Then you should connect error signal to a slot and print the error you get for other destinations.

[MemphisWang]

@jsulm yes it works only for 127.0.0.1, and I have tried to step over this code. after on_btn_crash_clicked() been invoked, it didn't have the chance to send out any useful signal. it just crashed. in moc code.

[tomma]

That crash stack seems to point to issue with getting proxy configuration from platform.
You could try disabling proxy for QNAM using setProxy(QNetworkProxy::NoProxy).
Most likely some bug with Mac OS integration and you should report it if not reported already.

[MemphisWang]

I don't understand, it's so weird. and my program can't even finish it's login work now.
if it's a bug, it's a huge bug, it will not be allowed to release. so I guess there must be some thing wrong with my code.
can any body repeat this problem? here is my header for your convenience: http://paste2.org/ZABXaUUJ

[tomma]

Found report for that issue:
https://bugreports.qt.io/browse/QTBUG-56747

[MemphisWang]

@tomma Thannnnnnnnnnnnnnnnnks men! you are so amazing! It works when i set my mNetworkAccessManager's proxy to NoProxy!

[kshegunov]

As a side note, this delete:

delete this->mNetworkReply;

is rather suspicious. In some use cases (e.g. using multiple threads) you might have events pending for that object in the event loop. Consider using QObject::deleteLater() instead.

[VRonin]

@kshegunov or, given the use case, use QScopedPointer<QNetworkReply,QScopedPointerDeleteLater> mNetworkReply;

[kshegunov]

Yes indeed. It does the same thing though. ;)

[MemphisWang]

@kshegunov You are right. I'll use deleteLater next time. and I have a further questions for this:
if i have a pointer to a QObject this->pObj,

this->pObj = new Foo();
this->pObj->doingSomeThing();
this->pObj->deleteLater();

can i continue to use this pointer immediately

this->pObj = new Foo();
this->pObj->doingSomeThing();

Is it OK?

[kshegunov]

@MemphisWang said in Weird crash of QNetworkAccessManager::post():

can i continue to use this pointer immediately

Yes, you can even use the same object immediately.

this->pObj = new Foo();
this->pObj->doingSomeThing();
this->pObj->deleteLater();

this->pObj->someOtherThing(); //< Valid until you return control to the event loop