Why is "this" NULL? C++ Segmentation fault

Question

I'm building a Qt app and it's crashing because of a segmentation fault. After investigation, I found out that the cause of the segfault is that "this" is NULL and I try to access a member variable in the readInputFile(QString path) method. In this line input += line;

I don't understand why this is happening. how can "this" be NULL ?

Here's where the object is created

void MainWindow::on_inpFileCheck_clicked()
{
    if (ui->inpFileCheck->isChecked()) {
        QString filePath = QFileDialog::getOpenFileName(this,tr("Open CSV file"), "/home", tr("CSV  (*.csv)"));
        myAlgo->readInputFile(filePath);
        ui->inputEdit->clear();
        ui->inputEdit->appendPlainText(myAlgo->getInput());
    }
}

Here's the BaseAlgorithm header

#include "qstring.h"
#include "qmainwindow.h"

class BaseAlgorithm
{
public:
    BaseAlgorithm();
    QString readInputFile(QString);
    int lenArr;

private:
    QString input;
    QString output;
};

And here's the implementation and where the problem happens

#include "basealgorithm.h"
#include "qfile.h"
#include "qtextstream.h"

BaseAlgorithm::BaseAlgorithm() {

    numComparisons = 0;
    input = "";
    output = "";
    intArr = NULL;
}

QString BaseAlgorithm::readInputFile(QString path) {

    QFile inpFile(path);
    if (inpFile.open(QIODevice::ReadOnly | QIODevice::Text)) {
        QTextStream in(&inpFile);

        while (!in.atEnd()) {
            QString line = in.readLine();
            input += line; // crash happens here
        }
        return input;
    }

    else {
         return "ERROR";
    }

}

@DeiDei Updated. In the readInputFile() method. This line `input += line;` — Mohamed Ali, Dec 09 '17 at 18:27
Hard to say much without knowing where and how `BaseAlgorithm` is created. I recommend fashioning yourself an [mcve]. If that doesn't show you where the problem is and how to fix it, remove the code in the question and replace it with the MCVE. — user4581301, Dec 09 '17 at 18:28

score 3 · Answer 1 · edited Dec 10 '17 at 10:12

3

In C++, it is perfectly possible to call a method via a null pointer to an object. As long as this is not actually dereferenced, the function would work fine.

UPDATE: The behavior is what is often exhibited by implementations, as this is usually treated as just another parameter in the compiled code. However, as @manni66 points out, the standard doesn't actually mandate the result of calling a method on a nullptr.

edited Dec 10 '17 at 10:12

Remy Lebeau

555,201
31
458
770

answered Dec 09 '17 at 19:08

Del

1,309
8
21

3

It is UB. The function may do what you expect, but there is **no guarantee** – Dec 09 '17 at 19:13
I learned something very interesting today. – Silvio Mayolo Dec 09 '17 at 19:13
Weird things happen if the object is supposed to have a vtable for virtual functions. – Zan Lynx Dec 09 '17 at 19:17
For each undefined behavior the standard states there is usually a well defined behavior in the particular implementation. Implementations tend to go for behavior that is as safe, logical and predictable as possible, contrary to the stereotypical anecdotal UB explanation. It just takes more digging to find that out, and it is really NOT recommended practice to rely on it. It is just tying loose ends to the extent that it is possible in order to avoid the worst as much as possible. – dtech Dec 09 '17 at 20:31
@dtech The "stereotypical" explanation is actually becoming truer each day as compilers reason more about the values during compile time. Modern C++ compilers are free to and **will** delete method invocations where it's statically known that `this` is null! More generally, the desired and ever more present compiler behavior is to **remove** code with UB. It's an optimization technique, and a very important one. So the "well defined" behavior is that of deleting your code. So yeah - depend on UB as long as you don't care about your code at all. That's the essence of your advice... – Kuba hasn't forgotten Monica Dec 12 '17 at 15:46
@KubaOber the point was that the behavior is never really undefined in practice. I haven't dug into recent implementations but back in the day when I bothered to check what various compilers do, it was usually the same thing that I would have done. For example the destruction of polymorphic objects without a virtual destructor in the base invoked the destructor for the particular pointer type. And my advise was to NOT rely on that, even if your derived classes don't add anything extra that needs destructing. How you extrapolated the "advice" to depend on UB from my comment is a logical mystery – dtech Dec 12 '17 at 16:44
1

@dtech Using UB to mean "remove me" is becoming an idiom. This can't but depend on the ability of the compiler to statically reason about code. So the behavior is "defined" only inasmuch as you can presume that compilers doesn't learn any new tricks. None of is is well documented at all: UB removal depends on implementation details of the various optimization passes. So yes, **with each new modern compiler release the UB is becoming even more undefined** as the optimizers become more complex and delete more UB code - but you never know exactly which code! https://stackoverflow.com/q/36893251 – Kuba hasn't forgotten Monica Dec 12 '17 at 17:15

score 1 · Answer 2 · answered Dec 09 '17 at 19:16

1

It is pretty obvious that this is NULL because myAlgo is NULL where it is called. So the question asked in the title here is answered.

Why is myAlgo NULL? We don't know because you didn't show that code.

answered Dec 09 '17 at 19:16

Zan Lynx

53,022
10
79
131

score -1 · Accepted Answer · answered Dec 09 '17 at 19:22

-1

I fixed it. The object was being created late.

answered Dec 09 '17 at 19:22

Mohamed Ali

21
10

Why is "this" NULL? C++ Segmentation fault

3 Answers3