[Qt-creator] How to break on an assert?

[Murphy, Sean]

I'm sure I'm doing something stupid, but I'm not sure how to find it. I've got an existing codebase that we've just discovered fails on a new type of input - basically we crossed over the signed/unsigned boundary of a single byte field. So previous runs on the application always had this variable <= 127, now we're providing an input where the variable should be >= 128. I fixed the first place I found the issue, but that has changed where the problem occurs to somewhere later in my code I'm getting an assertion, but I'm having trouble figuring out where.

When running a debug build inside Qt Creator, all I get in the Application Output pane is:
ASSERT failure in QList<T>::at: "index out of range", file C:\Qt_5_3_2\5.3\mingw482_32\include/QtCore/qlist.h, line 479

But I have no idea where in my code this is happening, and gdb isn't breaking on this assert, allowing me to see where in my call stack this is happening. I've got plenty of QList's all over the place, and I'm fairly certain this issue is happening after a bunch of different signals fire, which is leading to the difficulty of tracking down where this happens.

Is there some setting in gdb/Qt Creator that would automatically break on this assertion?
Sean


This message has been scanned for malware by Forcepoint. www.forcepoint.com

[Steve Atkins]

Post by Murphy, Sean
I'm sure I'm doing something stupid, but I'm not sure how to find it. I've got an existing codebase that we've just discovered fails on a new type of input - basically we crossed over the signed/unsigned boundary of a single byte field. So previous runs on the application always had this variable <= 127, now we're providing an input where the variable should be >= 128. I fixed the first place I found the issue, but that has changed where the problem occurs to somewhere later in my code I'm getting an assertion, but I'm having trouble figuring out where.
ASSERT failure in QList<T>::at: "index out of range", file C:\Qt_5_3_2\5.3\mingw482_32\include/QtCore/qlist.h, line 479
But I have no idea where in my code this is happening, and gdb isn't breaking on this assert, allowing me to see where in my call stack this is happening. I've got plenty of QList's all over the place, and I'm fairly certain this issue is happening after a bunch of different signals fire, which is leading to the difficulty of tracking down where this happens.
Is there some setting in gdb/Qt Creator that would automatically break on this assertion?

Q_ASSERT uses qFatal(), so you can break on that and get a stack trace.

Preferences... -> Debugger -> GDB Extended has "Stop when qFatal() is called", which might do what you need.

Cheers,
Steve

[Murphy, Sean]

Post by Murphy, Sean

Post by Murphy, Sean
Is there some setting in gdb/Qt Creator that would automatically break on

this assertion?
Q_ASSERT uses qFatal(), so you can break on that and get a stack trace.
Preferences... -> Debugger -> GDB Extended has "Stop when qFatal() is
called", which might do what you need.

Thanks! That did the trick. I notice at the top of that tab it says "The options below should be used with care.", can anyone talk me through the harm of leaving this option enabled (and maybe the "Stop when abort() is called") as well?

Sean


This message has been scanned for malware by Forcepoint. www.forcepoint.com

[André Pönitz]

Post by Murphy, Sean

Post by Murphy, Sean

Post by Murphy, Sean
Is there some setting in gdb/Qt Creator that would automatically break on

this assertion?
Q_ASSERT uses qFatal(), so you can break on that and get a stack trace.
Preferences... -> Debugger -> GDB Extended has "Stop when qFatal() is called",
which might do what you need.

Thanks! That did the trick. I notice at the top of that tab it says "The options
below should be used with care.", can anyone talk me through the harm of leaving
this option enabled (and maybe the "Stop when abort() is called") as well?

The harm is mostly startup performance degradation, especially in cases
where the symbol is not found or even present (e.g. in non-Qt applications).

While this is in general true for any breakpoint, it gets more prominent for
functions that may or may not belong to a Qt configured with -qtnamespace as
trying to determine the configured namespace may trigger excessive scans of
debug information.

On Windows there seems also be a problem when that search kicks in very early
in the application startup due to an unrelated interruption either gdb or
the dynamic loader gets confused to a degree that continuation is not possible.

So it's not an option to leave on by default, use it only when you notice you
need it. But it won't eat kittens, if that's what you are afraid of.

Andre'