[Interest] Can't Debug on Windows 7: Invalid parameter passed to C runtime

[Josiah Bryan]

I'm attempting to debug an odd problem wherein my program (http://
code.google.com/p/dviz/) crashes when displaying certain UTF-8 strings.
That's not really why I'm emailing - the problem I'd like your help with is
that I'm unable to run the program in "Debug" mode in Qt Creator on Windows
7.


I've set the project in Qt Creator to the "Debug" build and tried to run it
in the Debugger (F5). The program builds and launches - however, before the
main UI can appear, an error dialog titled "Microsoft Visual C++ Runtime
Library" appears giving the following error: "This application has
requested the Runtime to terminate in an unusual way. Please contact the
application's support team for more information."


Below the console output from Qt Creator. As you can guess, it *does* run
correctly in "Release" mode in Qt Creator (just crashes when the user
performs a certain UI action - hence why I want to run it in Debug mode.
Note that it does not crash on linux in gdb or in release mode - so this is
specific to Windows and the debugger in Qt Creator.)


You'll note there are comments in the console output below regarding
constructing QApplication before QPaintDevice and other references to
QApplication - well, I don't know why it's complaining about that, because
QApplication is created on the second line of code to be executed in in
main() - see
http://code.google.com/p/dviz/source/browse/trunk/src/main.cpp#36 for proof.


In short, I can't run in the Debugger to trace the crash in Release,
because the debugger crashes before the program even starts. (And the
debugger doeesn't give a stack trace to indicate where the MSVC runtime
freaks out at.)


Any thoughts on what I can do to fix this or at least track down the
problem more accurately so I can get the program to execute in the debugger?


Console output:


Debugging starts

SlideTemplateManager::loadOrCreate( 0 ): file:
"C:/Users/JosiahBryan/DVizUserTemplates.dviz"

QObject: Cannot create children for a parent that is in a different thread.

