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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Rolf Magnus]

mufasa wrote:

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".
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;
}

[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.

"mufasa" <so*****@gmail.com> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...

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;
}

[Krishanu Debnath]

[top posting fixed]

Kehuei Huang wrote:

"mufasa" <so*****@gmail.com> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...

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;
}

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]

Krishanu Debnath wrote:

[top posting fixed]

Kehuei Huang wrote:

"mufasa" <so*****@gmail.com> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...

i believe deleting an already delete pointer should give me a
segmentation fault! Why, then, is the following working? I am using gccversion 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;
}

> 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]

jo*****@dariel.co.za wrote:

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]

mufasa wrote:

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]

mufasa wrote:

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.