Same variable names inside multiple sub-scopes results in delete tocrash sporadically

[pvinodhkumar]

#include <stdio.h>
#include <string.h>

struct A
{
void* myPtr;
};

int main()
{
{
A a;
char* aPtr = new char[1024];
char* bPtr = aPtr;
a.myPtr = aPtr;

memset(aPtr, 'A', 1024);

// delete 1
delete aPtr;
}

{
A a;
char* aPtr = new char[1024];
char* bPtr = aPtr;
a.myPtr = aPtr;

memset(aPtr, 'A', 1024);

// delete 2
delete aPtr;
}
}

The delete2 crashes sometimes.

The compiler used is I use Microsoft Visual Studio 2008, with Service Pack1.

Any obvious reason for it to crash?

 

[Stefan van Kessel]

char* aPtr = new char[1024];
delete aPtr;

The delete2 crashes sometimes.

When you use new ... [] you need to use delete[] ...

 

[pvinodhkumar]

char* aPtr = new char[1024];

delete aPtr;

The delete2 crashes sometimes.

When you use new ... [] you need to use delete[] ...

Thanks. You are Right. I used the right delete [] in actual code.
Still wondering why it is happening? My suspicion is MSVC not supporting too much of neting and same names in them

 

[pvinodhkumar]

#include <stdio.h>

#include <string.h>



struct A

{

void* myPtr;

};



int main()

{

{

A a;

char* aPtr = new char[1024];

char* bPtr = aPtr;

a.myPtr = aPtr;



memset(aPtr, 'A', 1024);



// delete 1

delete aPtr;

}



{

A a;

char* aPtr = new char[1024];

char* bPtr = aPtr;

a.myPtr = aPtr;



memset(aPtr, 'A', 1024);



// delete 2

delete aPtr;

}

}



The delete2 crashes sometimes.



The compiler used is I use Microsoft Visual Studio 2008, with Service Pack1.



Any obvious reason for it to crash?

Please read my delete as delete [] . It happens when properly doing a delete [] as well.

 

[Fred Zwarts \(KVI\)]

wrote in message

#include <stdio.h>

#include <string.h>



struct A

{

void* myPtr;

};



int main()

{

{

A a;

char* aPtr = new char[1024];

char* bPtr = aPtr;

a.myPtr = aPtr;



memset(aPtr, 'A', 1024);



// delete 1

delete aPtr;

}



{

A a;

char* aPtr = new char[1024];

char* bPtr = aPtr;

a.myPtr = aPtr;



memset(aPtr, 'A', 1024);



// delete 2

delete aPtr;

}

}



The delete2 crashes sometimes.



The compiler used is I use Microsoft Visual Studio 2008, with Service
Pack1.



Any obvious reason for it to crash?

Please read my delete as delete [] . It happens when properly doing a
delete [] as well.

From this last remark, I conclude that the code that you posted is not the
actual code that crashes. Are there more differences? For example, did you
omit parts of struct A in this post? If A has a destructor that uses the
pointer, then it is clear that you delete the pointer before the destruction
of A, so that its destructor uses an invalid pointer.
For this reason, the FAQ tells you to post the exact code that reproduces
the problem.

 

[Krice]

        void* myPtr;

Don't do this in C++.

                char* bPtr = aPtr;

This is wrong too. Your code is crap, that's why is crashes.

 

[pvinodhkumar]

wrote in message

#include <stdio.h>

#include <string.h>



struct A

{

void* myPtr;

};



int main()

{

{

A a;

char* aPtr = new char[1024];

char* bPtr = aPtr;

a.myPtr = aPtr;



memset(aPtr, 'A', 1024);



// delete 1

delete aPtr;

}



{

A a;

char* aPtr = new char[1024];

char* bPtr = aPtr;

a.myPtr = aPtr;



memset(aPtr, 'A', 1024);



// delete 2

delete aPtr;

}

}



The delete2 crashes sometimes.



The compiler used is I use Microsoft Visual Studio 2008, with Service
Pack1.



Any obvious reason for it to crash?

Please read my delete as delete [] . It happens when properly doing a

delete [] as well.

From this last remark, I conclude that the code that you posted is not the

actual code that crashes. Are there more differences? For example, did you

omit parts of struct A in this post? If A has a destructor that uses the

pointer, then it is clear that you delete the pointer before the destruction

of A, so that its destructor uses an invalid pointer.

For this reason, the FAQ tells you to post the exact code that reproduces

the problem.

Thanks for the response. Except for my first typo everything is fine. Request everyone to make a note of it. Please let me know in case if there is a problem of same names and multiple scope or some other issue.

Thanks Again.

 

[Øyvind Røtvold]

(e-mail address removed) writes:

[ ... ]

Thanks for the response. Except for my first typo everything is fine.

What's that suppose to mean? Is there still a problem with your code?
What is your code?

Request everyone to make a note of it.

No, you post the exact code that produces this problem, the code
should be well formed as far as you can tell, and we will take it from
there.

