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. Non connected signal causes crash
Forum Updated to NodeBB v4.3 + New Features

Non connected signal causes crash

Scheduled Pinned Locked Moved General and Desktop
9 Posts 3 Posters 3.2k 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.
  • K Offline
    K Offline
    koahnig
    wrote on last edited by
    #1

    emitting a signal with a custom object results in following message with a crash:
    @
    terminate called after throwing an instance of 'std::logic_error'
    what(): basic_string::_S_construct null not valid
    @
    The signal is not connected to any slot. The custom object does not contain a string object but other template objects (std).
    The compiler is MinGw 4.6.2 with Qt 4.8.3.

    Has somebody an idea?

    Vote the answer(s) that helped you to solve your issue(s)

    1 Reply Last reply
    0
    • M Offline
      M Offline
      MuldeR
      wrote on last edited by
      #2

      I think we need some code...

      My OpenSource software at: http://muldersoft.com/

      Qt v4.8.6 MSVC 2013, static/shared: http://goo.gl/BXqhrS

      Go visit the coop: http://youtu.be/Jay...

      1 Reply Last reply
      0
      • K Offline
        K Offline
        koahnig
        wrote on last edited by
        #3

        Thanks for feedback.

        The code is quite complex and hard to extract essentials.
        BTW the code does work compiled with msvc 2005 in release and debug mode. Therefore I am expecting a problem in combination with the compiler.

        Vote the answer(s) that helped you to solve your issue(s)

        1 Reply Last reply
        0
        • L Offline
          L Offline
          lgeyer
          wrote on last edited by
          #4

          Is it possible that there is an implicit conversion from <code>nullptr</code> to <code>std::string</code> somewhere in your code (which has been silently discarded by MSVC, but is now caught by GCC)?

          Does this error occour on GCC 4.7.2 as well? Could be a bug in the standard library of GCC 4.6.2.

          1 Reply Last reply
          0
          • K Offline
            K Offline
            koahnig
            wrote on last edited by
            #5

            Hi Lukas,
            neither a std::string nor a QString around there. The custom class has some custom templates with std::vector internally.
            The problem seem to occur in the destructor, but the debugger does not really show it. When the emit is being commented out, the problem disappears. I just did another test with a blind function call and there is no problem either. Possibly a mix of issues with emit playing a role.

            Thanks for sharing that there is already a newer version of GCC available. I do not understand why they are hiding the version numbers on the mingw webpage. Does not make sense to me :-(

            Vote the answer(s) that helped you to solve your issue(s)

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

              [quote author="koahnig" date="1355929296"]Thanks for feedback.

              The code is quite complex and hard to extract essentials.
              BTW the code does work compiled with msvc 2005 in release and debug mode. Therefore I am expecting a problem in combination with the compiler. [/quote]

              From experience, if you suspect there is a bug in third-party code, you quite often find the mistake in your own code, while trying to strip it down to a minimal example. And even if it really is compiler issue, we won't know for sure, unless you have clear example code that triggers the issue...

              My OpenSource software at: http://muldersoft.com/

              Qt v4.8.6 MSVC 2013, static/shared: http://goo.gl/BXqhrS

              Go visit the coop: http://youtu.be/Jay...

              1 Reply Last reply
              0
              • K Offline
                K Offline
                koahnig
                wrote on last edited by
                #7

                [quote author="MuldeR" date="1355951809"][quote author="koahnig" date="1355929296"]Thanks for feedback.

                The code is quite complex and hard to extract essentials.
                BTW the code does work compiled with msvc 2005 in release and debug mode. Therefore I am expecting a problem in combination with the compiler. [/quote]

                From experience, if you suspect there is a bug in third-party code, you quite often find the mistake in your own code, while trying to strip it down to a minimal example. And even if it really is compiler issue, we won't know for sure, unless you have clear example code that triggers the issue...[/quote]

                Yes, I know. You are using similar words as I have used already in this forum.

                Following are the current facts:

                • As stated above, the code was running as debug and release compilations of msvc 2005.
                • It can be limited to a single emit not leading anywhere.
                • The class is in use for a couple of years with only minor changes in the non-complex part. It is a central part of the code and nothing used rarely.
                • The class has been used in MinGW 4.4 (the one being part of Qt SDK) at least compilations for some tests. However, the emit was not part of those tests.
                • Elimination of the emit and using a blind function call runs smoothly. The question is: does the compiler notice that I am trying to fool it even so it is a debug compilation?

                Nothing a 100% conclusive yet in my opinion :-(

                At the moment I am following Lukas' hint with the newer version of MinGW 4.7.2 which requires unfortunately a complete recompilation of Qt libs and my code.

                Vote the answer(s) that helped you to solve your issue(s)

                1 Reply Last reply
                0
                • L Offline
                  L Offline
                  lgeyer
                  wrote on last edited by
                  #8

                  Yes, MinGW can be quite a bit "'arduous'":http://qt-project.org/wiki/MinGW-64-bit sometimes, especially when it comes to Qt5.

                  1 Reply Last reply
                  0
                  • K Offline
                    K Offline
                    koahnig
                    wrote on last edited by
                    #9

                    The exact same thing with MinGW 4.7.2 :-(
                    The possible requirement to recompile everything once again with another compiler damps a bit my enthusiasm to continue.
                    In my opinion the problem occurs through the combination of different factors. This makes it hard to blame on any of the pieces involved. Ultimately the emit of Qt is the one drop too much for the barrel.

                    I have decided to the signal's argument list from "const object & " to a variant of shared pointer. This certainly solves the problem for me.

                    Vote the answer(s) that helped you to solve your issue(s)

                    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