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

DRoscoe

I posted almost the exact same pseudocode in my original post, and yes I have already tried this in code, as I alluded to in a follow-up post. On my system it crashes, which is a Windows system. I don't have this problem on the Mac. This is a problem (for me) on the Windows platform using MSVC2010.

sandy.martel23

Qt and your code are probably not compiled with the same STL version. Something like this:
http://stackoverflow.com/questions/14090341/difference-in-byte-size-of-stl-containers-in-visual-studio-2010-and-2012

DRoscoe

@sandy.martel23 said:

http://stackoverflow.com/questions/14090341/difference-in-byte-size-of-stl-containers-in-visual-studio-2010-and-2012

I recompiled the Qt Library from source using the same compiler and that did not solve the problem. I am trying different C++11 options now to see if that's implicated

DRoscoe

I think I might be on the right track to figuring out what's going on. My project builds three executables. I recreated the same code that causes a crash in the problem executable in another of the remaining executables and the crash is not reproducible there. This leads me to suspect there is an alignment issue or something else that is affecting ONLY this one executable.

DRoscoe

My previous assertion that only one executable had the problem was false. I quickly mocked up the following in the main method of all three executables and got similar results:

using std::string;

int main(int argc, char *argv[])
{
  {
    QString temp("blah");
    string temp_str = temp.toStdString();
    std::cout << temp_str << std::endl;
    std::cout << "blah2" << std::endl;
    string temp_str2 = temp_str;
    temp_str2.append("a");
    std::cout << temp_str2 << std::endl;
  }

The output:

£♫  â─♦â° un §$
blah2
£♫  â─♦â° un §$a

As you can see, the string is already junk when it's streamed to std::cout but looks fine in the watch list in the debugger. The string literal outputs fine. The copying of temp_str to temp_str2 does not crash, nor does the append call, as evidenced by the last line. When the code goes out of scope, the crash occurs as normal. This suggests that even the original call to temp.toStdString() resulted in what looked like a valid string, but the std::cout results and the copy output clearly shows that something is wrong even before we go out of scope.

alex_malyu

Do you have MSVC10 service packs installed?
I remember MSVC10 in 64 bit had a nasty bug which took microsoft about a year to fix.

DRoscoe

I'm running 10.0.40219.1 SP1Rel

I have many other large legacy projects which don't have any problems with STL in general. It's just the use of Qt's STL conversions that are presenting a problem.

alex_malyu

SP1 should have solved the problem I mentioned, so it is not it.

sandy.martel23

@DRoscoe said:

I recompiled the Qt Library from source using the same compiler and that did not solve the problem.

But it seems that your still mixing debug and release STL object.
sizeof( debug std::string ) != sizeof( release std::string ).

DRoscoe

DependencyWalker has confirmed I am not using Debug STL libraries. However, I will use the sizeof() test as you suggest. At this point, I'll try anything!

DRoscoe

I ran the test and the results support DependencyWalker:

21:47:49.858 INFO: SIZE OF STD::STRING (DEBUG): 32
21:51:34.968 INFO: SIZE OF STD::STRING (RELEASE): 32

JKSH

Hi @DRoscoe,

Did you run your RELEASE program inside the IDE, or by double-clicking the executable?
Could you post the contents of your PATH?

   QString temp("blah");
   string temp_str = temp.toStdString();
   std::cout << temp_str << std::endl;
   std::cout << "blah2" << std::endl;
   string temp_str2 = temp_str;
   temp_str2.append("a");
   std::cout << temp_str2 << std::endl;

The output:

£♫ â─♦â° un §$
blah2
£♫ â─♦â° un §$a

There's something very wrong indeed. What happens when you:

Print through qDebug() instead of std::cout?
Print the QString itself?
Do an indirect conversion that bypasses QString::toStdString()?

QString temp;
QByteArray arr = temp.toUtf8();
std::string temp_str(arr.data());

qDebug() << temp;
qDebug() << arr;
qDebug() << temp_str.c_str();

At this point, I'll try anything!

One other thing I can think of is to install the MinGW version of Qt and use that to build you project. The binaries are very different, and might free you from the strange string issue.

DRoscoe

I modified the code as suggested:

  {
    QString temp("blah");
    qDebug() << "QString: " << temp;
    string temp_str = temp.toStdString();
    qDebug() << "TEMP_STR: " << temp_str.c_str();
    qDebug() << "blah2";
    string temp_str2 = temp_str;
    temp_str2.append("a");
    qDebug() << temp_str2.c_str();
  }

In this case, the copy from temp_str to temp_str2 caused the crash. The output from what did execute:

QString:  "blah"
TEMP_STR:
blah2

In both tests, I ran from the IDE, since the behavior is easily reproducible. However, I also ran it from the command line with the same results. Here is the contents of my PATH variable:

C:\Users\roscoe.NASALAB>echo %PATH%
C:\Python27\;C:\Python27\Scripts;C:\Perl64\site\bin;C:\Perl64\bin;C:\Program Fil
es (x86)\IBM\RationalSDLC\common;C:\Program Files (x86)\Intel\iCLS Client\;C:\Pr
ogram Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System3
2\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\Intel(
R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Manage
ment Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Com
ponents\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\I
PT;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\
Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\D
TS\Binn\;C:\Program Files (x86)\IBM\RationalSDLC\ClearCase\bin;C:\Program Files\
SourceGear\Common\DiffMerge\;C:\Program Files\Microsoft Windows Performance Tool
kit\;C:\Program Files (x86)\Common Files\Plantronics\;C:\Program Files (x86)\Pla
ntronics\MyHeadsetUpdater\;C:\Program Files (x86)\Plantronics\VoyagerEdge\;C:\Pr
ogram Files\IBM\RationalPurifyPlus;C:\Ruby21\bin;%APPDATA%\Python\Scripts

Using an indirect conversion as you suggest would not be convenient, thus I've avoided it, but may be my only option. I implemented the following:

  {
    QString temp("blah");
    QByteArray arr = temp.toUtf8();
    std::string temp_str(arr.data());

    qDebug() << temp;
    qDebug() << arr;
    qDebug() << temp_str.c_str();
  }

The program did not crash and the output:

"blah"
"blah"
blah

I could try the minGW version, but I have concerns. Our Visual Studio projects are generated using CMake. The CMake scripts generate our project files for Windows, Linux/Unix and MacOS. I am fairly certain it can handle an output compatible with MinGW, but may introduce difficulties if changes need to be made, as the ripples could cause us to rework the scripts to maintain the ability to generate project files for the other platforms. Again, I may have no other option, so I won't discount it.

Another thing I have not considered, we use the Adaptive Communications Environment (ACE) which is a public-domain, platform-independent middleware that abstracts our threading, networking and many other tasks. This requires that our executables have ACE_main as its entry point. Since its only an entry point to the main execution thread, I doubt it's implicated, but I do plan on trying a sample app without it to remove this variable to be certain. Nothing is making sense, so it's worth a shot. Without a fix for this problem our project is dead in the water with a deadline looming.

JKSH

@DRoscoe said:

In this case, the copy from temp_str to temp_str2 caused the crash. The output from what did execute:
QString:  "blah"
TEMP_STR:
blah2

There's no doubt then that the std::string is being constructed with invalid data (possibly with an invalid char* pointer).

Here is the contents of my PATH variable:

I was looking for common crash culprits in Qt-based projects, but didn't find any in your PATH. I don't recognize a number of the tools you're using though.

Using an indirect conversion as you suggest would not be convenient, thus I've avoided it, but may be my only option.
...
The program did not crash and the output:
"blah"
"blah"
blah

Ok, we now have one workaround, at least.

The implementation of QString::toStdString() is pretty straightforward:

Maybe try temp.toUtf8().toStdString() and see if that avoids the crash. If so, perhaps you can do a find-and-replace.

I could try the minGW version, but I have concerns.

Agreed; that is a drastic change. I would use the multi-step conversion, personally.

Another thing I have not considered, we use the Adaptive Communications Environment (ACE).... I do plan on trying a sample app without it to remove this variable to be certain.

Yes, do test it.

DRoscoe

I tested the shorthand conversion you suggested with the same result. I have also confirmed that the ACE_main entry is not causing a problem. What I have done is implement a static function to do the conversion you gave me, that I've already confirmed works. I hate not having a proper solution for this, but at least I can move forward.

I'm not going to mark this one as solved, as it technically is not. I am planning on trying this on MSVC 2013 to see if it makes a difference.

Thanks!

JKSH

@DRoscoe:

You're welcome :)

I tested the shorthand conversion you suggested with the same result. I have also confirmed that the ACE_main entry is not causing a problem.

Very very strange. It appears that an QByteArray::toStdString() doesn't work on rvalues in your system. I've never seen this before.

(For academic curiosity, I'm tempted to try qDebug() << QByteArray("blah").toStdString();)

I am planning on trying this on MSVC 2013 to see if it makes a difference.

If you have time and a fresh PC, try the same compiler version and Qt version on the fresh PC. I'm curious to know if the corruption is due to your environment, or a long-standing and undetected bug.

But, I know you have a deadline to meet; these experiments aren't crucial. (I did try string temp_str = temp.toStdString(); qDebug() << "TEMP_STR: " << temp_str.c_str(); on my machine (MSVC 2013 32-bit, Qt 5.4.1) but it was fine in both Debug and Release mode.)

Anyway, all the best!

DRoscoe

" (For academic curiosity, I'm tempted to try qDebug() << QByteArray("blah").toStdString();)"

I tried this with the same result. I had to add .c_str() as QDebug does not support std::string

"If you have time and a fresh PC, try the same compiler version and Qt version on the fresh PC. I'm curious to know if the corruption is due to your environment, or a long-standing and undetected bug."

I probably won't have time to try this fully, but I do know other developers in our group are experiencing the same problem

UPDATE: I created an empty MSVC2010 console application project that does nothing but bring in QT5Core and a few other Qt support libraries and tried it from there. Same behavior. It's something very basic and fundamental. I'd say it was a Qt bug, but that wouldn't explain why more people aren't having the same problem. With the simpler project, its even crashing in DEBUG

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!

sandy.martel23

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

JKSH

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.