Qt Creator crashes (SIGABRT) on expression error

James Murray

When debugging and stopping at a breakpoint, if an existing expression is invalid (subscript out of range) it causes a SIGABRT.

This can be really confusing. While I have learned to expect it now and can work around it, the first time I encountered it I lost a number of hours trying to understand why my code was crashing at this point when it was not.

Code example:

#include <QApplication>

int main(int argc, char *argv[])
{
    QList<int> testList;

    fprintf(stderr, "Size of list = %lld\n", testList.count()); // Set breakpoint on this line

    for (int x = 0; x < 5; x++) {
        testList.append(x);
    }

    for (int x = 0; x < 5; x++) {
        fprintf(stderr, "testList[x] = %d\n", testList[x]);
    }
}

Add an expression evaluator for testList[2]
Debug the code and receive a SIGABRT

Is this a known issue? Should I submit a bug report?
I did search and didn't immediately find existing reference to this.

James

aha_1980

Hi @James-Murray,

Yes, crashes can always be reported as bugs. Please go to bugreports.qt.io (you can add a link to the report here so others can follow).

Please also specify the Creator version you are using, the operating system and the underlying debugger (and version) you are using. If you are using a Qt Creator older than 16.x, you will probably be asked to update and re-test.

Regards

JonB

@James-Murray
You do not say platform, compiler, debugger or Creator version.

For me under Ubuntu 24.04, Creator 13.0, gdb 15.0. I do not get a SIGABRT per se. Compiled for debug at least, in the terminal opened for a console application it outputs

ASSERT failure in QList::operator[]: "index out of range", file /usr/include/x86_64-linux-gnu/qt6/QtCore/qlist.h, line 428

at least until the element gets created while stepping through.

But it does not stop my debugging, I can continue fine in the debugging session.

I get similar behaviour if I use that expression for the conditional on a conditional breakpoint.

I am not quite sure this can be avoided. It's irritating but not fatal so long as it does not stop you debugging. Are you saying it does that to you?

However, so long as I change array expressions to use at(2) instead of [2] it goes through fine and no complaints for me? You should never use array operator [] in an expression in debugger anyway, think about why! :)

Oh, LOL, testList.at(2) "works" in that it does not error, but it never evaluates to anything. So not much use. I have found trouble with array accesses trying to use Qt's [].

James Murray

Ubuntu 22.04.5
QtCreator 16.0.0
gdb 12.1

At each single-step, I get a popup message about the SIGABRT.

Yes, I realise why this occurs as [2] is beyond the end of the QList, but initially I found it really confusing and went around in circles thinking there was a problem with my application code - even as a reasonably experienced programmer.

Perhaps if QtCreator at least mentioned that it was an expression evaluation problem then it would be more obvious to find the problem?

James

aha_1980

@James-Murray: Ah, that's a crash of your debugged app, not a crash of Qt Creator.

Nevertheless, you could report it (maybe as suggestion) as I agree the result is a bit surprising.

Regards

JonB

@aha_1980 said in Qt Creator crashes (SIGABRT) on expression error:

@James-Murray: Ah, that's a crash of your debugged app, not a crash of Qt Creator.

No, it is not. The only thing which causes the crash is having Creator have a Watch Expression (or same if condition on a breakpoint) on testList[2]. It is Creator/gdb evaluating that which causes the error, not OP's code.

JonB

@James-Murray
As I wrote, I do not get any such SIGABRT dialog or interruption. It may be coming from the ASSERT(), which can do something like an abort() call at its end.

If you press OK in yours, (a) do you get a stack trace which shows an actual trace from your program (as opposed to inside Creator/gdb)? and (b) can you continue with the debugging session afterwards or does it terminate?

Either our Craetors are different or you have a different setting from me? I can't recall whether I did a gdb setting to do with ignoring signals....

James Murray

There's no stack trace as my application hasn't crashed.

The Application Output shows:
ASSERT failure in QList::operator[]: "index out of range", file /home/jsm/Qt/6.8.3/gcc_64/include/QtCore/qlist.h, line 458

I click ok, then Step, then the message pops up again. (As expressions are evaluated on each step.)
Neither QtCreator nor my application terminate. (My post title is slightly misleading, it isn't a full crash.)

James

JonB

@James-Murray OK, so just the same as I wrote in my first post. Same behaviour, but I don't get the message box.