Pointer being set to null (not by me)??

M

Matthew

Hello,

I have an executable that is calling a DLL I have built. The DLL
requires two static libraries to run (genuine statics as opposed to
the 'stub' .lib files that still require a DLL).

In the DLL source I have the following code...

{
char *l_H = (char *)malloc(200);
sprintf(l_H, "Hello");

namespace1::namespace2::namespace3::Thing l_Thing;

free(l_H);
}

....now the strange thing is that after executing the initialization of
l_Thing, l_H has been set to NULL (0x00000000).

I have a breakpoint that is triggered when free(l_H) is reached (I
know for a fact that the free() has not yet executed as VC++
breakpoints are triggered before a line of code is processed. Also I
have had other lines of code between free() and the initialization of
Thing - not shown here - where I see l_H has been reset). Also, l_H is
not going out of scope before the free() is reached.

l_H is local and Thing knows nothing about it. The constructor of
Thing is as follows (in .cpp file)...

namespace namespace1
{
namespace namespace2
{
namespace namespace3
{
Thing::Thing()
{
m_D = 0;
}

...other code ...

}
}
}

....where m_D is declared as a double with private access in the header
file.

Observations
------------

- I declare m_D as an int, the code behaves as expected (i.e. "Hello"
remains in l_H after the initialization of Thing).

- If I remove m_D = 0 from the constructor of Thing, the code works
normally

- If I declare a double and assign it a value in the main code (after
removing m_D = 0 from the Thing constructor) after the initialization
of Thing, the code works as normal.

I am posting this in microsoft.public.vc.language and comp.lang.c++ as
I am not sure whether it's a Microsoft thing or a C++ issue.

Can anyone explain this?

Thanks,

Matthew
 
M

MiniDisc_2k2

Are you sure that malloc() isn't returning NULL? Pointers don't initialize
themselves to NULL, the compiler just picks some random address (usually
invalid). VC++ in debug mode picks 0xCCCCCCCC, therefore we know it's
actually being set to 1_H. Check to make sure malloc() isn't returning NULL,
which would indicate an error.
 
M

MiniDisc_2k2

invalid). VC++ in debug mode picks 0xCCCCCCCC, therefore we know it's
actually being set to 1_H.

I'm sorry that's "therefore we know it's actually being set to __NULL__"
 
M

Matthew

Thanks for the reply.

The malloc is not returning NULL as when I step over the sprintf
statement in the IDE debugger, I see "Hello" in l_H.
 
A

Alf E. Helseth

Matthew said:
Hello,

I have an executable that is calling a DLL I have built. The DLL
requires two static libraries to run (genuine statics as opposed to
the 'stub' .lib files that still require a DLL).

In the DLL source I have the following code...

{
char *l_H = (char *)malloc(200);
sprintf(l_H, "Hello");

namespace1::namespace2::namespace3::Thing l_Thing;

free(l_H);
}

...now the strange thing is that after executing the initialization of
l_Thing, l_H has been set to NULL (0x00000000).

I have a breakpoint that is triggered when free(l_H) is reached (I
know for a fact that the free() has not yet executed as VC++
breakpoints are triggered before a line of code is processed. Also I
have had other lines of code between free() and the initialization of
Thing - not shown here - where I see l_H has been reset). Also, l_H is
not going out of scope before the free() is reached.

l_H is local and Thing knows nothing about it. The constructor of
Thing is as follows (in .cpp file)...

namespace namespace1
{
namespace namespace2
{
namespace namespace3
{
Thing::Thing()
{
m_D = 0;
}

...other code ...

}
}
}

...where m_D is declared as a double with private access in the header
file.

Observations
------------

- I declare m_D as an int, the code behaves as expected (i.e. "Hello"
remains in l_H after the initialization of Thing).

- If I remove m_D = 0 from the constructor of Thing, the code works
normally

- If I declare a double and assign it a value in the main code (after
removing m_D = 0 from the Thing constructor) after the initialization
of Thing, the code works as normal.

I am posting this in microsoft.public.vc.language and comp.lang.c++ as
I am not sure whether it's a Microsoft thing or a C++ issue.

Can anyone explain this?

I'm a bit curious of the "other code" in the Thing's contructor, if
you're overwriting say an array on the stack here, you might get exactly
this behaviour.
Change in behaviour when adding/removing also points in this direction.

Overwriring the stack is an evil and often hard-to-get error...

Does i really fails in a sample as small as what you've shown?


-Alf
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top