Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Weird crash of QNetworkAccessManager::post()
Forum Updated to NodeBB v4.3 + New Features

Weird crash of QNetworkAccessManager::post()

Scheduled Pinned Locked Moved Solved General and Desktop
22 Posts 7 Posters 8.1k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    MemphisWang
    wrote on last edited by
    #1
    • 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?

    jsulmJ 1 Reply Last reply
    0
    • dheerendraD Offline
      dheerendraD Offline
      dheerendra
      Qt Champions 2022
      wrote on last edited by dheerendra
      #2

      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 ?

      Dheerendra
      @Community Service
      Certified Qt Specialist
      http://www.pthinks.com

      M 2 Replies Last reply
      4
      • dheerendraD 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 ?

        M Offline
        M Offline
        MemphisWang
        wrote on last edited by
        #3

        @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

        1 Reply Last reply
        0
        • M 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?

          jsulmJ Offline
          jsulmJ Offline
          jsulm
          Lifetime Qt Champion
          wrote on last edited by jsulm
          #4

          @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.

          https://forum.qt.io/topic/113070/qt-code-of-conduct

          M 1 Reply Last reply
          1
          • dheerendraD 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 ?

            M Offline
            M Offline
            MemphisWang
            wrote on last edited by
            #5

            @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.

            1 Reply Last reply
            0
            • J.HilkJ Offline
              J.HilkJ Offline
              J.Hilk
              Moderators
              wrote on last edited by
              #6

              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.


              Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


              Q: What's that?
              A: It's blue light.
              Q: What does it do?
              A: It turns blue.

              jsulmJ M 2 Replies Last reply
              0
              • jsulmJ 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.

                M Offline
                M Offline
                MemphisWang
                wrote on last edited by
                #7

                @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.

                1 Reply Last reply
                0
                • J.HilkJ 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.

                  jsulmJ Offline
                  jsulmJ Offline
                  jsulm
                  Lifetime Qt Champion
                  wrote on last edited by jsulm
                  #8

                  @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.

                  https://forum.qt.io/topic/113070/qt-code-of-conduct

                  1 Reply Last reply
                  2
                  • J.HilkJ 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.

                    M Offline
                    M Offline
                    MemphisWang
                    wrote on last edited by
                    #9

                    @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.

                    jsulmJ 1 Reply Last reply
                    1
                    • M 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.

                      jsulmJ Offline
                      jsulmJ Offline
                      jsulm
                      Lifetime Qt Champion
                      wrote on last edited by
                      #10

                      @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.

                      https://forum.qt.io/topic/113070/qt-code-of-conduct

                      M 1 Reply Last reply
                      0
                      • jsulmJ 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.

                        M Offline
                        M Offline
                        MemphisWang
                        wrote on last edited by
                        #11

                        @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.

                        1 Reply Last reply
                        0
                        • T Offline
                          T Offline
                          tomma
                          wrote on last edited by
                          #12

                          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.

                          M 1 Reply Last reply
                          2
                          • M Offline
                            M Offline
                            MemphisWang
                            wrote on last edited by
                            #13

                            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

                            1 Reply Last reply
                            0
                            • T Offline
                              T Offline
                              tomma
                              wrote on last edited by
                              #14

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

                              1 Reply Last reply
                              2
                              • T 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.

                                M Offline
                                M Offline
                                MemphisWang
                                wrote on last edited by
                                #15

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

                                kshegunovK 1 Reply Last reply
                                0
                                • M MemphisWang

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

                                  kshegunovK Offline
                                  kshegunovK Offline
                                  kshegunov
                                  Moderators
                                  wrote on last edited by
                                  #16

                                  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.

                                  Read and abide by the Qt Code of Conduct

                                  VRoninV M 2 Replies Last reply
                                  2
                                  • kshegunovK 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.

                                    VRoninV Offline
                                    VRoninV Offline
                                    VRonin
                                    wrote on last edited by
                                    #17

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

                                    "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                                    ~Napoleon Bonaparte

                                    On a crusade to banish setIndexWidget() from the holy land of Qt

                                    kshegunovK 1 Reply Last reply
                                    1
                                    • VRoninV VRonin

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

                                      kshegunovK Offline
                                      kshegunovK Offline
                                      kshegunov
                                      Moderators
                                      wrote on last edited by
                                      #18

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

                                      Read and abide by the Qt Code of Conduct

                                      1 Reply Last reply
                                      0
                                      • kshegunovK 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.

                                        M Offline
                                        M Offline
                                        MemphisWang
                                        wrote on last edited by
                                        #19

                                        @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?

                                        kshegunovK 1 Reply Last reply
                                        0
                                        • M 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?

                                          kshegunovK Offline
                                          kshegunovK Offline
                                          kshegunov
                                          Moderators
                                          wrote on last edited by
                                          #20

                                          @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
                                          

                                          Read and abide by the Qt Code of Conduct

                                          M 1 Reply Last reply
                                          1

                                          • Login

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • Users
                                          • Groups
                                          • Search
                                          • Get Qt Extensions
                                          • Unsolved