Please let me know in case if there is a problem of same names and
multiple scope or some other issue.

If you think there's a problem with same names then just modify the
code to use different names and see if that removes the problem.



Also: If you've paid for this product (Visual Studio) and/or have
support for it then send the same well formed code to the supplier and
ask them about the issue. If you can expose a bug in their product
with this simple code they should appreciate that.

 

[pvinodhkumar]

(e-mail address removed) writes:



[ ... ]

Thanks for the response. Except for my first typo everything is fine.

What's that suppose to mean? Is there still a problem with your code?

What is your code?

Request everyone to make a note of it.

No, you post the exact code that produces this problem, the code

should be well formed as far as you can tell, and we will take it from

there.

Please let me know in case if there is a problem of same names and

multiple scope or some other issue.

If you think there's a problem with same names then just modify the

code to use different names and see if that removes the problem.







Also: If you've paid for this product (Visual Studio) and/or have

support for it then send the same well formed code to the supplier and

ask them about the issue. If you can expose a bug in their product

with this simple code they should appreciate that.

Thanks Again.

--

.. Øyvind - soon to appear in a kill file near you.

.. Ignorance can be cured; stupidity is forever.

Hi Thanks for the reply. Yes, giving different names solves the problem in the production code. However, the problem does not occur when you have onlythis much in a program(i.e on a sample program). My program has thousands of lines of code and I am not able to post all those lines due to legal aspects with my employer.

That is why my suspicion is somehow the compiler has this same name bug in certain not so simple cases. Thanks so much.

 

[pvinodhkumar]

(e-mail address removed) writes:








You are focusing on an assumed problem.



The only problem with using the same symbol names in isolated

contexts is the tendency to confuse the programmer. If the two

contexts overlap in scope (one block inside another), that gets

even more likely.



If the code you posted, when it is the only thing in the program,

crashes, then post again with the exact message/details/etc. Run

it in a debugger and see what it says.



I will note that the 'delete' lines are the last statements in code

blocks with local variables. So the next thing after 'delete' is

destroying the locals and (possibly) unwinding something on the

stack. *That* may be where it is actually crashing. Try adding

something like:

std::cout << "After delete #1\n";

and see if the crash is really on the delete.



--

Drew Lawson | We were taking a vote when

| the ground came up and hit us.

| -- Cylon warrior

The destructor is a trivial destructor in this case. However I will try let you know. Thanks so much for the response.

 

[Juha Nieminen]

char* aPtr = new char[1024];
delete aPtr;

The delete2 crashes sometimes.

When you use new ... [] you need to use delete[] ...

For that matter, there's very seldom any need to use 'new' and 'delete'
directly in your code, unless you are implementing a special dynamic data
container (and even that happens quite rarely in practice, as it's not
very common to need a data container that's different from what the
standard library offers).

The lesson is: Only use 'new' and 'delete' if you absolutely must. Before
resorting to them, see if the standard containers will do what you want
in the way you want. It will not only be safer and less error-prone, it
will also be much simpler and your code will become clearer and easier
to read.

 

[Single Stage to Orbit]

char* aPtr = new char[1024];
delete aPtr;

The delete2 crashes sometimes.

When you use new ... [] you need to use delete[] ...

For that matter, there's very seldom any need to use 'new' and 'delete'
directly in your code, unless you are implementing a special dynamic data
container (and even that happens quite rarely in practice, as it's not
very common to need a data container that's different from what the
standard library offers).

The lesson is: Only use 'new' and 'delete' if you absolutely must. Before
resorting to them, see if the standard containers will do what you want
in the way you want. It will not only be safer and less error-prone, it
will also be much simpler and your code will become clearer and easier
to read.

As does Item 16 in Scott Meyer's Effective C++. Brilliant book.

 

[Øyvind Røtvold]

(e-mail address removed) writes:

[ ... ]

You should trim the quoting in your replies, also it appears that your
newsreader puts double linefeeds in your quoting.

Hi Thanks for the reply. Yes, giving different names solves the
problem in the production code. However, the problem does not occur
when you have only this much in a program(i.e on a sample
program). My program has thousands of lines of code and I am not
able to post all those lines due to legal aspects with my employer.

OK, you should have indicated that this was just an example in your
original post.

That is why my suspicion is somehow the compiler has this same name
bug in certain not so simple cases. Thanks so much.

The usual advice would be to simplify the original program until you
have something that can be posted, or until the bug disappears, in
your case this appears to be achieved, but I doubt that you've found
the real bug.

Sometimes one comes across a class of bugs where seemingly unrelated
or meaningless changes causes the bug to disappear. Often the bug
isn't at that place at all, rather there's some spurious overwrites
elsewhere in your program, the use of memset with constant numbers as
size may be an indication of a programming style where these kind of
errors would be likely.

Changing other parts of the code may cause code or data to move around
thus making the overwrites hit some other part of your data and cause
some other bug that you may or may not see as a failure in your tests.

I suggest you use a memory access checker such as purify - or the
system that I believe exist within Visual Studio to check for
overwrites.