Odd Dialog creation... when deleting unused line of code

I ran into a very weird problem and after a lot of trial error, narrowed it down to a single line of code that should NOT be causing this problem...

A little background....

We have a very very large VC6 program that was written and modified by several programmers over the past 10+ years. One of the first things that the program does when it runs for the first time, is display a small dialog box centered on the display for some basic input. This dialog is a small subclass of the CDialog class. The subclass changes are very minimal, mostly just process the input results.

I recently removed a section of code and some variable declarations that are no longer used. When the program EXE was "run", this dialog no longer appears centered, it is now in the lower right corner. If I run the program in the VC6 development environment, the dialog appears as normal. For clarification, the subclass does not control any of the dialog positioning whatsoever.

Restoring the removed code and then via trial and error, removing each line individually, recompiling and executing the EXE, I have narrowed it down to a single line of code. Keeping the line, the dialog appears as anticipated. Removing it, the dialog moves to the corner.

This line of code is as follows:

Code:

---

BOOL m_bFlag;

---

This line of code is in the .h for the subclass, in the protected section of the declaration. This m_bFlag variable is no longer referenced or used anywhere in the program except for this line. Of course, not being able to replicate this in the development environment makes it even harder to diagnose.

Of course, I could just leave this line in place and ignore it... but that is NOT a solution as I can see it. What worries me even worse is this may be just a symptom of a larger problem... guessing, maybe possible memory issue or ????? I've never had an issue with REMOVING a variable declaration unless that variable is used, which it is not... that's what makes this so bizarre.

Any suggestions or ideas that may point me in the right direction for fixing this issue, would be greatly appreciated....

When you invoke the dialog do you pass in the pointer to the parent window?

MFC dialog may be centered a few different ways. First (and explicit) is providing DS_CENTER style to dialog styles. Second (and explicit) is forcing it with CenterWindow. The last (and implicit) one is providing {0,0} coordinate for left top vertex of the dialog rect while DS_CENTER is not specified.

Quote:

---

What worries me even worse is this may be just a symptom of a larger problem... guessing, maybe possible memory issue or ?????

---

Yes, this may be an indication of memory corruption when dialog gets created as long as the dialog appears misplaced. If the problem is reproducible for debug build as well, I would suggest to make sure this coordinate corruption really takes place by direct debugging of dialog creation.

Quote:

---

Originally Posted by pbrama

I ran into a very weird problem and after a lot of trial error, narrowed it down to a single line of code that should NOT be causing this problem...

---

