Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Crash when trying to start KMyMoney with QT 4.7.3 debug version
Forum Updated to NodeBB v4.3 + New Features

Crash when trying to start KMyMoney with QT 4.7.3 debug version

Scheduled Pinned Locked Moved General and Desktop
13 Posts 3 Posters 4.6k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    mkae
    wrote on last edited by
    #1

    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().

    1 Reply Last reply
    0
    • G Offline
      G Offline
      goetz
      wrote on last edited by
      #2

      Maybe a false mixup of libraries (mixing release and debug versions). This can be caused by the DYLD_IMAGE_SUFFIX=_debug.

      http://www.catb.org/~esr/faqs/smart-questions.html

      1 Reply Last reply
      0
      • A Offline
        A Offline
        andre
        wrote on last edited by
        #3

        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.

        1 Reply Last reply
        0
        • M Offline
          M Offline
          mkae
          wrote on last edited by
          #4

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

          1 Reply Last reply
          0
          • M Offline
            M Offline
            mkae
            wrote on last edited by
            #5

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

            1 Reply Last reply
            0
            • M Offline
              M Offline
              mkae
              wrote on last edited by
              #6

              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.

              1 Reply Last reply
              0
              • M Offline
                M Offline
                mkae
                wrote on last edited by
                #7

                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?

                1 Reply Last reply
                0
                • G Offline
                  G Offline
                  goetz
                  wrote on last edited by
                  #8

                  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.

                  http://www.catb.org/~esr/faqs/smart-questions.html

                  1 Reply Last reply
                  0
                  • M Offline
                    M Offline
                    mkae
                    wrote on last edited by
                    #9

                    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?

                    1 Reply Last reply
                    0
                    • G Offline
                      G Offline
                      goetz
                      wrote on last edited by
                      #10

                      I never used that. I'm not sure if it works as expected in your use case.

                      http://www.catb.org/~esr/faqs/smart-questions.html

                      1 Reply Last reply
                      0
                      • M Offline
                        M Offline
                        mkae
                        wrote on last edited by
                        #11

                        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!

                        1 Reply Last reply
                        0
                        • G Offline
                          G Offline
                          goetz
                          wrote on last edited by
                          #12

                          Sorry, I'm bailing out here ... I never dug that deep into debugging Qt.

                          http://www.catb.org/~esr/faqs/smart-questions.html

                          1 Reply Last reply
                          0
                          • M Offline
                            M Offline
                            mkae
                            wrote on last edited by
                            #13

                            Sad, but thanks for all your efforts up to now. :-)

                            1 Reply Last reply
                            0

                            • Login

                            • Login or register to search.
                            • First post
                              Last post
                            0
                            • Categories
                            • Recent
                            • Tags
                            • Popular
                            • Users
                            • Groups
                            • Search
                            • Get Qt Extensions
                            • Unsolved