troubleshooting segmentation fault and the ~ in a method decleration

[vysero]

There is a bug in this application that causes the app to crash. I can replicate the bug and so I loaded up gdb (first time user) through Eclipse and replicated it during a debug session.

Here is the gdb output:

  Thread 1 received signal SIGSEGV, Segmentation fault.
0x000f3ba8 in MapView::CMVTesselatorGL::~CMVTesselatorGL (this=0x4332ba60, __in_chrg=<optimized out>) at ../../../src1/MapView/CMVTesselatorGL_GLES2_0.cpp:159
159       }

The method it is referring to:

  (gdb) list
154         if(m_glTess!=NULL)
155         {
156           gluDeleteTess(m_glTess);
157           m_glTess=NULL;
158         }
159       }
160       

and here is the current value of m_glTess:

  (gdb) print m_glTess
$2 = (GLUtesselator *) 0x1

I am not positive what it means when you have a ~ in the name of the method:

CMVTesselatorGL::~CMVTesselatorGL()

What is the significance of the ~ and how is it that m_glTess != NULL considering the method seems like it should force it to.

[Ganado]

What is the significance of the ~

~ClassName is the signature of the destructor of a class.
The purpose of a destructor is to clean up any resources that the class is using.

It is called automatically when an object is deleted (if dynamically allocated) or when an object (with automatic storage) goes out of scope.

// Example program
#include <iostream>

class Foo {
 public:  
    Foo()
    {
        std::cout << "  Foo created\n";   
    }

    ~Foo()
    {
        std::cout << "  Foo destroyed\n";   
    }
  
};

int main()
{
    std::cout << "automatic:\n";
    
    {
        Foo foo;
    }
    
    std::cout << "dynamic:\n";
    
    {
        Foo* pfoo = new Foo();
        
        delete pfoo;
    }
    
    std::cout << "dynamic w/ leak:\n";
    
    {
        Foo* pfoo = new Foo();
        // not deleted! (memory leak)
    }
}

automatic:
  Foo created
  Foo destroyed
dynamic:
  Foo created
  Foo destroyed
dynamic w/ leak:
  Foo created

gluDeleteTess is a GLU library function that should delete a tesselation object that was presumably created with gluNewTess().
https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluDeleteTess.xml
https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluNewTess.xml
(Side note: glu* functions are incredibly old and shouldn't be used in modern OpenGL (v.3.1+). This fact might be immaterial to you.)

Probably more code must be shown to know the root cause of this segfault, but segfaults are usually caused by your program trying to mess with memory that doesn't belong to it (like trying to call delete on a junk pointer).

the method seems like it should force it to.

Just a guess, but your program might be crashing before reaching the m_glTess = NULL; call.
It looks like it's crashing during the gluDeleteTess call.

[vysero]

Ah I see now, thank you! I thought that might be the case as well because if it was in fact reaching the m_glTess=NULL statement then by the time I see it it should have been NULL. However, since it was reporting the error at line 159 instead of 158 then I thought the error might be occurring at clearData(). I am trying to set debug points but they do not seem to be working. I will look into the make file to see if the debugging is making it into the build.

[Ganado]

Might be of interest: https://stackoverflow.com/a/24914359/8690169 (if you're using g++)
Make sure you are deleting old .o (object) files if you're just now turning on "generate debug symbols".

error at line 159 instead of 158 then I thought the error might be occurring at clearData()

Could be. I have no idea, since I cannot see your code :P

[salem c]

> (gdb) print m_glTess
> $2 = (GLUtesselator *) 0x1

Nobody likes to see 0x1 in a pointer.
It isn't NULL (which obviously means it skips over the guard), and it's nowhere near being a valid pointer.

Two possible things to look for.
1. Make sure m_glTess is initialised to NULL in all constructors, unless that constructor actually initialises it to something proper to start with.

2. This is harder. It means something else overwrote your pointer with garbage.

If you can reliably predict in advance which object is corrupt, then this can be useful.
https://stackoverflow.com/questions/58851/can-i-set-a-breakpoint-on-memory-access-in-gdb
Before you start destructing things, you can set a data breakpoint on the suspect m_glTess to see when it gets written to.