And the answer to you is memory corruption, plain and simple. That memory could be corrupted by any number of ways, from a buffer overrun, to accessing invalid memory in some way and using it (maybe a variable is uninitialized and you're using this uninitialized variable to perform critical code in your app), etc.

Anytime you move, add, or remove lines of code that are totally benign, and the program now crashes, behaves differently, magically works, all without an explanation, it is due to memory corruption.

When you move/add/change lines, you're also changing the binary executable that is being produced. Any memory corruption such as buffer overrun may not show the effects due to the area of the overrun being moved to a "safe" area in the changed executable, where an overrun cannot be detected.

Quote:

---

Of course, I could just leave this line in place and ignore it...

---

No.

Remove that line, duplicate the problem, and fix the problem. The last thing you want to do is move the corruption bug to another area in the program, where you now do not know where it can be lurking.

Quote:

---

I've never had an issue with REMOVING a variable declaration unless that variable is used, which it is not... that's what makes this so bizarre.

---

There is really nothing bizarre about it. That's what happens when you corrupt memory.

Quote:

---

Any suggestions or ideas that may point me in the right direction for fixing this issue, would be greatly appreciated....

---

Again, you shouldn't change any code whatsoever. Keep the non-working code, and fix the problem. The dialog doesn't show, then great -- you see the problem, you have the source code, so now it's time to debug what is wrong.

Regards,

Paul McKenzie

Thanks for all the great input... I am definitely leaning towards a memory corruption issue... especially because the dialog creation is pretty standard... no additional code for that process. Plus, not being able to replicate in a development environment, just the exe... all kind of points that way.

Biggest problem is, this program, has hundreds of thousands of lines code and with the add-in libraries (which we hope are rather bug/memory corruption free)... well over a million lines... all written by multiple programmers over the years.

This is going to be a diagnose nightmare... especially with the only way of checking it to change it, compile it, run it, and see. Does anyone know of any tricks or hints or even other applications that might help narrow this down other than going line by line and double/triple/quadruple checking each and every memory call and use... by hand... and hoping you don't accidentally overlook something?

Quote:

---

Originally Posted by pbrama

Thanks for all the great input... I am definitely leaning towards a memory corruption issue... especially because the dialog creation is pretty standard... no additional code for that process. Plus, not being able to replicate in a development environment, just the exe... all kind of points that way.

---

You could (and should) write to a log file or to the debug monitor using OutputDebugString() the values of important variables and other information when your program runs. Or if there is a pause in the program in some way, you can have the debugger attach to the executable before the dialog is shown. Or stick a DebugBreak() call to start the debugger before the dialog is shown.

Also, there are third-party debugging tools such as BoundsChecker, Purify, and others. Do you use one? If not, why not, knowing that you have this massive C++ program that needs to be maintained?

Quote:

---

Biggest problem is, this program, has hundreds of thousands of lines code and with the add-in libraries (which we hope are rather bug/memory corruption free)...

---

And if these libraries are not corruption free, how will you know?

Quote:

---

This is going to be a diagnose nightmare... especially with the only way of checking it to change it, compile it, run it, and see.

---

I'll give you some encouragement -- I bet that many here, even the ones responding to you, could be able to identify the problem within a day or so if we had all the source, compiled it, ran it, and duplicated the problem. So it isn't really a "diagnose nightmare" -- actually the largest apps are never really a "diagnose nightmare" for an experienced professional who knows what they're doing and have the right tools for the job.

The problem starts with the dialog being placed in the wrong area. That certainly means that the dialog template has been corrupted, or the OnInitDialog is placing the dialog in a user-defined x,y position that was corrupted. So start from there.

Secondly, unless you're very experienced in C++ programming, you will miss subtle issues that only an experienced C++ programmer will identify as a problem. Things like calling memcpy() or 'C' routines on C++ non-POD structs or classes, constructs that cause undefined behaviour, etc. all require a very experienced C++ programmer to identify.

Quote:

---

Does anyone know of any tricks or hints or even other applications that might help narrow this down other than going line by line and double/triple/quadruple checking each and every memory call and use... by hand... and hoping you don't accidentally overlook something?

---

1) Use logging.

2) Use the debugger to break into the running executable that does demonstrate the issue.

3) Use tools that specialize in finding buffer overruns and other issues. I mentioned two previously

4) If you're not one yourself, get yourself an experienced C++ professional who knows the language to a degree where things such as illegal constructs, badly coded copy-assignment operators, etc. are identified, almost on the spot. Just as important is that the programmer explains why the construct is bad, so that it doesn't happen again. An intermediate or novice C++ programmer will not spot these issues, trust me on this.

5) Dodgy or "C-like" coding should be considered for a rewrite, using safer C++ constructs. Things like new[]/delete[] could be replaced with CArray or std::vector, home-made linked lists or maps replaced with CList/CMap/std::list/std::map, strings created with new char[] replaced with CString or std::string, etc.

6) Make sure you're building your entire application using a consistent set of headers and libraries. If you compile one part of your code with an edited header file, and the other part of the code uses the same header but was not compiled, then you have another reason for memory corruption -- the internal structures for a common struct/class are different, therefore you have memory corruption when any copying of an object is made.

Regards,

Paul McKenzie

Going to start tackling this problem this weekend. Is it a safe assumption that as I try to find this potential memory issue... that the code that is "passed through" from program start to where the moved dialog appears... the error is possibly in only that code? That is, we have a lot of routines and such that are not called until later in the application running based on user input. I am assuming, at least for now, I can ignore that code.

Good assumption, bad assumption.....

Thanks

If the problem is memory corruption, the problem could be anywhere.

I've spent ALOT of the past three days going through code trying to find the corruption. As much as I would love to use a program like Boundschecker or Purify... unfortunately it is not in the development budget... at least at this time. I did find a OpenSource program to look for memory leaks... Visual Leak Detector... that worked with vc6. It found a couple dialog NEW calls that didn't have matching DELETE calls. Fixed that but unfortunately, that didn't correct the problem. I am sure some of the bigger better and expensive apps would probably find more, but... have to with what we have at our disposal. If anyone has any other less expensive tool recommendations that might work....

