Weird crash of QNetworkAccessManager::post()

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

MemphisWang

@kshegunov that's nice, and convenient. I can be less careful about memory and care more about business logic.

kshegunov

Well, it's "invented" not to make you less careful about memory, but exactly because deleteing an object that's referenced in a queued event in the event loop is pretty nasty - I'd segfault.