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. QSharedPointer, qRegisterMetaType, GDB and slots
Forum Updated to NodeBB v4.3 + New Features

QSharedPointer, qRegisterMetaType, GDB and slots

Scheduled Pinned Locked Moved General and Desktop
19 Posts 5 Posters 7.2k Views 3 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.
  • julio.cruzJ julio.cruz

    @jeffdag,
    By chance I just saw the new messages in this post. My setup is similar to yours.
    Did you solve your issue?
    I suggest to create a empty project and add the QGraphicsScene to find the cause. Fortunately, you get same results at remote with ssh.
    Right now, I'm dealing with another issue. Debugging with QT Creator the GDB show a SEG FAULT (without any reference to source code), and using the same program, the GDB at remote (using ssh or serial console) don't show SEG-FAULT.

    kshegunovK Offline
    kshegunovK Offline
    kshegunov
    Moderators
    wrote on last edited by
    #9

    @julio.cruz said:

    By chance I just saw the new messages in this post.

    You could subscribe to your posts (there's an option at the profile page somewhere) so you get notifications on new messages.

    Debugging with QT Creator the GDB show a SEG FAULT (without any reference to source code)

    You should at least get a stack trace, no?

    Read and abide by the Qt Code of Conduct

    1 Reply Last reply
    0
    • julio.cruzJ Offline
      julio.cruzJ Offline
      julio.cruz
      wrote on last edited by
      #10

      Hi kshegunov,

      Done about the notifications. Thanks for the suggestion.
      About the segmentation fault, I described the stack trace below. Maybe new suggestions could arise.
      Appreciated your feedback.
      Thanks

      Custom application (GDB remote)
      The stack trace of the custom application is:

      Level Function File Line
      1        ??
      2        ?? 
      
      • Screenshot of QT Creator during the SIGSEG: http://postimg.org/image/a62dxnrkh/
      • Debugger log (left) : https://justpaste.it/tblo
      • Debugger log (right): https://justpaste.it/tbln

      Empty application (GDB remote)
      If a new application is created (i.e. Application with a QWidget), the debugger run fine. Below the debug log:

      • Debugger log (left) : https://justpaste.it/tbm0
      • Debugger log (right): https://justpaste.it/tblz

      Differences (GDB log)

      Comparing both logs there are the following differences: https://www.diffchecker.com/zdvjxhzr

      • Line 746 : Empty application have: >1571^done >&"Function "QMessageLogger::fatal" not defined.\n"
      • Line 753: Custom application have it with different order: Process /usr/sbin/emonitor created; pid = 9606
      • Line 769: Custom application receive segmentation

      About the left side (in the QT Creator Debugger log), there is not difference (until process is running): https://www.diffchecker.com/1f2xllvu

      Custom application (GDB local)
      If the custom application is running with local GDB (through console or ssh) there is not segmentation fault:

      ...
      (gdb) run
      Starting program: /usr/sbin/emonitor
      [Thread debugging using libthread_db enabled]
      Using host libthread_db library "/lib/libthread_db.so.1". 
      [Julio: The application at this point run without problem]
      

      Completed local GDB log here: https://justpaste.it/tbm9

      kshegunovK 1 Reply Last reply
      0
      • julio.cruzJ julio.cruz

        Hi kshegunov,

        Done about the notifications. Thanks for the suggestion.
        About the segmentation fault, I described the stack trace below. Maybe new suggestions could arise.
        Appreciated your feedback.
        Thanks

        Custom application (GDB remote)
        The stack trace of the custom application is:

        Level Function File Line
        1        ??
        2        ?? 
        
        • Screenshot of QT Creator during the SIGSEG: http://postimg.org/image/a62dxnrkh/
        • Debugger log (left) : https://justpaste.it/tblo
        • Debugger log (right): https://justpaste.it/tbln

        Empty application (GDB remote)
        If a new application is created (i.e. Application with a QWidget), the debugger run fine. Below the debug log:

        • Debugger log (left) : https://justpaste.it/tbm0
        • Debugger log (right): https://justpaste.it/tblz

        Differences (GDB log)

        Comparing both logs there are the following differences: https://www.diffchecker.com/zdvjxhzr

        • Line 746 : Empty application have: >1571^done >&"Function "QMessageLogger::fatal" not defined.\n"
        • Line 753: Custom application have it with different order: Process /usr/sbin/emonitor created; pid = 9606
        • Line 769: Custom application receive segmentation

        About the left side (in the QT Creator Debugger log), there is not difference (until process is running): https://www.diffchecker.com/1f2xllvu

        Custom application (GDB local)
        If the custom application is running with local GDB (through console or ssh) there is not segmentation fault:

        ...
        (gdb) run
        Starting program: /usr/sbin/emonitor
        [Thread debugging using libthread_db enabled]
        Using host libthread_db library "/lib/libthread_db.so.1". 
        [Julio: The application at this point run without problem]
        

        Completed local GDB log here: https://justpaste.it/tbm9

        kshegunovK Offline
        kshegunovK Offline
        kshegunov
        Moderators
        wrote on last edited by kshegunov
        #11

        @julio.cruz
        Hello,
        To be completely candid, I haven't used GDB remotely and I'm certainly not so intimate with it for the log to speak to me much. However, it does appear (at least to me) that you're trying to debug a release build of the application. Although I'm used to x86 assembly and jne instead of bne, it looks like there's no debug information in your program, hence the calls are optimized out and there's no "good" stack trace.
        I suggest, building for your device in debug and trying to find out what the error might be. At least to obtain a sensible view of the stack frame. It'd be hell trying to trace it through the asm ...

        Line 769: Custom application receive segmentation

        This does point to a segmentation fault, but that error is so broadly raised it's almost meaningless without context. It can vary from dereferencing NULL pointers to out of bounds buffer overflows, so it's hard to tell what's going on.

        Kind regards.

        Read and abide by the Qt Code of Conduct

        1 Reply Last reply
        0
        • julio.cruzJ Offline
          julio.cruzJ Offline
          julio.cruz
          wrote on last edited by
          #12

          Hi @kshegunov ,

          Thanks for your quick feedback.

          The application was build in Debug mode. However, the file system was build without the debug symbols as you mentioned. So, a new file system was created including the debug symbol for all installed packages.

          With this new system, I still receive the same segmentation fault from GDB/Qt Creator. In other hand, the local GDB still working with some additional messages (that not show before):

          Starting program: /usr/sbin/emonitor
          [Thread debugging using libthread_db enabled]
          Using host libthread_db library "/lib/libthread_db.so.1".
          warning: File "/usr/lib/libstdc++.so.6.0.21-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
          To enable execution of this file add
                  add-auto-load-safe-path /usr/lib/libstdc++.so.6.0.21-gdb.py
          line to your configuration file "/home/root/.gdbinit".
          To completely disable this security protection add
                  set auto-load safe-path /
          line to your configuration file "/home/root/.gdbinit".
          For more information about this security protection see the
          "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
                  info "(gdb)Auto-loading safe path"
          

          This time, the local GDB take more time to run the application.

          kshegunovK 1 Reply Last reply
          0
          • julio.cruzJ julio.cruz

            Hi @kshegunov ,

            Thanks for your quick feedback.

            The application was build in Debug mode. However, the file system was build without the debug symbols as you mentioned. So, a new file system was created including the debug symbol for all installed packages.

            With this new system, I still receive the same segmentation fault from GDB/Qt Creator. In other hand, the local GDB still working with some additional messages (that not show before):

            Starting program: /usr/sbin/emonitor
            [Thread debugging using libthread_db enabled]
            Using host libthread_db library "/lib/libthread_db.so.1".
            warning: File "/usr/lib/libstdc++.so.6.0.21-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
            To enable execution of this file add
                    add-auto-load-safe-path /usr/lib/libstdc++.so.6.0.21-gdb.py
            line to your configuration file "/home/root/.gdbinit".
            To completely disable this security protection add
                    set auto-load safe-path /
            line to your configuration file "/home/root/.gdbinit".
            For more information about this security protection see the
            "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
                    info "(gdb)Auto-loading safe path"
            

            This time, the local GDB take more time to run the application.

            kshegunovK Offline
            kshegunovK Offline
            kshegunov
            Moderators
            wrote on last edited by kshegunov
            #13

            @julio.cruz
            Hello Julio,

            With this new system, I still receive the same segmentation fault from GDB/Qt Creator.

            This'd be something to track, but I think it's more important to fix the debugging first.

            In other hand, the local GDB still working with some additional messages (that not show before)

            If I'm not mistaken, this python file(s) should contain some debugging helpers for gdb. Since you're developing (not to mention it's your own application), I'd suggest to just disable whatever security nonsense is in place, i.e. to add: set auto-load safe-path to ~/,gdbinit. Note however that it's not a good idea in general to operate with the super user account (I'm inferring this from ~ being equal to /home/root).

            Kind regards.

            Read and abide by the Qt Code of Conduct

            1 Reply Last reply
            0
            • L Offline
              L Offline
              Larswad
              wrote on last edited by
              #14

              Hi!

              I see the very same SIGSEGV in gdb, imx, Jethro (yocto), qt5.1.1.

              Did this issue ever get solved, Juilio? If so, what was the reason?
              I can create a simple console app, and debugging works. But our real application will cause this crash when debugging.
              Best Regards,
              Lars

              kshegunovK 1 Reply Last reply
              0
              • julio.cruzJ Offline
                julio.cruzJ Offline
                julio.cruz
                wrote on last edited by
                #15

                Hi @Larswad,
                The issue get solved partially. After included new code, we got similar issues during debug session. That's could depend in many variables as suggested by @kshegunov previously.
                In any case, I suggest you to try upgrading to Krogoth. After the upgrade, I was able to debug the latest application without issues.
                Best regards
                Julio

                1 Reply Last reply
                0
                • L Larswad

                  Hi!

                  I see the very same SIGSEGV in gdb, imx, Jethro (yocto), qt5.1.1.

                  Did this issue ever get solved, Juilio? If so, what was the reason?
                  I can create a simple console app, and debugging works. But our real application will cause this crash when debugging.
                  Best Regards,
                  Lars

                  kshegunovK Offline
                  kshegunovK Offline
                  kshegunov
                  Moderators
                  wrote on last edited by
                  #16

                  @Larswad said in QSharedPointer, qRegisterMetaType, GDB and slots:
                  Hello,

                  As for the loading warning (assuming you also get it), you could peak here:
                  https://sourceware.org/gdb/onlinedocs/gdb/Auto_002dloading-safe-path.html

                  Kind regards.

                  Read and abide by the Qt Code of Conduct

                  1 Reply Last reply
                  0
                  • L Offline
                    L Offline
                    Larswad
                    wrote on last edited by
                    #17

                    Thanks Julio for your answers!

                    Stepping up from Jethro may be (at least in the in the near time) too much work for us. But maybe something can be backported from Krogoth instead and patched.

                    Lars

                    1 Reply Last reply
                    0
                    • G Offline
                      G Offline
                      Greg Hwang
                      wrote on last edited by
                      #18

                      Hello,

                      Was this issue ever resolved? I have a very similar setup to Larswad, and I'm seeing the same issue.

                      1 Reply Last reply
                      0
                      • G Offline
                        G Offline
                        Greg Hwang
                        wrote on last edited by
                        #19

                        Just an update. I upgraded my version of gdb from 7.9.1 to 7.10.1 on my embedded system, and I was able to get past this point. Just putting this out there in case anyone else runs into this issue.

                        1 Reply Last reply
                        1

                        • Login

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