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]

"Niels Dybdahl" <nd*@fjern.detteesko-graphics.com> skrev i en meddelelse
news:41*********************@dtext02.news.tele.dk. ..

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

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

/Peter

[Howard]

"Noa Garnett" <no********@hotmail.com> wrote in message
news:7e**************************@posting.google.c om...

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

[Howard]

"Noa Garnett" <no********@hotmail.com> wrote in message
news:7e**************************@posting.google.c om...

"Howard" <al*****@hotmail.com> wrote in message

news:<Sm*********************@bgtnsc05-news.ops.worldnet.att.net>...

"Noa Garnett" <no********@hotmail.com> wrote in message
news:7e**************************@posting.google.c om...

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

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]

"Noa Garnett" <no********@hotmail.com> wrote in message
news:7e**************************@posting.google.c om...

"Howard" <al*****@hotmail.com> wrote in message

news:<Sm*********************@bgtnsc05-news.ops.worldnet.att.net>...

"Noa Garnett" <no********@hotmail.com> wrote in message
news:7e**************************@posting.google.c om...

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

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