Program layout in memory (is anything overwriting my static pointer?)

[simonl]

Hi,

I've been given the job of sorting out a crash in our product for
which we have the crash information and an avi of the event (which
can't possibly match but more of that later...) (btw this is a single
threaded VC9 / win32 app)

The call stack for the bug effectively goes

void* myBuf;

void myFunc()
{

if( myBuf )
{
(maybe some stuff happens here)
do something with myBuf.. except it's NULL in the debug
information I have
}

My question is.. can anything in the heap have overwritten myBuf with
NULL?
Another possibilty is another static variable, say a fixed size array
where we're writing outside the bounds.

My boss just told me we're using a memory manager called Smartheap,
crap knows what that's doing..

Any comments?

[Ian Collins]

simonl wrote:

Hi,

I've been given the job of sorting out a crash in our product for
which we have the crash information and an avi of the event (which
can't possibly match but more of that later...) (btw this is a single
threaded VC9 / win32 app)

The call stack for the bug effectively goes

void* myBuf;

void myFunc()
{

if( myBuf )
{

}

My question is.. can anything in the heap have overwritten myBuf with
NULL?

One the heap? If your application is threaded and writes to myBuf are
unguarded, anything might happen. myBuf isn't static, its global.

--
Ian Collins.

[Wolfgang Draxinger]

simonl wrote:

Hi,

I've been given the job of sorting out a crash in our product
for which we have the crash information and an avi of the event
(which can't possibly match but more of that later...) (btw
this is a single threaded VC9 / win32 app)

The call stack for the bug effectively goes

void* myBuf;

void myFunc()
{

if( myBuf )
{
(maybe some stuff happens here)
do something with myBuf.. except it's NULL in the debug
information I have
}

My question is.. can anything in the heap have overwritten
myBuf with NULL?
Another possibilty is another static variable, say a fixed size
array where we're writing outside the bounds.

My boss just told me we're using a memory manager called
Smartheap, crap knows what that's doing..

Any comments?

Testing for NULL != myBuf (note in C you should always test
against the NULL macro explicitly, it may be defined as not
being of value 0 on all systems, 0xffffffff may be as common),
just tells you if the pointer has been marked invalid/NIL
explicitly. It doesn't tell you however if it's valid.

You may have a perfectly non-NULL pointer, that's still not
pointing into valid memory.

Eventually you expect myBuf to be NULL if it's not initialized.
(Big) surprise though: Variables not being initialized
explicitly can have any value until getting a value assigned.

So add these two changes to your program, and see if it works
then:

- void* myBuf;
+ void *myBuf = NULL;

- if( myBuf )
+ if( NULL != myBuf )

And you might try test your program with a debugger, set a watch
on myBuf, to see when it changes.

Wolfgang Draxinger
--
E-Mail address works, Jabber: he******@jabber .org, ICQ: 134682867

[Richard Bos]

Wolfgang Draxinger <wd********@dar kstargames.dewr ote:

Testing for NULL != myBuf (note in C you should always test
against the NULL macro explicitly, it may be defined as not
being of value 0 on all systems, 0xffffffff may be as common),

This is nonsense. A constant integer expression with the value zero
(such as, ooh, perhaps 0) will _always_ compare equal to a null pointer,
no matter how that null pointer is represented in memory; and a boolean
test against any scalar, including pointers, _always_ happens as if it
was written to include !=0.

Richard

[simonl]

>

>
myBuf isn't static, its global.

OK, I'm not too clear on this. Both global and static variables in
this case have the same scope and lifetime, but are stored in
different areas of process memory?

[Ben Bacarisse]

Ian Collins <ia******@hotma il.comwrites:

simonl wrote:

<snip>

>>... btw this is a single threaded VC9 / win32 app

<snip>

If your application is threaded and writes to myBuf are
unguarded, anything might happen.

I seems not.

--
Ben.

[Ben Bacarisse]

simonl <si*******@hotm ail.comwrites:

I've been given the job of sorting out a crash in our product for
which we have the crash information and an avi of the event (which
can't possibly match but more of that later...) (btw this is a single
threaded VC9 / win32 app)

The call stack for the bug effectively goes

void* myBuf;

void myFunc()
{

if( myBuf )
{
(maybe some stuff happens here)
do something with myBuf.. except it's NULL in the debug
information I have
}

My question is.. can anything in the heap have overwritten myBuf with
NULL?
Another possibilty is another static variable, say a fixed size array
where we're writing outside the bounds.

You need to ask yourself if the debug information is reliable. I have
no reason to doubt it, but do be sure. You can waste a lot of time
using unreliable information.

If the data is sound then something has altered myBuf between testing
it and the crash point where your debug data shows it to be NULL. The
most likely suspects are, as you say, an out of bounds access to a
nearly object, but another possibility is access though an invalid
pointer. Is there a lot of code being executed between the if and the
reported crash? Can you reproduce the error or must you debug this
fro one debug data set?

My boss just told me we're using a memory manager called Smartheap,
crap knows what that's doing..

I don't like the sound of that, but I know nothing about it.

--
Ben.

[Chris Dollin]

Wolfgang Draxinger wrote:

simonl wrote:

(fx:snip)

>void myFunc()
{

if( myBuf )
{
(maybe some stuff happens here)
do something with myBuf.. except it's NULL in the debug
information I have
}

My question is.. can anything in the heap have overwritten
myBuf with NULL?
Another possibilty is another static variable, say a fixed size
array where we're writing outside the bounds.

My boss just told me we're using a memory manager called
Smartheap, crap knows what that's doing..

Any comments?

Testing for NULL != myBuf (note in C you should always test
against the NULL macro explicitly,

False.

it may be defined as not
being of value 0 on all systems, 0xffffffff may be as common),

True but irrelevant; null pointers are /required/ to behave
like 0 in a condition, just as they are /required/ to compare
equal to null pointer constants in comparisions. If the bitwise
representation of a null pointer is 0xffffffff, then the compiler
must insert the appropriate code, just as it must for

int *mylittlenullpo inter = 0;

Eventually you expect myBuf to be NULL if it's not initialized.
(Big) surprise though: Variables not being initialized
explicitly can have any value until getting a value assigned.

Not static variables; they are implicitly initialised to
suitable zeros. So, if they're pointers, they get initialsed
the null pointer.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[viza]

On Thu, 09 Oct 2008 12:14:07 +0200, Wolfgang Draxinger wrote:

Testing for NULL != myBuf (note in C you should always test against the
NULL macro explicitly, it may be defined as not being of value 0 on all
systems, 0xffffffff may be as common)

Since:

if( NULL == ptr )

is always exactly equivalent to:

if( ! ptr )

I prefer:

if( !! ptr )

to

if( NULL != ptr )

the two are equivalent.

[Richard Bos]

viza <to******@gm-il.com.obviousc hange.invalidwr ote:

On Thu, 09 Oct 2008 12:14:07 +0200, Wolfgang Draxinger wrote:

Testing for NULL != myBuf (note in C you should always test against the
NULL macro explicitly, it may be defined as not being of value 0 on all
systems, 0xffffffff may be as common)

Since:

if( NULL == ptr )

is always exactly equivalent to:

if( ! ptr )

I prefer:

if( !! ptr )

to

if( NULL != ptr )

the two are equivalent.

And surprise, surprise, they're both also equivalent to the superior

if (ptr)

Richard