Any recommended debugging techniques I'm missing?

Question

0.00/5 (No votes)

See more:

I have a global that has a pointer member in it. A program function calls into the global and initializes that pointer. Then later the pointer is accessed. For some reason in Debug mode, the pointer reads 'NULL' instead of the address of the newed pointer.

Using Visual Studio's Immediate window, the address of the pointer is the same at both places, so I don't appear to have a variable name conflict. The pointer is in a library that is a project of the solution, and is declared global there and 'extern'al in the main application. When stepping through, Visual Studio's mouse hover watch shows the pointer member holding a number (memory location), but when assigning it to a local variable, that local variable becomes NULL.

Oddly, the program seems to work in Release mode. The fact that the Debug version is flakey is concerning.

Does anyone have any ideas to help debug this further?

Thanks!

What I have tried:

I've tried moving the initialization of the member to the line right before the access:

C++

gDwlGlobals->setupItemsNeedingHwnd(); //Initialize 'dialogs'
void * address = &gDwlGlobals->dialogs; //For debugging, to see address
dwl::WinDialogs * d = gDwlGlobals->dialogs; //Here it is NULL, even though I just
                                            //stepped through and watched it initialize
d = gDialogs; //If, when I initialize it in 'setupItems...', I create another global
              //pointer and assign the memory address to it, and use that instead
              //of the main gDwlGlobal->dialogs, it will show up correctly here!

It didn't work, although the second assignment to a secondary global did work.

Another clue is that the 'hover' action in the debugger where I take the pointer's address as a void * shows the address being 20 bytes off from the value given by the Immediate window. What would cause that?

Posted 27-Mar-18 20:21pm

David O'Neil

Updated 27-Mar-18 21:39pm

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Jochen Arndt · Answer 1 · 2018-03-27T21:41:00

This can't be answered without knowing the type of the gDwlGlobals variable, how it is initialised, and what setupItemsNeedingHwnd() is doing (what is assigned to the dialogs member).

But

void * address = &gDwlGlobals->dialogs;

gets the address of the dialogs member (the address of gDwlGlobals plus an offest) while

dwl::WinDialogs * d = gDwlGlobals->dialogs;

gets the value of the dialogs member (which is also a pointer).

These values will never be the same. It explains also why you have an offset of 20 bytes between address and gDwlGlobals shown by the immediate window.

One difference between debug and release builds is that variables are initialised with zero / NULL in debug builds while they contain random values in release builds. This applies not to global (static) variables which are always initialised with zero / NULL. But your gDwlGlobals is a pointer so that only the pointer is initialised with NULL.

Ensure also that your program has executed until a specific point before checking variables in the Immediate window. If you set for example a breakpoint on the setupItemsNeedingHwnd() line, that will not be executed. To see the effects of that function you have to set the breakpoint on the next line.