PDA

View Full Version : "Debug Assertion failed" in debug mode



hed
28th January 2008, 11:38
I am having problem working in debug mode with QT 4.3.0
Release works fine
but when changing to debug mode i get on really innocent lines
"Debug Assertion failed"

this line for example:

dataPath.toStdWString().c_str();
(used to be this line: CString searchPath = dataPath.toStdWString().c_str(); )

it failes on the destructor of the temporary string.
Has anyone ran into those problems?

tnx,
hed

here is the stack:


> MSVCR71D.dll!operator delete() + 0x99
MSVCP71D.dll!std::collate<unsigned short>::do_hash() + 0x2b0
MSVCP71D.dll!std::basic_string<unsigned short,std::char_traits<unsigned short>,std::allocator<unsigned short> >::_Tidy() + 0x58
MSVCP71D.dll!std::basic_string<unsigned short,std::char_traits<unsigned short>,std::allocator<unsigned short> >::~basic_string<unsigned short,std::char_traits<unsigned short>,std::allocator<unsigned short> >() + 0x13
HiroClient.exe!HiroRTLogic_PC_Specific::DeleteObso leteFiles() Line 101 C++
HiroClient.exe!HiroRTLogic_PC_Specific::BackSuppor tForOldVersions() Line 84 C++
HiroClient.exe!HiroRTLogic::Init(HiroCodecContaine r * container=0x00538eb0, bool bFromMoviePlayback=false) Line 41 C++
HiroClient.exe!CHiroClientApp::InitInstance() Line 181 + 0x4a C++
mfc71ud.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x00020c70, int nCmdShow=1) Line 39 + 0xb C++
HiroClient.exe!wWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x00020c70, int nCmdShow=1) Line 25 C++
HiroClient.exe!wWinMainCRTStartup() Line 390 + 0x39 C
kernel32.dll!RegisterWaitForInputIdle() + 0x49

wysota
28th January 2008, 12:13
Are you sure this is a Qt related problem? :) From what I see it is the STL runtime of MSVC that asserts... You are probably doing something you shouldn't be doing with the string.

hed
28th January 2008, 12:31
It's this function thats the trigger:
QString::toStdWString()

it returns std::basic_string<wchar_t> which it creates inside - and in the destructor of the temporary object i fail.

Again it's something that doesn't happen in the release. so i believe the code is ok,
and has some mistaken Assertion in debug.

it's rather a straightforward thing so i thought other here might be familiar with it.

hed

wysota
28th January 2008, 12:35
It's this function thats the trigger:
QString::toStdWString()
QString just creates an object and doesn't care about it any more. Take a look at the stack trace you provided - there is not a single reference to Qt code there.


Again it's something that doesn't happen in the release. so i believe the code is ok,
and has some mistaken Assertion in debug.
Because release applications don't assert. But it doesn't mean the code is correct. If the assert is there, it's because of a reason, I think it is safe to assume STL implementors knew what they were doing.

hed
28th January 2008, 14:05
i still think it is a QT problem - only now i can be more specific. ;-)
The fact i have a crash just means something interenally is not stable inside the QString object.
here is my test program:

QString param = "1";
QString test = QString("Test %1").arg(param);
CString test2 = test.toStdString().c_str();

everything works ok.


QString param = "111111111111111111111111";
QString test = QString("Test %1").arg(param);
CString test2 = test.toStdString().c_str();

third line fails because of the size of the arg.

Can you reproduce it?
(My environment is - Windows + MFC + ATL)
Anyone familiar with it?

hed

wysota
28th January 2008, 14:16
You clearly have an invalid code. It's the same like if you wrote:

QString str("xxxxx");
char *cstr = str.toAscii().data();
printf("%s\n", cstr);
Second line of the above code is invalid because data() returns a pointer to internal data of the byte array that gets destroyed immediately as it is a temporary object. From what I understand you are doing exactly the same in your code and Qt has nothing to do with it.

hed
30th January 2008, 08:20
it depends when the temporary variable is being killed.
the line:
CString test2 = test.toStdString().c_str();
copy the data before the temporary object is being killed and its memory released.

anyway, to better show my problem:
take a look at the following code:

QString param = "111111111111111111111111";
QString test = QString("Test %1").arg(param);
test.toStdString();

third line fails.
it's the destructor of the temprary object that fails.
Again -
there is a good chance i'm doing something wrong:
only i don't see what.

hed.

wysota
30th January 2008, 09:01
The temporary object gets destroyed immediately after the statement it was created in is finished.

If the std::strnig object is valid Qt has nothing more to do with it. Are you by any chance using VS6 to compile your project?

ChristianEhrlicher
30th January 2008, 09:33
Are you by any chance using VS6 to compile your project?

That's imho the correct question :)

Keep in mind that std::string and std::wstring are different regarding whether you compile the code in Debug or Release mode in every msvc version. So when you mix e.g. Release Qt and Debug Program or vice versa, you'll encounter a crash. But your linker should warn you about such things.
But why you need crappy std::string/wstring at all?

Rayven
31st January 2008, 20:55
To add to this growing post, I have run into similar issues when using std::string on VS2005 in debug mode. When the scope destructors are called the program aborts in the ~Tidy( ) function. This is only using std::strings and no QStrings what-so-ever. However, when I ran the same code on VS2003 it works just fine. The program also runs fine in release mode. I definatly believe it has something with VS implementation of std::string in converting it into a c_str( ). I am using Qt v4.3.0 as well, but I have to link to data libraries that return std::string's so dont assume that all people can get away from "crappy std::string/wstring". We have to make due.

hed
4th February 2008, 12:10
I am using .Net 2003
and in my case it was a Debug/Release mixing

i was compiling in debug mode while using the release QT libraries.
when changing to the debug libraries everything returned to behave normal


hed