(Parent is NativeViewerPhonon(0x895c780), parent's thread is
QThread(0x7065da0), current thread is QThread(0x990a7d8)

QCoreApplication::applicationFilePath: Please instantiate the QApplication
object first

QObject: Cannot create children for a parent that is in a different thread.

(Parent is NativeViewerPhonon(0x895c780), parent's thread is
QThread(0x7065da0), current thread is QThread(0x990a7d8)

QWidget: Must construct a QApplication before a QPaintDevice

Invalid parameter passed to C runtime function.

Invalid parameter passed to C runtime function.

[André Pönitz]

Post by Josiah Bryan
I'm attempting to debug an odd problem wherein my program (http://
code.google.com/p/dviz/) crashes when displaying certain UTF-8
strings. That's not really why I'm emailing - the problem I'd like
your help with is that I'm unable to run the program in "Debug" mode
in Qt Creator on Windows 7.
I've set the project in Qt Creator to the "Debug" build and tried to
run it in the Debugger (F5). The program builds and launches -
however, before the main UI can appear, an error dialog titled
"Microsoft Visual C++ Runtime Library" appears giving the following
error: "This application has requested the Runtime to terminate in an
unusual way. Please contact the application's support team for more
information."
Below the console output from Qt Creator. As you can guess, it does
run correctly in "Release" mode in Qt Creator (just crashes when the
user performs a certain UI action - hence why I want to run it in
Debug mode. Note that it does not crash on linux in gdb or in release
mode - so this is specific to Windows and the debugger in Qt Creator.)

Assuming that the "release" mode takes roughly the same code path
as the "debug" mode (i.e. no major #ifdef surgery in your code),
the problems that are indicated by the output

QObject: Cannot create children for a parent that is in a different
thread. [...]

QCoreApplication::applicationFilePath: Please instantiate the
QApplication object first [...]

QWidget: Must construct a QApplication before a QPaintDevice

Invalid parameter passed to C runtime function.

They would exist in "release" mode as well. So it does not run
"correctly" there, rather "by accident".

Post by Josiah Bryan
You'll note there are comments in the console output below regarding
constructing QApplication before QPaintDevice and other references to
QApplication - well, I don't know why it's complaining about that,
because QApplication is created on the second line of code to be
executed in in main() - see
http://code.google.com/p/dviz/source/browse/trunk/src/main.cpp#36 for proof.

The second line of 'main' is not the second line of code that ie
executed. There are things like constructions of global objects
that go before 'main'.

Start with tracking down global objects, avoid them, or at the
very least don't do anything that needs a fully constructed
Q[Core]Application. Check your thread creation and thread affinity
of your QObjects.

Andre'

[Josiah Bryan]

Post by André Pönitz

Post by Josiah Bryan
I'm attempting to debug an odd problem wherein my program (http://
code.google.com/p/dviz/) crashes when displaying certain UTF-8
strings. That's not really why I'm emailing - the problem I'd like
your help with is that I'm unable to run the program in "Debug" mode
in Qt Creator on Windows 7.
I've set the project in Qt Creator to the "Debug" build and tried to
run it in the Debugger (F5). The program builds and launches -
however, before the main UI can appear, an error dialog titled
"Microsoft Visual C++ Runtime Library" appears giving the following
error: "This application has requested the Runtime to terminate in an
unusual way. Please contact the application's support team for more
information."
Below the console output from Qt Creator. As you can guess, it does
run correctly in "Release" mode in Qt Creator (just crashes when the
user performs a certain UI action - hence why I want to run it in
Debug mode. Note that it does not crash on linux in gdb or in release
mode - so this is specific to Windows and the debugger in Qt Creator.)

Assuming that the "release" mode takes roughly the same code path
as the "debug" mode (i.e. no major #ifdef surgery in your code),
the problems that are indicated by the output

Correct, no #ifdef's for debug mode - a few for Windows/Linux, but
that's about it.

Post by André Pönitz
QObject: Cannot create children for a parent that is in a different
thread. [...]
QCoreApplication::applicationFilePath: Please instantiate the
QApplication object first [...]
QWidget: Must construct a QApplication before a QPaintDevice
Invalid parameter passed to C runtime function.
They would exist in "release" mode as well. So it does not run
"correctly" there, rather "by accident".

Perhaps - the thing is, these errors are not generated in Release mode
- e.g. no complains about instantiating a QApplication first, QWidget
doesn't complain about a QApplication before a QPaintDevice - given
that they are running the same code path, wouldn't these errors output
in Release mode as well?

Post by André Pönitz

Post by Josiah Bryan
You'll note there are comments in the console output below regarding
constructing QApplication before QPaintDevice and other references to
QApplication - well, I don't know why it's complaining about that,
because QApplication is created on the second line of code to be
executed in in main() - see
http://code.google.com/p/dviz/source/browse/trunk/src/main.cpp#36 for proof.

The second line of 'main' is not the second line of code that ie
executed. There are things like constructions of global objects
that go before 'main'.

Granted. However, None of *my* code is executed prior to QApplications
creation - any global static objects are created using a static
::instance() model (check static pointer at call time, create if not
exists at that time) - sort of like a "pull" model to create any
needed global pointers.

The real problem here is that Qt Creator / Debugger doesn't even
bother to give a stack trace of where it stopped at - just the MSVC
error dialog, no stack trace. If it would just give some info about
*where* it stopped, I could trace it from there. As it sits now, I'm
flailing in the dark at more than 50K SLOC. Any thoughts as to why no
stack trace from the debugger?

Post by André Pönitz
Start with tracking down global objects, avoid them, or at the
very least don't do anything that needs a fully constructed
Q[Core]Application. Check your thread creation and thread affinity
of your QObjects.

I'll double-check globals, but a stack trace is really what's needed
here anyway - debugger just says "Application exited with exit code
exit-code="03"" (Yes, I googled that - no, the only three results I
found did not help.)

Thanks for your help and advice!
-Josiah

[Till Oliver Knoll]

Post by Josiah Bryan
...
I'll double-check globals, but a stack trace is really what's needed
here anyway - debugger just says "Application exited with exit code
exit-code="03"" (Yes, I googled that - no, the only three results I
found did not help.)

What compiler do you use? The MS Visual Studio compiler? If so, double check that you link against the proper C runtime libraries: debug vs release, single vs multithread support. Any mix can lead to spurious problems you have described. (Just a first rough guess)

Cheers,
Oliver

[Andreas Pakulat]

Hi,

On Thu, Jun 14, 2012 at 8:13 AM, Till Oliver Knoll <

Post by Till Oliver Knoll

Post by Josiah Bryan
...
I'll double-check globals, but a stack trace is really what's needed
here anyway - debugger just says "Application exited with exit code
exit-code="03"" (Yes, I googled that - no, the only three results I
found did not help.)

What compiler do you use? The MS Visual Studio compiler? If so, double
check that you link against the proper C runtime libraries: debug vs
release, single vs multithread support. Any mix can lead to spurious
problems you have described. (Just a first rough guess)

