delete pointers: why is this working!!??

[mufasa]

i believe deleting an already delete pointer should give me a
segmentation fault! Why, then, is the following working? I am using gcc
version 3.0.2.

#include<stdio.h>
#include <string>
using namespace std;

int main()
{
string * j = new string("this prog should dump core!");
printf("\n%s\n",j->c_str());
delete j;
delete j;
}

 

[Alf P. Steinbach]

* mufasa:

i believe deleting an already delete pointer should give me a
segmentation fault! Why, then, is the following working? I am using gcc
version 3.0.2.

#include<stdio.h>
#include <string>
using namespace std;

int main()
{
string * j = new string("this prog should dump core!");
printf("\n%s\n",j->c_str());
delete j;
delete j;
}

It's Undefined Behavior, which means that any result whatsoever is
acceptable as far as the standard is concerned.

General advice as you're learning the language:

1) Don't use raw pointers.
2) Don't use raw pointers.
3) Don't ... You get the idea.

Also, consider using C++ iostreams, which are more type-safe than C printf.

 

[Rolf Magnus]

i believe deleting an already delete pointer should give me a
segmentation fault!

No, it should give you undefined behavior.

Why, then, is the following working?

Because that is one instance of "undefined behavior".

 

[Kehuei Huang]

the std::string class might've used a reference counting allocation for the
actually string content. The reference counting rule can be "delete the
content if reference count drops to zero; if the reference count is
negative, don't do any deletion".

you should refer to the actually implementation to see what is going on
there.

don't do double deletion, that's all.

 

[Krishanu Debnath]

[top posting fixed]

the std::string class might've used a reference counting allocation for the
actually string content. The reference counting rule can be "delete the
content if reference count drops to zero; if the reference count is
negative, don't do any deletion".

I don't see how your /proposed/ reference counting avoid undefined
behavior, when you are deleting the pointer j twice.

you should refer to the actually implementation to see what is going on
there.

don't do double deletion, that's all.

Krishanu

 

[joe.els]

[top posting fixed]

the std::string class might've used a reference counting

allocation
for the

actually string content. The reference counting rule can be "delete the
content if reference count drops to zero; if the reference count is
negative, don't do any deletion".

I don't see how your /proposed/ reference counting avoid undefined
behavior, when you are deleting the pointer j twice.

you should refer to the actually implementation to see what is going on
there.

don't do double deletion, that's all.

Krishanu

 

[joe.els]

Hi

Sorry about the previous "empty" message.

I'm using glibc-2.3.4 with gcc-3.3.5.
When I do delete twice my program aborts:
"*** glibc detected *** double free or corruption (fasttop): 0x08049db0
***
Aborted"

I didn't expect such a descriptive error message.

Anyway, new and delete are merely mechanisms of telling the system,
which sections of memory you're using.
After calling the delete operator on a pointer, the memory pointed to
becomes available to the system again. Until the system reasigns that
memory you'll be able to "access" it.
ie:
int& a = new int;
a = 5;
cout << a; // "5"
delete &a;
cout << a; // "5"
.... // some time later
cout << a; // whatever's in memory at that time.


It is posible that having the two delete statements next to each other,
would allow your program to run without any problems.

Remember new and delete are class (static) operators not instance
operators.
It is posible to call them with out having any valid instances.

Also if you have to use raw pointer, set them to null after calling the
delete, then you'll be able to tell if it's safe to use.
IE:
SomeClass* sc = new SomeClass();
.... // some time later
if (sc) // true
{
sc->someFunction();
}
.... // some time later
if (sc) // true
{
delete sc;
sc = 0;
}
.... // some time later
if (sc) // false
{
sc->someFunction();
}

Joe

 

[mufasa]