Still working through all the code piece by piece and trying to set some debug code to see if we can find it. As mentioned, my "tell" is repeatable because the first dialog that appears, normally is centered on the display but with the "error", it is showing up in the corner of the display. Re-Checking all the code that calls that dialog, there isn't anything we have done to control the positioning of the dialog when it creates.

Wanting to take one of Paul's advice, I figure the best "variable(s)" to watch would be the ones that control the dialogs original position seeing how it gets bad info. Problem is, I don't know what variable to use in an OutputDebugString to watch the default position. Any suggestions....

Quote:

---

Originally Posted by pbrama

Wanting to take one of Paul's advice, I figure the best "variable(s)" to watch would be the ones that control the dialogs original position seeing how it gets bad info. Problem is, I don't know what variable to use in an OutputDebugString to watch the default position. Any suggestions....

---

The dialog template. This is basically a memory layout of the dialog's you find in the .rc file. If this template gets corrupted, then you can get a dialog positioned incorrectly.

There probably is a function that you can write that dumps the resource info for the dialog (as a debugging aid). However, you need to be careful that whatever function you write doesn't move the bug to another area of the program.

Boundschecker has a free 7-day trial. I would ask for it at the MicroFocus web site.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by pbrama

Going to start tackling this problem this weekend. Is it a safe assumption that as I try to find this potential memory issue... that the code that is "passed through" from program start to where the moved dialog appears... the error is possibly in only that code? That is, we have a lot of routines and such that are not called until later in the application running based on user input. I am assuming, at least for now, I can ignore that code.

Good assumption, bad assumption.....

Thanks

---

Although memory corruption bugs are the hardest to track down, the memory is being corrupted by the execution of some instructions. Those instructions are executed somewhere between the start of the program and the point where you see the "error". Therefore, I have to disagree with Arjay and say your assumption is good.

Also...
If you know some bit of memory (variable) gets overwritten by some bogus information somewhere...
you can set a breakpoint on that memory and get the debugger to break when the memory is changed.
With regular VS... this is possible, but your code will be incredibly slow (it could take minutes/hours) depending on how the problem manifests itself. But it's a good place to start if you know of such variables being corrupted.

It may not get you the actual error though, you could end up in some other class that overwrites the variable because the class too has corrupted data. Change your data breakpoint and restart and work your way back to the error.


With VS this is slow because checking the variable being changed is done in software. There are debuggers that do this with hardware assistance (they tend to be pricey though) and that can run code at near full speed while doing this.

Quote:

---

Originally Posted by Coder Dave

Although memory corruption bugs are the hardest to track down, the memory is being corrupted by the execution of some instructions. Those instructions are executed somewhere between the start of the program and the point where you see the "error". Therefore, I have to disagree with Arjay and say your assumption is good.

---

I guess I should have explicitly stated it as "...anyware within the path of execution"? Clearly the memory corruption is going to have taken place in code that has already be executed.

After working on it on and off for the last week, still haven't been able to find what is causing this issue. Decided it was probably time to look into Boundschecker 7 day trial as recommended.

As I was reading the DATASHEET before filling out the form on the website, I noticed that it works with VISUAL STUDIO 5, VISUAL STUDIO 8, VISUAL STUDIO 10... It doesn't list Visual Studio 6, which we use. I emailed MicroFocus but haven't heard anything back as of yet. Does anyone know if it works with Visual Studio 6 (Visual C++ 6)?

Hopefully, if it works, I can get it up and running and try it out before the trial expires.

Well after over a month of work off and on... we are still no further than we were back then. This problem still exists and we can't find it. Even had another experienced C++ programmer look at the code. Again, there is ALOT to go through and as we all know, it could be something very small and simple and easily overlooked... hence getting a tool or two to help out.

Trying to get a 7 day trial for Boundschecker has been a joke. The hoops you have to jump through just to talk to someone is ridiculous and they appear to be in no hurry to talk to you. All their documentation does NOT list Visual Studio 6 and we tried for weeks to get someone to confirm if it does or does not work with that. All to no avail.

Went to the IBM website for Purify. After reading everything I could find for a couple days including the compatible software, etc. I found a trial for them as well. I signed up and downloaded the software. Even got a call from a rep before I had a change to even open the files. This weekend was going to be the trial. Unzipped the files ran the installed, loaded the install utility. Then started going through the documentation. Low and behold, in a small paragraph way into the docs, Visual Studio v6 is no longer supported. ****, thought we had something.

