QString optimized out, causes segmentation fault

[Publicnamer]

I have code similar to this:

struct mystruct {
  QString s;
  int i;
}
QVector<mystruct> v;
v[3].s = "abc";
v[3].i = 123;

I find that when I try to write the QString inside of an element that is in a vector, it causes a segmentation fault.
Anyone know why this might happen?

This also causes a segmentation fault:

mystruct str;
str.s = QString("abc");
str.i = 123;
v[3] = str;

When I use gdb to print v[3], it says that the QString has null content and seems to suggest it was optimized out. I'm often finding that G++ optimizes things out these days that I didn't optimized out.

[mchinand]

You've created a vector with no elements, so it's going to crash when you try to write to a non-existent 4th element.

[Publicnamer]

@mchinand Another variant of this code that also crashes is:

mystruct *v = new mystruct[100];
v[3].s = "abc";
v[3].i = 123;

[mpergand]

@Publicnamer said in QString optimized out, causes segmentation fault:

@mchinand Another variant of this code that also crashes is:

mystruct *v = new mystruct[100];
v[3].s = "abc";
v[3].i = 123;

No, it doesn't.

With QVector you can do:

QVector<mystruct> v(10,{"aa",100});
qDebug()<<v[5].s<<v[3].s;

[Publicnamer]

@mpergand
It really does crash for me compiling with G++ and with clang.

0x0000007ff6fd8fc0 in QString::operator=(QString const&) () from /usr/lib/aarch64-linux-gnu/libQt5Core.so.5

It also crashes if I assign the QString like so:

QString otherString = "xyz";
std::string str = otherString.toString();
const char *cstr = str.c_str();
v[3].s = QString(cstr);

As well as:

v[3].s = QString(strdup(cstr)); // double free error

My struct has many elements. It makes no sense to init it using a single-line expresson.

[JonB]

@Publicnamer
Instead of stating that your code is correct and the C++ optimizer is wrong, show your code for others to be the judge.

There are a lot of programs out there, Qt or otherwise, using compiler optimization flags. If that regularly caused crashes there would be an uproar. Do you know better than the people who wrote the compilers?

[Publicnamer]

@JonB
The code I'm showing is virtually identical to the real code. It really is crashing with these simple operations.

[mchinand]

@Publicnamer said in QString optimized out, causes segmentation fault:

struct mystruct {
QString s;
int i;
}

Is your real code missing a semicolon at the end of this? I wouldn't think it would compile without it.

struct mystruct {
QString s;
int i;
};

[JonB]

@Publicnamer said in QString optimized out, causes segmentation fault:

The code I'm showing is virtually identical to the real code.

If I had a $ for every time somebody said "this code crashes, but it's not quite the same as my code, but it's really the same, honest", I'd be rich. After wasting my time on code which turns out to be different from what the person really has.

Be reasonable about what you want other people to comment on. That is, if you want to solve it.

Start by breaking your problem down.

• Remove the vector. Does, say, qDebug() << QString(cstr); crash? If yes it has nothing to do with the vector.

• If it is the vector situation only, look at your vector closely instead.

If you want anything done: Produce a minimal example which others can compile. Don't give us some code and say your actual code is something different.

Also, are you saying anything about how the code is compiled affecting the outcome? If you can reproduce the problem compiled for debug, let it crash in the debugger and show us the stack trace.

[JonB]

@Publicnamer said in QString optimized out, causes segmentation fault:

QString otherString = "xyz";
std::string str = otherString.toString();

This is part of your code which crashes? There is no method QString::toString(), so it would not even compile, so how can it crash? Do you see the point of producing an actual piece of code which exhbits your problem, rather than assuring us it is "virtually identical to the real code"?

[Publicnamer]

@JonB Obviously I meant toStdString.
The problem seems to be that QString cannot be put into a struct for whatever reason. There is some crazy bug in that class.
The fact that I get a double free error when I using strdup is really alarming:

v[3].s = QString(strdup(cstr)); // double free error here

[JonB]

@Publicnamer
So you would like us to comment on why your code is crashing when we should guess what is "obviously" in your code? This is getting crazy.

If you want actual help with your issue, as opposed to telling us that everything is wrong and does not work, produce an actual example. People here will help.

The problem seems to be that QString cannot be put into a struct for whatever reason. There is some crazy bug in that class.

Simply not so.

Meanwhile I have asked you useful questions like: does it happen when compiling for debug? No answer. Does it crash when you do not use a vector? array? No answer.

[JoeCFD]

@Publicnamer struct is a class as well. How can it be possible that QString can not be put into struct? Your app may have some corrupt memory and the real problem may be somewhere else.
On linux, run valgrind to find out memory issue.

[wrosecrans]

@Publicnamer said in QString optimized out, causes segmentation fault:

@JonB Obviously I meant toStdString.

