Assert failure in QList ??

grpace

Downloaded the new installer, deleted the last install and reinstalled Qt.

Qt Creator is now version 4.2.1, Based on Qt 5.8.0 (GCC 5.3.1 20160406 (Red Hat 5.3.1-6), 64 bit)... Red Hat is Linux... I am on Linux/Ubuntu.

Project still crashes with the same message.
Any ideas ???
Anyone ??

kshegunov

You're overrunning your list - i.e. you're asking for an element by index, and that index is out of the valid indices of that list. Start your program in the debugger and identify the bogus index and where it's passed to QList::at.

SGaist

Hi,

Can you show the stack trace from the crash ?

grpace

Thank You for the reply.

I'm not directly using a QList in the project at all !

I'm reinstalling Qt again right now. I'll get back to you when it's done. There are a few things I noticed on the Compile/Build options as well as the project's behavior.

This project was working fine and was not changed at all during this "upgrade" process.

grpace

Qt reinstalled. Tried reopening and running the project. Got:
No valid kits found. Project not yet configured. Add a kit from options or from the Maintenance Tool. Went to options, found, selected and applied Desktop to the project. Tried running it. Got:

ASSERT failure in QList<T>::at: "index out of range", file ../../../Qt/5.8/gcc_64/include/QtCore/qlist.h, line 540
The program has unexpectedly finished.

I go into Build & Run options. Qt's qmake was set to a subfolder of Qt's installation path in my home folder. I had made note of the original location and changed it back to the original:

/usr/lib/x86_64-linux-gnu/qt5/bin/qmake

It has a "caution" icon beside it (well both did... No helpers installed). The version of it shows Qt 5.2.1. Tried building and running the project again. Got:

Cannot mix incompatible Qt library (version 0x50201) with this library (version 0x50800)
The program has unexpectedly finished.

I load Maintenance Tool again and choose to add 5.2.1 libraries. Now waiting for them to be installed. Apparently an "upgrade" does that... And causes several other things to break.

ambershark

@grpace said in Assert failure in QList ??:

Thank You for the reply.

I'm not directly using a QList in the project at all !

I'm reinstalling Qt again right now. I'll get back to you when it's done. There are a few things I noticed on the Compile/Build options as well as the project's behavior.

This project was working fine and was not changed at all during this "upgrade" process.

QApplication uses QList, and your application should have a QApplication of some sort. If you could show the stack trace we could probably help you figure out what's going on.

Also there was a thread recently covering this exact issue with a Qt upgrade. It was from mixing one version of Qt with another. Sounds like that is what's going on your as well. The easiest way is to take Creator out of it and just run the build on the command line to confirm a clean build and working app.

grpace

Thanks to all that are replying to this. Your help is greatly appreciated !

Here's what I've gotten so far (hope these can be seen):

Link: Build & Run
Crash
Link: Crash

@ambershark said in Assert failure in QList ??:

The easiest way is to take Creator out of it and just run the build on the command line to confirm a clean build and working app.

How do I do that ? What are the commands ?

@ambershark said in Assert failure in QList ??:

Also there was a thread recently covering this exact issue with a Qt upgrade. It was from mixing one version of Qt with another.

How was that solved ? ... Or was it solved ?

grpace

I need to make some corrections to prior statements.

I was using a QStringList to get command line parameters to the app. Those were assigned in the "Run" section of Build & Run.

Apparently those command line parameters were not carried over during the upgrade (the "Arguments" text box was empty). The section of code I was using is:

    // get command line I/O parameters
    QStringList params = QCoreApplication::arguments();

    // set input file and output folder
    xmlSourceFile.setFileName(params.at(1));
    bomOutputPath.setPath(params.at(2) + "/");

There's the QList "out of range" issue... There were no command line parameters present for the app to read. I reset those parameters and the app runs again.

Thanks to all of you that have replied and offered help !

SGaist

QCommandLineParser to the rescue !

That's the best way to deal with command line parameters. Another thing that might get you in trouble otherwise is that Qt already has a set of arguments that you can use. Using QCommandLineParser will allow you to only focus on what you need.

grpace

On a second thought, the command line parameters could have been lost when having to reassign the Desktop kit to the project after the upgrade.

At any rate, the "upgrade" was not a smooth one.

grpace

@SGaist
Thank you. I'll have a look at the command line parser.

I'm new to Qt. I have a basic understanding of C++, but learning the myriad of classes Qt offers and how to utilize them is a completely different story.

Again, thanks to all that have offered help. I'm going to set this topic a solved.

ambershark

@grpace said in Assert failure in QList ??:

Thanks to all that are replying to this. Your help is greatly appreciated !

Here's what I've gotten so far (hope these can be seen):

Link: Build & Run

Link: Crash

@ambershark said in Assert failure in QList ??:

The easiest way is to take Creator out of it and just run the build on the command line to confirm a clean build and working app.

How do I do that ? What are the commands ?

Just to answer these for completeness... To build on the command line:

$ cd /your/project
$ qmake
$ make

(assumed posix os, if you're using windows it's more complicated to get the environment set up but the build process is similar).

windows/mingw:
$ cd \your\project
$ qmake
$ mingw32-make

@ambershark said in Assert failure in QList ??:

Also there was a thread recently covering this exact issue with a Qt upgrade. It was from mixing one version of Qt with another.

How was that solved ? ... Or was it solved ?

By making sure the build environment used only the Qt intended. For that guy it was removing the previous Qt install (not the path i would have taken but that's what did it).