memory corruption while debugging

[Noa Garnett]

I'm developing on C++, using visual studio 6.0 with service pack 5.
I have a memory corruption while debugging. Some of the variables I'm
using are suddenly set to zero while progressing along the code.
The specific location of the memory corruption depends on the names I
give my local variables, on putting some of the codes in curly
brackets - {}, and on having the watch window open.
I already cleaned and re-built my project.
Can anyone help??

thanks
Noa Garnett

 

[Niels Dybdahl]

I'm developing on C++, using visual studio 6.0 with service pack 5.

I have a memory corruption while debugging. Some of the variables I'm
using are suddenly set to zero while progressing along the code.
The specific location of the memory corruption depends on the names I
give my local variables, on putting some of the codes in curly
brackets - {}, and on having the watch window open.
I already cleaned and re-built my project.
Can anyone help??

Two suggestions:
1. Single step through your application
2. Use something like boundschecker

Niels Dybdahl

 

[Peter Koch Larsen]

Two suggestions:
1. Single step through your application
2. Use something like boundschecker

Niels Dybdahl

3. Ask in a Microsoft newsgroup
4. Set a data breakpoint on the variable

/Peter

 

[Howard]

I'm developing on C++, using visual studio 6.0 with service pack 5.
I have a memory corruption while debugging. Some of the variables I'm
using are suddenly set to zero while progressing along the code.
The specific location of the memory corruption depends on the names I
give my local variables, on putting some of the codes in curly
brackets - {}, and on having the watch window open.
I already cleaned and re-built my project.
Can anyone help??

thanks
Noa Garnett

It may not actually be memory corruption (although, not seeing the code, it
certainly *could* be). It may be that your debugger is simply confused.

In VC++6, I've seen the debugger get confused as to which variable it's
actually looking at when there are multiple variables with the same name.
But, I've also had actual behavior problems (not just debugger issues) when
using VC++6 and having multiple instaces of variables with the same name.

Check for any local variables that are declared twice, or that have the same
name as a member (or global) variable. If you're using the same named
variable twice, try declaring it just once at the top of the function, or
else renaming each instance (such as i1, i2, and i3 instead of just i for
them all). This includes loop variables! If you've got a local variable
named the same as a class member or global, try renaming it to something
else.

-Howard

 

[Noa Garnett]

It may not actually be memory corruption (although, not seeing the code, it
certainly *could* be). It may be that your debugger is simply confused.

In VC++6, I've seen the debugger get confused as to which variable it's
actually looking at when there are multiple variables with the same name.
But, I've also had actual behavior problems (not just debugger issues) when
using VC++6 and having multiple instaces of variables with the same name.

Check for any local variables that are declared twice, or that have the same
name as a member (or global) variable. If you're using the same named
variable twice, try declaring it just once at the top of the function, or
else renaming each instance (such as i1, i2, and i3 instead of just i for
them all). This includes loop variables! If you've got a local variable
named the same as a class member or global, try renaming it to something
else.

-Howard

1. thanks.
2. but the application indeed crashes later, in a way consistent with
the memory corruption I see in the debug watch.
3. I have many multiple variables with the same name. Does the
phenomenon you describe occur only while watching variables on
debugger, or can it cause problems while working on release mode, too?

 

[Dave Townsend]

I'm developing on C++, using visual studio 6.0 with service pack 5.
I have a memory corruption while debugging. Some of the variables I'm
using are suddenly set to zero while progressing along the code.
The specific location of the memory corruption depends on the names I
give my local variables, on putting some of the codes in curly
brackets - {}, and on having the watch window open.
I already cleaned and re-built my project.
Can anyone help??

thanks
Noa Garnett

I've been using VC++ for many years now and I've never seen this problem, I
doubt
if you are really seeing a bug in VC++. Most likely you have a memory
corruption
in your program, or you are misintepreting the behavior incorrectly. Make
sure you
do not have any expressions with side effects in your watch windows such as
x++,etc.

You could use the memory watch window and monitor the raw memory used in
your program, first get the addresses of the variables concerned and then
view the
page of memory which contains them.

Alternatively, if you might have a true heap corruption, you can call the
MFC routine
AfxCheckMemory() which will check the heap. Put these calls in the location
where the
alleged corruption is happening to narrow the hunt down.

Post some code if you can so we can peruse this problem.

dave


dave

 

[Howard]

"Howard" <[email protected]> wrote in message

1. thanks.
2. but the application indeed crashes later, in a way consistent with
the memory corruption I see in the debug watch.
3. I have many multiple variables with the same name. Does the
phenomenon you describe occur only while watching variables on
debugger, or can it cause problems while working on release mode, too?

It happens in my release builds, too, (but only with my apps built with
VC++, as far as I can tell). When I changed my local variables' names to be
unique (with respect to each other, and to global variables, and to member
variables), the problems went away. (It's fine to have local variables in
one function the same as local variables in another function, though, since
they're in different scopes.)

-Howard

 

[Howard]

"Howard" <[email protected]> wrote in message

1. thanks.
2. but the application indeed crashes later, in a way consistent with
the memory corruption I see in the debug watch.
3. I have many multiple variables with the same name. Does the
phenomenon you describe occur only while watching variables on
debugger, or can it cause problems while working on release mode, too?

Other thoughts: if your'e seeing memory corruption, look especially for
code that writes beyond the end of an array, or use of pointers that have
not been properly initialized before their first use, or where the objects
they point to have been deleted. Such errors can cause problems in
completely separate parts of your code, and are most often the culprits for
*strange* behavior.

-Howard