The thing is, nothing is "obvious" when debugging. You didn't mean to have a bug in the first place, so trying to make people guess about the code you are having problems with isn't productive. People can really only help you debug an actual reproducible test case, not just something "obviously" similar to a test case. Seriously, share a full main() with your actual problem, and people will be much more able to see what's happening.

[ChrisW67]

@Publicnamer said in QString optimized out, causes segmentation fault:

Anyone know why this might happen?

It really does crash for me compiling with G++ and with clang.

Yes, the code presented in the original post will crash for exactly the reason described by @mchinand. The result almost certainly will not change with compiler or optimization level, but might be more informative if compiled for debug.

Here is your example, or something "virtually identical" to it:

#include <QCoreApplication>
#include <QString>
#include <QVector>
#include <QDebug>

struct mystruct {
  QString s;
  int i;
};

int main (int argc, char **argv) {
        QCoreApplication app(argc, argv);

        qDebug() << "Starting";
        QVector<mystruct> v;  // <<<< this vector has no members
        v[3].s = "abc";
        v[3].i = 123;
        qDebug() << v[3].s << v[3].i;
                qDebug() << "Ending";
                qDebug() << "Ending";

        return 0;
}

Here is what happens when compiled for release (-O2 optimization, gcc version 9.3.0)

chrisw@newton:/tmp/crash$ qmake -v
QMake version 3.1
Using Qt version 5.12.8 in /usr/lib/x86_64-linux-gnu
chrisw@newton:/tmp/crash$ qmake CONFIG+=release
Info: creating stash file /tmp/crash/.qmake.stash
chrisw@newton:/tmp/crash$ make
g++ -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o main.o main.cpp
g++ -Wl,-O1 -o crash main.o   /usr/lib/x86_64-linux-gnu/libQt5Gui.so /usr/lib/x86_64-linux-gnu/libQt5Core.so /usr/lib/x86_64-linux-gnu/libGL.so -lpthread   
chrisw@newton:/tmp/crash$ ./crash 
Starting
Segmentation fault (core dumped)

... and for debug (no optimization at all, and debug symbols):

chrisw@newton:/tmp/crash$ make distclean
rm -f moc_predefs.h
rm -f main.o
rm -f *~ core *.core
rm -f crash 
rm -f .qmake.stash
rm -f Makefile
chrisw@newton:/tmp/crash$ qmake CONFIG+=debug
Info: creating stash file /tmp/crash/.qmake.stash
chrisw@newton:/tmp/crash$ make
g++ -c -pipe -g -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o main.o main.cpp
g++  -o crash main.o   /usr/lib/x86_64-linux-gnu/libQt5Gui.so /usr/lib/x86_64-linux-gnu/libQt5Core.so /usr/lib/x86_64-linux-gnu/libGL.so -lpthread   
chrisw@newton:/tmp/crash$ ./crash 
Starting
ASSERT failure in QVector<T>::operator[]: "index out of range", file /usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h, line 437
Aborted (core dumped)

With/without optimization, same result, ergo not optimization induced.
Debug version tells you exactly why it crashed, if only you looked.

gdb, on a debug version, will tell you which line of your code triggered it:

chrisw@newton:/tmp/crash$ gdb ./crash
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
...
Reading symbols from ./crash...
(gdb) run
Starting program: /tmp/crash/crash 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Starting
ASSERT failure in QVector<T>::operator[]: "index out of range", file /usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h, line 437

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7694859 in __GI_abort () at abort.c:79
#2  0x00007ffff7ae3aad in QMessageLogger::fatal(char const*, ...) const () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#3  0x00007ffff7ae2f46 in qt_assert_x(char const*, char const*, char const*, int) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x0000555555555d85 in QVector<mystruct>::operator[] (this=0x7fffffffdf60, i=3) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h:437
#5  0x0000555555555453 in main (argc=1, argv=0x7fffffffe0b8) at main.cpp:16
(gdb) 

If you correct your erroneous code to, for example:

#include <QCoreApplication>
#include <QString>
#include <QVector>
#include <QDebug>

struct mystruct {
  mystruct(): s(), i(0) { }  // <<<< a  constructor so the int is never undefined

  QString s;
  int i;
};

int main (int argc, char **argv) {
        QCoreApplication app(argc, argv);

        qDebug() << "Starting";
        QVector<mystruct> v(4);  // <<<< this vector actually has 4 default constructed members
        v[3].s = "abc";
        v[3].i = 123;
        qDebug() << v[3].s << v[3].i;
        qDebug() << "Ending";
        
        return 0;
}

Then, oddly, it does not crash:

chrisw@newton:/tmp/crash$ make
g++ -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o main.o main.cpp
g++ -Wl,-O1 -o crash main.o   /usr/lib/x86_64-linux-gnu/libQt5Gui.so /usr/lib/x86_64-linux-gnu/libQt5Core.so /usr/lib/x86_64-linux-gnu/libGL.so -lpthread   
chrisw@newton:/tmp/crash$ ./crash 
Starting
"abc" 123
Ending