std::string destructor crashing in Release when using ::toStdString methods
-
@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.
-
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.
-
@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.
-
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.
-
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.
-
@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?
-
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.
-
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.
-
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.
-
@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
newso you can calldeleteon it. There's nonewinQByteArray::toStdString,
