Crash when trying to start KMyMoney with QT 4.7.3 debug version
-
I've enabled debugging using
@
DYLD_IMAGE_SUFFIX=_debug
@
but when I am running KMyMoney in Xcode's gdb I get this error right at the start:
@
---gdb-output---
QWidget: Must construct a QApplication before a QPaintDevice
Program received signal: “SIGABRT”.@
I was wondering whether this could be caused by QT itself (since I've found this hint on this site: http://developer.qt.nokia.com/wiki/Mac_OS_X_Troubleshooting) or whether KMyMoney code would be to blame here.I sort of believe that KMyMoney is NOT the culprit, since I cannot see any explicit QPaintDevice construction before QApplication, which I figured is inherently done by kdelibs4's KXmlGuiWindow::setupGUI().
-
Maybe a false mixup of libraries (mixing release and debug versions). This can be caused by the DYLD_IMAGE_SUFFIX=_debug.
-
I had a similar problem that reared its ugly head for me when I was switching compilers from MinGw to MSVC on windows. Certain things like initialization order of resources are different between compilers. That can trigger bugs like these. It might be that the application is initialising resources like pixmaps (perhaps in the form of a QIcon?) statically. That may work fine on compiler A, but leads to this issue on compiler B.
Such a thing may be the issue you're running into.
-
[quote author="Volker" date="1307921017"]Maybe a false mixup of libraries (mixing release and debug versions). This can be caused by the DYLD_IMAGE_SUFFIX=_debug.[/quote]
I wonder what defines a "false mixup" (probably all QT-related libs should be accessed in their debug version) and how I could verify it. "otool -L" is probably my friend.
-
[quote author="Andre" date="1307951874"]I had a similar problem that reared its ugly head for me when I was switching compilers from MinGw to MSVC on windows. ... That may work fine on compiler A, but leads to this issue on compiler B. [/quote]
Well, that sounds like it, since on Linux you won't see this issue at all.[quote author="Andre" date="1307951874"]It might be that the application is initialising resources like pixmaps (perhaps in the form of a QIcon?) statically.[/quote]
I see for instance on MacOSX warnings like these during startup of KMyMoney4:
@
QPainter::setPen: Painter not active
QPainter::font: Painter not active
QPainter::setFont: Painter not active
@
... actually THOUSANDS of lines of these!This might indicate that there is something like that what you are describing going on here. See https://bugs.kde.org/show_bug.cgi?id=256913
It doesn't happen on Linux.
-
The above mentioned warnings appear - as I now remembered - only at a later stage of the application startup (main window is already shown, data file is loaded). So, these messages are surely not linked to the initially described problem.
-
I have tons of messages like these popping up when starting gdb:
@
objc[20856]: Class QCocoaColorPanelDelegate is implemented in both /opt/macports-test/lib/libQtGui.4.7.3.dylib and /opt/macports-test/lib/libQtGui_debug.4.7.3.dylib. One of the two will be used. Which one is undefined.
@
so, it looks like I haven't convinced KMyMoney to solely use the the debug libraries.What can I do to ensure that only the _debug libs are being used?
-
You have to tell every Qt library involved to use the debug versions.
I recommend to use the release versions of the Qt libs.
If you reallly need the debug versions of the Qt libs (e.g. to debug those), I recommend installing a debug only build of Qt and build everything against this.
Otherwise you will have to track all the dependencies to make them use the Qt debug libs too. If you miss just one, you'll run into the now well known problems.
Sorry to give no better advice that causes less work.
-
I had the idea that telling the QT library to use its debug version by setting
@
DYLD_IMAGE_SUFFIX=_debug
@
in the environment.It looks like I am wrong here?
-
I never used that. I'm not sure if it works as expected in your use case.
-
It doesn't that's what many post here on QTdev and elsewhere say.
I wonder how I can make my app really link against the *_debug libraries.
I used
@
cmake .. -DCMAKE_BUILD_TYPE=DebugFull
@
but that obviously did not link my executable statically to the debug version of the libs.Do you have a hint how to configure??
I would really like to get this going, since that would help greatly to find other QT bugs, like https://bugs.kde.org/show_bug.cgi?id=276066 and others...
Any help welcome, Volker!
-
Sorry, I'm bailing out here ... I never dug that deep into debugging Qt.
-
Sad, but thanks for all your efforts up to now. :-)
