Thread: Call to destructor crashes program

  1. #1
    Registered User
    Join Date
    Apr 2011
    Posts
    8

    Call to destructor crashes program

    Thanks to the help from all you lovely people on my last problem I've managed to crack on and make my program work the way I wanted.

    For a quick catchup: I have a program that creates objects on the fly with new every time a certain event happens, and stores the memory locations of these new objects in a database as an integer value. I can then interact with any specific object by converting the integer value back into a pointer. All this is working brilliantly!

    However, when the object is destroyed using delete on that pointer, the destructor is called and executes all it's code correctly, then the program crashes. My compiler (Visual C++ Express) throws a message saying No Source Available with "Call stack location: Table::`scalar deleting destructor'() + 0x2b bytes".

    Am I doing something wrong by calling delete on a pointer to the object?

    Relevant code below. I have omitted all the database query code:

    Code:
    unsigned long tablename; 
    // this variable holds the memory location (in integer form) 
    // of a specific object, retrieved from the database.
    
    Table* tableptr; // pointer of class type
    tableptr = (Table*)tablename;
    delete tableptr;
    
    // destructor is called correctly
    
    Table::~Table()
    {
    	// more database interaction code which completes successfully
    }

  2. #2
    Registered User
    Join Date
    Aug 2010
    Location
    Poland
    Posts
    733
    This code is not enough to tell what is wrong. There is a possibility, that a completely different and irrelevant thing went wrong. I don't think that storing pointer in a data base is a good idea. Program/database may crash/quit and the values will remain and will be invalid in the next run. Also, use reinterpret_cast for int <=> pointer conversions. What is size of long? AFAIK it's always 32 bit in MSVC and as you know, pointer is 64-bit on 64-bit systems.

  3. #3
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    There are three potential problems I can see.

    Firstly, there is no guarantee that a pointer value will survive a round-trip through an unsigned long (i.e. pointer -> unsigned long -> pointer is not guaranteed to give the original pointer value).

    Second, even if a pointer can survive that round-trip, you will have problems if your program exits and reads from the database again, as it is not guaranteed that values in the database will correspond to any valid object created by your program when subsequently run. [And if this is not a factor, it needs to be asked why you are storing the values in a database - there are alternative options].

    Third, even if the object being deleted is valid (i.e. created with operator new) the most common causes of crash when invoking a destructor or operator delete is pointer molestation. For example;
    Code:
        Object *x = new Object;
        SomethingElse *y = NULL;
        y->MemberFunctionThatChangesASomethingElse();   // dereferencing NULL and writing to random memory here
        delete x;                                                           // crash occurs here
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  4. #4
    Registered User
    Join Date
    Apr 2011
    Posts
    8
    Thanks for feedback both of you. I figured there was nothing wrong with the pointers since I was able to interact with the objects, but I'll go back over the pointer conversions and make sure the byte length is correct. I had a quick look and see that there are some native typedefs designed to handle converting pointer values to int so it shouldn't be too hard.

    Regarding the database, it's true that I don't need to worry about losing the contents of the memory location table, but I have to use the database for other things so it made sense at the time to keep it all in the same place. I could change the code to use a vector of a structure type that holds the object's unique ID and a pointer to it. Then I wouldn't have to worry about converting pointers at all! Would this be a better direction?

  5. #5
    Registered User
    Join Date
    Aug 2010
    Location
    Poland
    Posts
    733
    Pointers should not be visible to the user. You should store unique ID (vector's indices at least).

    From 5.2.10.5:
    A value of integral type or enumeration type can be explicitly converted to a pointer.64) A pointer converted
    to an integer of sufficient size (if any such exists on the implementation) and back to the same pointer type
    will have its original value; mappings between pointers and integers are otherwise implementation-defined.
    So, if the integer type is large enough to hold the pointer, the pointer's value will survive the 'pointer -> int -> pointer' conversion

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. My I/O Program crashes, I need some help
    By Guti14 in forum C Programming
    Replies: 4
    Last Post: 09-24-2004, 01:16 AM
  2. Odd program crashes
    By Mithoric in forum Windows Programming
    Replies: 3
    Last Post: 03-20-2004, 11:37 PM
  3. call a destructor
    By kashifk in forum C++ Programming
    Replies: 17
    Last Post: 07-17-2003, 06:06 AM
  4. Program crashes
    By fkheng in forum C Programming
    Replies: 12
    Last Post: 06-24-2003, 04:59 AM
  5. program crashes
    By Strut in forum Linux Programming
    Replies: 3
    Last Post: 02-10-2002, 10:49 AM