Of course, I am realizing more and more that VC++ 6 is becoming an issue... but unfortunately, upgrading that could bring development to a complete stand still right now (even more that it currently is). This is a large mult-file app. I can see an upgrade causing even MORE problems and first NOT related to this memory issue and after fixing any/all those issues, may lose the ability to "repeat" this bug... like we currently have been able to do.

So, I have to ask again, any more suggestions/recommendations? Just a fast recap, the repeatable bug is that at the very beginning of the programming running (as an EXE), the first dialog that we open is being placed in the lower right corner, not centered like it should be. If I comment out one line of non-related code (a new variable declaration), the dialog appears dead center as it should. We are NOT physically controlling or modifying the location... it is using the defaults. I am thinking that if I put some logging in to watch some pointer or internal variable, I might be able to narrow down the code that is trashing that location pointer. Problem is, I have no idea, at this point, what to watch.

Again, I really appreciate all the help I have received and the input from this forum... it is an excellent source for help and even a small recommendation might point us back into the right direction.

Thanks again...

You've stepped through all the dialog creation code, constructors, Create call, OnInitDialog, etc. to see why it's getting placed where it's getting placed I assume?

Thanks for getting back to me so fast...

Yes, we can step through all the code without a problem. When we run it in the IDE, it works fine. When we compile it and run the EXE, it moves the dialog to the corner.

What I think I need to do.... I need to create a log file that will run in the EXE and "write" out at certain places the value of ???? to watch for when it changes. I am thinking with that, I can narrow down the section of code that may have the issue(s) for now. Problem is, because we don't specifically address the dialogs creation location... I am not 100% sure where it gets the default positioning info from that it uses.

Right track, wrong track????? At this point and way too much time going after this problem... I am at a loss. I need to make some other fixes to the program but don't want to lose my "repeatable" error.

Thanks again...

Quote:

---

So, I have to ask again, any more suggestions/recommendations?

---

Unless you give us the code to debug, everything that has been stated to you is what anyone here would have done already.

It's simple -- a dialog is placed at an X,Y position on the screen. There is only one way to do that, regardless of the layers of MFC or code. The dialog template that is being read by the Windows OS to position the dialog is either incorrect or corrupted. There is no other way for a dialog to show up on the screen in a certain position (if you claim you had no control over the dialog).

Quote:

---

Even had another experienced C++ programmer look at the code

---

And these experienced C++ programmers cannot solve a problem that is easily duplicated at startup?

Regards,

Paul McKenzie

Quote:

---

Originally Posted by pbrama

Problem is, because we don't specifically address the dialogs creation location... I am not 100% sure where it gets the default positioning info from that it uses.

---

How is this dialog created? If it is created via resource ID, then look at the .rc file. That is where the position of the dialog is established.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by pbrama

Thanks for getting back to me so fast...

Yes, we can step through all the code without a problem. When we run it in the IDE, it works fine. When we compile it and run the EXE, it moves the dialog to the corner.

What I think I need to do.... I need to create a log file that will run in the EXE and "write" out at certain places the value of ???? to watch for when it changes. I am thinking with that, I can narrow down the section of code that may have the issue(s) for now. Problem is, because we don't specifically address the dialogs creation location... I am not 100% sure where it gets the default positioning info from that it uses.

Right track, wrong track????? At this point and way too much time going after this problem... I am at a loss. I need to make some other fixes to the program but don't want to lose my "repeatable" error.

Thanks again...

---

You could try building a release version with debug info in it and debugging and see if you can reproduce the problem. You could always add CenterWindow in OnInitDialog, but you could potentially hide another problem by doing that.

Have you tried rearranging the variables (shuffle the variables around m_bFlag)? With a bit of luck it might produce something that's easier to detect like a access violation. It's been a long time since I used VC6 but I guess that it's capable to attach to the exe when (if) it has crashed?

If your budget doesn't allow for Boundschecker or somthing similar it might allow for pc-lint (http://www.gimpel.com/html/index.htm). I've used it in many projects and it's quite good in finding suspicious areas of the code.

Quote:

---

Originally Posted by pbrama

...When we run it in the IDE, it works fine. When we compile it and run the EXE, it moves the dialog to the corner.

---

When you run it "in the IDE", you are still running the compiled and linked executable.
Are you saying that the same exe file that runs OK from IDE behaves differently when simply double-clicked from Explorer?
Or are you talking about the differences between Debug and Release configurations?