2

I've started learning qt recently and was playing with it, also remembering a bit of c++ since I haven't used it in a while...

Anyway, I made this simple test class to see what would happen when you have a dangling pointer:

#include <QtCore/QCoreApplication>

#include <iostream>

class Test{
public:
    QString str;
    int i;
public:
    Test(){
        i=1337;
        str="str";
        std::cout<<"initialized\n";
    }

    ~Test(){
        std::cout<<"destructor called\n";
        delete &str;
        delete &i;
        /*the program MAY run if the deletes aren't called;*/
    }
};

Test* p;

void test_function(){
    Test a;
    p=&a; //this will give a segfault, since the destructor of a is called at the end of this function's scope, but p still points to a
    //p=new Test(a); //this will call the copy constructor of p, copying the values from a to p
}

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    test_function();

    std::cout<<p->str.toStdString() << p->i<<std::endl;

    return a.exec();
}

which, sure enough, crashes (but it doesn't say why - probably segfault). However, if I comment the line where the dangling pointer is called (the cout in main()), the program now crashes giving me a "std::bad_alloc" exception. The following list of things tested independently causes the exception to not be thrown anymore:

  • commenting the initialization of str;
  • commenting the destructor of str;
  • replacing QString with std::string;

What I tried and didn't have any effect was initializing str with QString::fromStdString("str") (instead of just "str").

I've also tried surrounding the initialization and destruction of str (while a QString) with a try/catch block, but to no avail. Also, try/catch for the test_function() - no result. I did however succeeded in catching the exception by surrounding the a.exec() in a try/catch block.

Why does it throw an exception when the cout is commented, but only crashes otherwise? Why does having both initializer and destructor for str throw the exception, but commenting one or both only results in a crash? (now that I'm writing this, I realise this may be the sole problem; however, why does it crash for QString but not for std::string?) Why does the a.exec() throw the exception?

Can someone who knows qt (or even c++) - better than I do - explain what's going on? Thank you

Nini Michaels
  • 341
  • 7
  • 17
  • 1
    Don't overthink. Usually, if you find yourself writing a destructor, you're doing something wrong. – Kerrek SB Mar 19 '12 at 23:06
  • You'll learn more by cleaning up the errors you didn't intend to make, and trying again. I still can't tell exactly what you were trying to test. – tmpearce Mar 19 '12 at 23:12
  • @tmpearce: well, I was trying to test destructors in a simple program, to see when they are called, if the delete actually removes the data, etc.; somehow, I ended commenting the cout in main() and I got an exception instead of a crash. From there, I started playing with it, seeing what causes the exception and what doesn't... – Nini Michaels Mar 19 '12 at 23:17
  • 1
    I understand, I'm not criticizing - trying to understand your code is a good thing - but trying to understand "undefined behavior" is a fool's errand. I suggest reading http://stackoverflow.com/q/2397984/1214731 – tmpearce Mar 19 '12 at 23:23
  • Thanks! A good read, I guess I haven't really stumbled upon this stuff before. It's good to know :) – Nini Michaels Mar 19 '12 at 23:59

2 Answers2

4

This is one mistake:

delete &str;
delete &i;

trying to delete variables that were not dynamically allocated, i.e. using new. Remove those two lines. i and str will be destroyed automatically when the Test instance is destructed.

hmjd
  • 120,187
  • 20
  • 207
  • 252
  • I thought that might be the problem, but why doesn't it crash for std::string? Also, why isn't it recommended to delete non-allocated variables? Are they automatically destructed? – Nini Michaels Mar 19 '12 at 23:05
  • I am pretty sure that this is the realm of undefined behaviour: meaning anything could happen. – hmjd Mar 19 '12 at 23:06
  • 1
    Yes, they are automatically destructed. Use `delete` with `new` and `delete[]` with `new[]`. – hmjd Mar 19 '12 at 23:07
  • Heh... I thought you were deleting stack variables on purpose, trying to get it to crash and seeing what exceptions were thrown. In other words, why you were getting the bad_alloc rather than just a segfault, or something like that. – tmpearce Mar 19 '12 at 23:07
  • 1
    dynamically allocated variables are created at runtime, where non-dynamically allocated variables are created at compile time and have the clean up code built into the program – Steve's a D Mar 19 '12 at 23:08
  • I understand better now, but I have one curiosity: why doesn't it throw the exception if I comment the initialization (str="str"), but not the delete? – Nini Michaels Mar 19 '12 at 23:14
  • 1
    @NiniMichaels, it is undefined behaviour: anything could happen. – hmjd Mar 19 '12 at 23:18
1

I'm not exactly sure what kind of answer you're looking for, but even if you don't use the dangling pointer p you'll have corrupted the heap (or some other undefined behavior) because in your dtor for Test you have the following:

~Test(){
    std::cout<<"destructor called\n";
    delete &str;
    delete &i;
    /*the program MAY run if the deletes aren't called;*/
}

The two delete statements are deleting things that aren't allocated via new - don't do that.

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • thanks for the answer! I've also asked hmjd: why isn't this recommended? What actually happens when you delete a non-allocated object? Why does it happen for QString but not for std::string? – Nini Michaels Mar 19 '12 at 23:08
  • 1
    If you delete stack-allocated variables, you usually crash the program - unless you're unlucky, then your program will mess up elsewhere. Read this for more info: http://stackoverflow.com/questions/441831/c-calling-delete-on-variable-allocated-on-the-stack – tmpearce Mar 19 '12 at 23:15
  • 1
    Deleting an object that wasn't allocated via `new` is similar to calling `free()` on a pointer that wasn't allocated via `malloc()`. You might never notice a problem, but you'll likely corrupt things and cause a crash - either right away or during some future allocation/deallocation. – Michael Burr Mar 19 '12 at 23:19