Weird crash of QNetworkAccessManager::post()
-
@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 -
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.@tomma Thannnnnnnnnnnnnnnnnks men! you are so amazing! It works when i set my mNetworkAccessManager's proxy to NoProxy!
-
@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. -
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;
-
@kshegunov or, given the use case, use
QScopedPointer<QNetworkReply,QScopedPointerDeleteLater> mNetworkReply;
Yes indeed. It does the same thing though. ;)
-
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 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?
-
@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
-
@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.
-
@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.