How about this code? Is the delete statement here trying to break some
ownership rules (I think that's the case .. still verifying)?
Because this segment is dumping core as well!

#include<stdio.h>
#include <string>
using namespace std;

int main()
{
string someString("abc");
char * c= new char[someString.length()];

c = const_cast<char*>(someString.c_str());

printf("\n%s\n",c);
delete [] c;
}

 

[Krishanu Debnath]

Hi

Sorry about the previous "empty" message.

Post with proper context/quote is much appreciated.

I'm using glibc-2.3.4 with gcc-3.3.5.

[all compiler/implementation specific details snipped]

After calling the delete operator on a pointer, the memory pointed to
becomes available to the system again. Until the system reasigns that
memory you'll be able to "access" it.
ie:
int& a = new int;

[invalid c++ code fragments snipped]

It is posible that having the two delete statements next to each other,
would allow your program to run without any problems.

After invoking UB, it can run without any problems, it may also order
a 'peppy paneer pizza' from Pizza Hut for you. Best of luck !

Krishanu

 

[Rolf Magnus]

How about this code? Is the delete statement here trying to break some
ownership rules (I think that's the case .. still verifying)?
Because this segment is dumping core as well!

#include<stdio.h>
#include <string>
using namespace std;

int main()
{
string someString("abc");
char * c= new char[someString.length()];

Here, you allocate an array of 3 char and assign its starting address to c.

c = const_cast<char*>(someString.c_str());

Here, you overwrite c, losing the only pointer you had to your dynamically
allocated array. This is a memory leak. Also, the const_cast is a *very*
bad idea, as are almost all const_casts.

printf("\n%s\n",c);
delete [] c;

Here, you try to delete the array that was returned by c_str(), so the
answer to your question is yes, you break an ownership rule. You don't even
know whether the pointer returned by c_str() actually points to dynamically
allocated memory.

 

[mufasa]

Am I not trying to break any ownership rules herein (see below) :

#include <string>
#include<iostream.h>

using namespace std;

int main()
{
char * a = new char('a');
cout << *a <<endl; //prints 'a'
char * c = new char();
c = a;
delete c;
cout << *a <<endl; //prints '0'. which means that 'delete c'
//did delete the contents
owned by a! right?
delete a;
delete a; //why does this double delete
work!
}

 

[Rolf Magnus]

Am I not trying to break any ownership rules herein (see below) :

There is no real ownership semantic here. You're allocating memory yourself,
and you're deallocating it yourself.

#include <string>
#include<iostream.h>

using namespace std;

int main()
{
char * a = new char('a');
cout << *a <<endl; //prints 'a'
char * c = new char();
c = a;

Like in the previous example, you loose the allocated memory here. Note that
c is only a pointer, just as a. "c = a" means that you let c point to the
very same memory location that a was (and still is) pointing to (the one
you allocated previously with "new char('a')"). You didn't do anything to
the memory that you allocated with "new char()", you only let the pointer c
point somewhere else. That memory is still there, but you don't have any
pointer pointing to it. So that memory is lost, unaccessable, undeletable.

delete c;

This frees the memory allocated with "new char('a')" that both a and c are
pointing to.

cout << *a <<endl; //prints '0'. which means that 'delete c'
//did delete the contents

This invokes undefined behavior (anything can happen, from printing '0' to a
system crash). You're not allowed to dereference a pointer that points to
memory that was already freed.

owned by a! right?
delete a;
delete a; //why does this double delete
work!
}

Again, undefined behavior. It might "work" (i.e. not crash), but it could
also crash or do anything else. The C++ standard doesn't give you any
guarantee about what happens. It might be system or compiler specific or
even depend on the moon phase.

 

[Grant Schoep]

How about this code? Is the delete statement here trying to break some
ownership rules (I think that's the case .. still verifying)?
Because this segment is dumping core as well!

#include<stdio.h>
#include <string>
using namespace std;

int main()
{
string someString("abc");
char * c= new char[someString.length()];

c = const_cast<char*>(someString.c_str());

printf("\n%s\n",c);
delete [] c;
}

Let me just say this. I know this may be an example. But if your writing
C++, DO NOT use printf. :> I ticks me off to no end when I look at
"Intro to C++ books" and see they use examples that have printf instead
of C++. F'ing ludicruous...

Anyways, the other hint here is you have a cast. Cast's are wrong and
evil. But I understand what your trying to do with this one here... ok
its and exmaple.

Your char*'s pointer is now a pointer to memory owned by the object
someString. When that object goes out of scope, it will call string's
destructor. But.. your deleting that pointer memory, in a way that is not
using the class, or its destructor. Hmm, I don't really know what its
doing. It is sorta like writing this.

int main()
{
string someString("abc");
delete someString; //you can't do this either.
}

Actually, the above example shouldn't compile.