Solved Weird crash of QNetworkAccessManager::post()
-
@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. -
@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.
-
@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.
-
@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. -
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. -
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 -
Found report for that issue:
https://bugreports.qt.io/browse/QTBUG-56747 -
@tomma Thannnnnnnnnnnnnnnnnks men! you are so amazing! It works when i set my mNetworkAccessManager's proxy to NoProxy!
-
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. -
@kshegunov or, given the use case, use
QScopedPointer<QNetworkReply,QScopedPointerDeleteLater> mNetworkReply;
-
Yes indeed. It does the same thing though. ;)
-
@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 QObjectthis->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?
-
@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
-
@kshegunov that's nice, and convenient. I can be less careful about memory and care more about business logic.
-
Well, it's "invented" not to make you less careful about memory, but exactly because
delete
ing an object that's referenced in a queued event in the event loop is pretty nasty - I'd segfault.