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.5k 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.
  • 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
                                • kshegunovK 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
                                  
                                  M Offline
                                  M Offline
                                  MemphisWang
                                  wrote on last edited by
                                  #21

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

                                  kshegunovK 1 Reply Last reply
                                  0
                                  • M MemphisWang

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

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

                                    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.

                                    Read and abide by the Qt Code of Conduct

                                    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