In particular make sure you use the same runtime as the Qt libraries. So if
your Qt links against the release runtime, your app has to do that too (no
matter wether you compile with or without debug-symbols) and vice-versa. Qt
debug libraries on Windows are usually having a 'd' suffix in their name.

I would expect qmake to take care of that though, when you switch your .pro
file from release to debug mode.

Andreas

[Josiah Bryan]

Post by Andreas Pakulat
Hi,
On Thu, Jun 14, 2012 at 8:13 AM, Till Oliver Knoll <

Post by Till Oliver Knoll

Post by Josiah Bryan
...
I'll double-check globals, but a stack trace is really what's needed
here anyway - debugger just says "Application exited with exit code
exit-code="03"" (Yes, I googled that - no, the only three results I
found did not help.)

What compiler do you use? The MS Visual Studio compiler? If so, double
check that you link against the proper C runtime libraries: debug vs
release, single vs multithread support. Any mix can lead to spurious
problems you have described. (Just a first rough guess)

In particular make sure you use the same runtime as the Qt libraries. So
if your Qt links against the release runtime, your app has to do that too
(no matter wether you compile with or without debug-symbols) and
vice-versa. Qt debug libraries on Windows are usually having a 'd' suffix
in their name.
I would expect qmake to take care of that though, when you switch your
.pro file from release to debug mode.

I'm just using Qt Creator and (I assume) Mingw - I installed the Qt SDK
with it's default settings, so however it configured Qt Creator - that's
what I use.

I would assume that Qt Creator / qmake is taking care of using the proper
debug libraries, wouldn't it?

[Josiah Bryan]

On Thu, Jun 14, 2012 at 9:44 AM, Till Oliver Knoll <

Post by Josiah Bryan

Post by Andreas Pakulat

...
What compiler do you use? The MS Visual Studio compiler? ...

In particular make sure you use the same runtime as the Qt libraries.
...

I'm just using Qt Creator and (I assume) Mingw - I installed the Qt SDK

with

Post by Josiah Bryan
it's default settings, so however it configured Qt Creator - that's what

I

Post by Josiah Bryan
use.

[...]
By the way: when questions like these come up ("with what runtime does
your executable/library link?") you should become best friend with
"Dependency Walker". It is either part of the Visual Studio package
(not sure about the "Express" edition) or the Windows SDK (or both,
can't remember) - all available from the MS download website of your
http://dependencywalker.com/
[...]
Yes, that's right (still: use depends.exe on your own binary and make
sure you have a consistent linking, debug vs release. As Anreas
already pointed out at least the Qt libraries have a -d.dll naming
pattern for their debug libraries.
By the way, the actual problem is not when you build your application
in, say, debug mode, but link against a *release* version of Qt - as
long as one one single C/C++ runtime library is pulled in! And *that*
is giving you serious problems, as soon as you have a debug C/C++
runtime library pulled in by your binary, but another C/C++ runtime
library in release mode! Memory allocated in the one library can't be
free'd in the other, since you end up with separate heap spaces etc. -
and that is almost impossible to debug. The system might simply freak
out and terminate your process.
Mixing debug and release Qt libraries - QtCored (debug) and QtGui
(release), for instance - is also not a good idea, because the QtGui
would still link against a release QtCore instance, and since those
libraries usually keep global instances which should better be unique
- bang!

[...]


Thanks to your suggestion and my new best friend, depends.exe, I see all
the Qt libs are linking correctly to the "-d" version - **except* for
phonon! *Depends.exe shows while the rest of the libs are debug versions,
the phonon lib is "phonon4.dll" - whats up with that? Why would qmake/Qt
Creator be linking the debug versions of the Qt libs, but the release
version of phonon?

If that doesn't help: Do the usual "Remove everything and rebuild"
trick! Sometimes some old *.obj object files linger around and get
linked into your binary. So also make sure that all moc_* etc.
generated files are deleted (somewhere under "Build" -> "Clean All" or
"Dist Clean" or something).

Already did that yesterday before emailing this list - no luck there. I've
even installed Qt creator on a fresh PC (never before had Qt on it) and
checked out a fresh copy of my project source - same problem when trying to
run in debug mode.

Next: Strip down your project to the very minimum: comment out
everything in your main function but e.g.
QApplication app(argc, argv);
...
// everything else commented out
..
qDebug("Set a breakpoint here!");
return app.exec();
Set a breakpoint at the qDebug line, recompile and debug. If that
works (and I sure hope so), start re-enabling your code and see where
it starts getting messy.

Doing that right now - my work in this direction has also pointed me toward
phonon as the problem, tho I'm still trying to narrow down the exact line
of code. So, I guess it goes back to why is phonon4.dll being used and not
the debug version?

Cheers!
-Josiah

[André Pönitz]

Post by Josiah Bryan
The real problem here is that Qt Creator / Debugger doesn't even
bother to give a stack trace of where it stopped at - just the MSVC
error dialog, no stack trace.

[...]

Post by Josiah Bryan
I'll double-check globals, but a stack trace is really what's needed
here anyway - debugger just says "Application exited with exit code
exit-code="03"" (Yes, I googled that - no, the only three results I
found did not help.)

This means that it looks like the program "just exited", maybe with an
error code, but still, all stack is gone at that time. You could try to
set a breakpoint on something that might happen before that. There are a
few "special" choices in the debugger options. Or go the other way
round, set an early breakpoint (on main, or even on the entry point)
and step from there.

Andre'

[Josiah Bryan]

On Fri, Jun 15, 2012 at 3:17 AM, André Pönitz <

Post by André Pönitz

Post by Josiah Bryan
The real problem here is that Qt Creator / Debugger doesn't even
bother to give a stack trace of where it stopped at - just the MSVC
error dialog, no stack trace.

[...]

Post by Josiah Bryan
I'll double-check globals, but a stack trace is really what's needed
here anyway - debugger just says "Application exited with exit code
exit-code="03"" (Yes, I googled that - no, the only three results I
found did not help.)

