Uploaded image for project: 'Qt Creator'
  1. Qt Creator
  2. QTCREATORBUG-6203

When debugging an application, Q_ASSERTs and other abort()-related macros should be "handled" by the debugger.

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Duplicate
    • Not Evaluated
    • None
    • Qt Creator 2.3.0, Qt Creator 2.4.0
    • Debugger
    • None

    • Ms Windows 7 x64

    Description

      What's happening now:
      If somewhere in the code a Q_ASSERT() evaluates false, the application is stopped with an info, where the Q_ASSERT() is and what expression evaluates false. If the application was run with a debugger, debugger is also stopped. If the developer wants to inspect a call stack, he must call qInstallMsgHandler() with a new MsgHandler, set a breakpoint in it and reproduce the bug. This is somewhat cumbersome.

      What would be nice to happen:
      Debugger breaks application execution in such case, giving the developer a way to inspect the call stack etc.

      Attachments

        1. gdbLog.notBreakingAssert.txt
          23 kB
          Dominik Dera
        2. gdbLog.qFatalCrash.txt
          22 kB
          Dominik Dera
        3. gdbLog.qWarningCrash.txt
          23 kB
          Dominik Dera

        Issue Links

          relates to

          Task - A task that needs to be done. QTCREATORBUG-5200 Fix "Internal error: pc 0x0 in read in psymtab, but not in symtab."

          • P2: Important - Urgent, should be fixed, but will not stop the release.
          • Closed
          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              hjk hjk
              phan Dominik Dera
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes