Thread: Destructor Problem - Seg Fault After Main Returns

  1. #1
    Registered User IdioticCreation's Avatar
    Join Date
    Nov 2006
    Location
    Lurking about
    Posts
    229

    Destructor Problem - Seg Fault After Main Returns

    So the class I'm working on is really messy at the moment because I'm playing around with it a lot and experimenting. It is a terrain class that loads a height map computes normals, etc, etc. Originally I had it where it would exit cleanly if it was given the name of a height map image that didn't exist, and I guess it still does, but as the class has grown there are problems with destruction.

    So I have this public function:
    Code:
    bool Terrain::loadTerrain(const std::string& source)
    {
        source_ = source;
        if (!hmImage_.loadTextureFromFile(source_)) {
            std::cout << "Failed to load heightmap, quitting." << std::endl;
            return false;
        }
        height_ = hmImage_.getHeight();
        width_ = hmImage_.getWidth();
        data_ = hmImage_.getData();
    
        applyBilinearFilter();
        heightMap_.resize(height_);
        for (unsigned int i = 0; i < heightMap_.size(); i++) {
            heightMap_[i].resize(width_);
        }
        for (int i = 0; i < height_; i++) {
            for (int j = 0; j < width_; j++) {
                if (filteredData_[i] != 0)
                    heightMap_[i][j] = (float)filteredData_[i][j];
                else {
                    std::cout << "When copying filteredData into heightmap a 
                                          null pointer was almost accessed.  Quitting." << std::endl;
                    return false;
                }
            }
        }
        for (int i = 0; i < width_; i++) {
            delete [] filteredData_[i];
            filteredData_[i] = 0;
        }
        delete [] filteredData_;
        filteredData_ = 0;
    
        computeNormals();
        std::cout << "Generating terrain display list...";
        createDisplayList();
        std::cout << " Done." << std::endl;
        terrainReady = true;
        return true;
    }
    Even though this is a height map, I used my texture class to load the image. I'm pretty sure that the problem is with filteredData_ which is a 2d array of floats. the function called applyBilinearFilter samples data_, which is a pointer to memory reserved by the FreeImage library, and saves the sampled data in filteredData_.

    loadTerrain(const std::string& source) is called in my main function like this:
    Code:
        Terrain terrain;
        terrain.setRenderMode(SOLID_MODE | VERTEX_LIGHTING);
        if (!terrain.loadTerrain(settings.getMap())) {
            glfwTerminate();
            std::cout << "dbg" << std::endl;
            return 0;
        }
    When executed dbg is outputted in the console. Also when I debug I get:
    Debugger finished with status 0
    and the call stack is empty. I'm pretty sure that I'm not explicitly any destructors.
    Some searching has given me the idea that this is probably caused when my objects go out of scope and their destuctors are called when main returns. So here it is, the destructor for my terrain class:

    Code:
    Terrain::~Terrain()
    {
        if (terrainReady) {
            for (unsigned int i = 0; i < heightMap_.size(); i++) {
                heightMap_[i].clear();
            }
            heightMap_.clear();
            for (unsigned int i = 0; i < normals_.size(); i++) {
                normals_[i].clear();
            }
            normals_.clear();
        }
        data_ = 0;
    }
    I normally avoid using these c style pointer arrays like the plague, so I'm not very experienced with them. Let me know what you think, or if you need to see more code.

    Thanks

    edit: I should also mention that it works just fine when I don't give it a bad file name.
    Last edited by IdioticCreation; 01-02-2011 at 07:16 PM.

  2. #2
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Quote Originally Posted by IdioticCreation View Post
    Code:
    Terrain::~Terrain()
    {
        if (terrainReady) {
            for (unsigned int i = 0; i < heightMap_.size(); i++) {
                heightMap_[i].clear();
            }
            heightMap_.clear();
            for (unsigned int i = 0; i < normals_.size(); i++) {
                normals_[i].clear();
            }
            normals_.clear();
        }
        data_ = 0;
    }
    If that is all that your destructor is doing then you can simply delete the whole thing. When the vector members themselves are destroyed, they already call clear on themselves, the elements of which in turn call clear on themselves if they are std library containers.

    Where does filteredData_ come from?
    I think we need to see more of the definition of this Terrain class.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  3. #3
    Registered User IdioticCreation's Avatar
    Join Date
    Nov 2006
    Location
    Lurking about
    Posts
    229
    Well interesting. Yeah I see that now. The reason I had it was because I was deleting filteredData_ in it, but just before I posted the code here I realized that once I had moved the filteredData_ to the heightMap vector I wasn't using it anymore. So I deleted it right after I was done with it. Really I don't even need to it, it's kind of an unnecessary intermediate step. I just put it in originally because I was writing a filter that I didn't understand to well at the time.

    Anyway, I just removed that destructor and it started working. I don't really understand why. Clearing a vector that is already cleared shouldn't cause problems? Unless maybe its trying to clear the vector after its been cleaned up.

  4. #4
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    That sounds like undefined behavior. Your entire LoadTerrain function is problematic. You are using raw pointers and deleting within the body. But what happens if you throw exceptions or return or fail in some other spectacular way? It's a disaster waiting to happen.
    You need to use smart pointers or some cleanup exit code (see BOOST_SCOPE_EXIT or whatever it's called).
    Also, does your class contain raw pointers? If so, then disable the copy constructor and assignment operator. They will/can cause problems.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Seg fault problem
    By grifan526 in forum C Programming
    Replies: 2
    Last Post: 04-12-2010, 10:33 PM
  2. next_permutation seg fault
    By zxcv in forum C++ Programming
    Replies: 9
    Last Post: 12-14-2008, 07:40 AM
  3. Unknown Seg Fault and Malloc/Realloc Problems
    By DonFord81 in forum C Programming
    Replies: 6
    Last Post: 12-01-2008, 11:49 PM
  4. Thread Prog in C language (seg fault)
    By kumars in forum C Programming
    Replies: 22
    Last Post: 10-09-2008, 01:17 PM
  5. Contest Results - May 27, 2002
    By ygfperson in forum A Brief History of Cprogramming.com
    Replies: 18
    Last Post: 06-18-2002, 01:27 PM