This means that it looks like the program "just exited", maybe with an
error code, but still, all stack is gone at that time. You could try to
set a breakpoint on something that might happen before that. There are a
few "special" choices in the debugger options. Or go the other way
round, set an early breakpoint (on main, or even on the entry point)
and step from there.

I've narrowed the problem down (thanks to earlier suggestions) and found
that it's caused by Qt/qmake/etc linking the non-debug version of
"phonon4.dll" even though the rest of the Qt libs *are* the debug version.
Any idea how to fix *that*? Or should I start another thread here?

Thanks!
-Josiah

[Josiah Bryan]

On Wed, Jun 13, 2012 at 5:50 PM, André Pönitz <

Post by André Pönitz

Post by Josiah Bryan
I'm attempting to debug an odd problem wherein my program (http://
code.google.com/p/dviz/) crashes when displaying certain UTF-8
strings. That's not really why I'm emailing - the problem I'd like
your help with is that I'm unable to run the program in "Debug" mode
in Qt Creator on Windows 7.
I've set the project in Qt Creator to the "Debug" build and tried to
run it in the Debugger (F5). The program builds and launches -
however, before the main UI can appear, an error dialog titled
"Microsoft Visual C++ Runtime Library" appears giving the following
error: "This application has requested the Runtime to terminate in an
unusual way. Please contact the application's support team for more
information."
Below the console output from Qt Creator. As you can guess, it does
run correctly in "Release" mode in Qt Creator (just crashes when the
user performs a certain UI action - hence why I want to run it in
Debug mode. Note that it does not crash on linux in gdb or in release
mode - so this is specific to Windows and the debugger in Qt Creator.)

Assuming that the "release" mode takes roughly the same code path
as the "debug" mode (i.e. no major #ifdef surgery in your code),
the problems that are indicated by the output
QObject: Cannot create children for a parent that is in a different
thread. [...]
QCoreApplication::applicationFilePath: Please instantiate the
QApplication object first [...]
QWidget: Must construct a QApplication before a QPaintDevice
Invalid parameter passed to C runtime function.
They would exist in "release" mode as well. So it does not run
"correctly" there, rather "by accident".

I just looked at the thread errors - that's a problem in Qt's codebase,
specifically inside Phonon - I don't create any threads at the spot it's
complaining about.
http://code.google.com/p/dviz/source/browse/trunk/src/phonon/NativeViewerPhonon.cpp
-
but I do create several Phonon objects which could (very likely) create
threads internally.

If I could only figure out where the QWidget error (above) is coming from
and the QCoreApplication::applicationFilePath error is from - that would be
helpful. Heck, I don't even call applicationFilePath once in my entire
codebase - so that's somewhere in Qt again.

Yes, I do use QWidgets (duh :-) but tracking down *which* call to a new
QWidget caused the above error - that's the rub.
-Josiah