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. std::string destructor crashing in Release when using ::toStdString methods
Forum Updated to NodeBB v4.3 + New Features

std::string destructor crashing in Release when using ::toStdString methods

Scheduled Pinned Locked Moved Solved General and Desktop
42 Posts 9 Posters 22.7k Views 6 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.
  • D Offline
    D Offline
    DRoscoe
    wrote on last edited by
    #32

    UPDATE2:

    I have found two more workarounds for this problem:

    QString temp("blah");
    std::string temp_str(std::string(temp.toLatin1().data()));
    

    and

    QString temp("blah");
    std::string temp_str = temp.toLatin1();
    

    Both of these result in valid strings which do not crash. I have now tried my original problem on several different systems at two different facilities with the same result. Either there is something lacking in the documentation for the MSVC10 build of Qt or its an outright bug. Why more people haven't reported this still baffles me.

    I am going to label this as SOLVED, though its a bit of a stretch. Thanks to all for your help!

    S 1 Reply Last reply
    0
    • D DRoscoe

      UPDATE2:

      I have found two more workarounds for this problem:

      QString temp("blah");
      std::string temp_str(std::string(temp.toLatin1().data()));
      

      and

      QString temp("blah");
      std::string temp_str = temp.toLatin1();
      

      Both of these result in valid strings which do not crash. I have now tried my original problem on several different systems at two different facilities with the same result. Either there is something lacking in the documentation for the MSVC10 build of Qt or its an outright bug. Why more people haven't reported this still baffles me.

      I am going to label this as SOLVED, though its a bit of a stretch. Thanks to all for your help!

      S Offline
      S Offline
      sandy.martel23
      wrote on last edited by sandy.martel23
      #33

      @DRoscoe said:

      Why more people haven't reported this still baffles me

      Personally, I haven't reported it because it has always worked perfectly, in Qt4, all Qt5 versions and with all MSVC versions I've used. I suspect it's the same for most people.

      It is also tested in the Qt5 test suite, so I doubt Qt would be released with this failing.

      Sorry, there is something with your configuration that you haven't told us (unintentionally, for sure) and we haven't guess.

      Out of curiosity, what version of Qt and Windows ? (you left that out, we only know it's Qt5). And what configure command do you use to compile it.

      1 Reply Last reply
      1
      • JKSHJ Offline
        JKSHJ Offline
        JKSH
        Moderators
        wrote on last edited by
        #34

        Thanks for posting your updates, @DRoscoe.

        Either there is something lacking in the documentation for the MSVC10 build of Qt or its an outright bug. Why more people haven't reported this still baffles me.

        It definitely doesn't belong in the documentation, as the crash should not happen. Like @sandy.martel23, I believe it hasn't been reported much because very few people are affected by it -- I tried to reproduce it on my system but couldn't (not that I have MSVC 2010 anymore).

        Anyway, I'm glad you can get on with your project.

        Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

        1 Reply Last reply
        0
        • D Offline
          D Offline
          DRoscoe
          wrote on last edited by
          #35

          @JKSH It can't just be a local problem either. Several other developers at my location are having the same problem. I created a very simple Win32 console app that reproduces the problem, eliminating all of the third-party libraries we use. I sent the project to another group down in Virginia and all who tried it had the same problem (our group is standardized on MSVC 2010, but we are moving to 2015 when available). What I failed to realized was that the basic console app also crashed in DEBUG, whereas our main project crashes only in RELEASE. I now believe that its a problem with MSVC 2010 only, as my MSVC 2013 project doesn't have the problem. I think the problem occurred when Qt went to UTF8 which would explain why toLatin1() and toLocal8Bit() work.

          1 Reply Last reply
          0
          • D Offline
            D Offline
            DRoscoe
            wrote on last edited by
            #36

            LAST UPDATE

            The problem is solved! Prior to installing Qt 5.4, I had been running Qt 4.8.6. This was installed with a binary installer package (not web installer). When I installed Qt 5.4, I used the web installer. It ended up installing several earlier versions of Qt as well. There were also some VC redistributables in the Qt folder. I gutted the whole thing and re-installed only Qt 5.4 clean. I installed no other versions. I rebuilt my project and ran the test again, and voila! The problem disappeared.

            The one thing in common in my case, our other internal developers and the group in Virginia is that we all started fro Qt 4.8.6 using the same installer package and upgraded via web-installer.

            S 1 Reply Last reply
            0
            • D DRoscoe

              LAST UPDATE

              The problem is solved! Prior to installing Qt 5.4, I had been running Qt 4.8.6. This was installed with a binary installer package (not web installer). When I installed Qt 5.4, I used the web installer. It ended up installing several earlier versions of Qt as well. There were also some VC redistributables in the Qt folder. I gutted the whole thing and re-installed only Qt 5.4 clean. I installed no other versions. I rebuilt my project and ran the test again, and voila! The problem disappeared.

              The one thing in common in my case, our other internal developers and the group in Virginia is that we all started fro Qt 4.8.6 using the same installer package and upgraded via web-installer.

              S Offline
              S Offline
              sandy.martel23
              wrote on last edited by
              #37

              A configuration issue ? I can't say that I'm shocked...

              I have several Qt versions installed on Windows, version 4, version 5, for 64 & 32 bits and for different VS (2010 and 2013). I would suspect those VC redistributables, if they were ot in sync with the compiler used.

              On the other hand, I only use Qts that I compile myself, so I keep a close control on access paths and get a "clean" dev install for each, no upgrades, maybe the (web) installer is mixing up versions.

              Glad you found it.

              1 Reply Last reply
              0
              • D Offline
                D Offline
                DRoscoe
                wrote on last edited by
                #38

                @sandy.martel23 When you build your Qt sources for VS2010 can you tell me how you do it? When I did it, I ended up having the same problem. Do you specify any special compiler settings?

                1 Reply Last reply
                0
                • D Offline
                  D Offline
                  DRoscoe
                  wrote on last edited by
                  #39

                  OK, this time, I have nailed down the specific line in our projects that are causing the problem:

                  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /D \"_ITERATOR_DEBUG_LEVEL=1\"")

                  Turning on STL iterator debugging is not compatible with Qt libraries. I suspect that turning this feature on when compiling Qt would solve the problem, but for now it's easier to turn it off in my own projects. It is only marginally useful.

                  S 1 Reply Last reply
                  0
                  • D DRoscoe

                    OK, this time, I have nailed down the specific line in our projects that are causing the problem:

                    SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /D \"_ITERATOR_DEBUG_LEVEL=1\"")

                    Turning on STL iterator debugging is not compatible with Qt libraries. I suspect that turning this feature on when compiling Qt would solve the problem, but for now it's easier to turn it off in my own projects. It is only marginally useful.

                    S Offline
                    S Offline
                    sandy.martel23
                    wrote on last edited by
                    #40

                    9 days ago, @sandy.martel23 said:

                    But it seems that your still mixing debug and release STL objects

                    told you :-)

                    As for building Qt, I do nothing special.

                    1 Reply Last reply
                    0
                    • HudsonH Offline
                      HudsonH Offline
                      Hudson
                      wrote on last edited by
                      #41

                      I was recently working with Qt, overridden new/delete operator, and got the similar issue.

                      It caused a problem that QByteArray::toStdString() made a std::string which avoided calling the overridden version of new.

                      However, when the std::string was destructed in my program, it called the overridden version of delete. Bomb!

                      Maybe it is a reasonable practice to avoid using std::string returned by Qt or other 3rd party library. Or you should rebuild all of them with the exactly same environment.

                      kshegunovK 1 Reply Last reply
                      0
                      • HudsonH Hudson

                        I was recently working with Qt, overridden new/delete operator, and got the similar issue.

                        It caused a problem that QByteArray::toStdString() made a std::string which avoided calling the overridden version of new.

                        However, when the std::string was destructed in my program, it called the overridden version of delete. Bomb!

                        Maybe it is a reasonable practice to avoid using std::string returned by Qt or other 3rd party library. Or you should rebuild all of them with the exactly same environment.

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

                        @Hudson said:

                        Maybe it is a reasonable practice to avoid using std::string returned by Qt or other 3rd party library.

                        Actually in your case, forgive me for being so blunt, I'd say it would be a reasonable practice to avoid writing new/delete operators for classes you don't own (i.e. such that are not written by you). And as a side note creating std::strings in the heap is a bit questionable.

                        Also I don't see how Qt could have called an overloaded new so you can call delete on it. There's no new in QByteArray::toStdString,

                        Read and abide by the Qt Code of Conduct

                        1 Reply Last reply
                        0

                        • Login

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