Passing Pointers or References?

I've been working on a basic framework that contains a series of objects that are instantiated and stored globally within one super class (hope my terminology is correct). Simply put, I have a series of classes, let's go with just three for now: Game, Filesystem, Renderer.

Game contains pointers to both Filesystem and Renderer.

After Filesystem is initialized with the new operator, it's passed to Renderer.

On a WindowsXP system, this appears to work normally in both Debug and Release modes. However, once I move over to a Vista machine, the neither version works and I see bad pointer errors within the debugger.

I doubt this is a Windows problem because if it's a pointer problem (more than likely) it will eventually effect any system that it's part of.

So I guess my question is if I should continue to pass pointers to the various objects (e.g., Renderer(Filesystem *filesystem)) or should I instead be passing references to the pointers? Am I going about this entirely the wrong way?

It depends on the nature of the problem you're having when you switch over to Vista. Try to reduce the pointer problem down to one that you can reproduce and post here.
In general, references are nice and clean so long as you don't plan on changing what it is they refer to. I tend to use references for as long as I can, and then switch over to a pointer if necessary, or some smart reference class thing.

*edit* And by references I mean references to the objects to which the pointers point. Not references to pointers.

Don't expect that changing the pointers to references will help much with your problem because the compiler will effectively turn references into pointers(if I'm remembering correctly).

i'll bet you $1 your pointers aren't being properly initialized.

Quote:

---

Originally Posted by m37h0d

i'll bet you $1 your pointers aren't being properly initialized.

---

I'm not sure about that because I've gone through every variable and pointer I have access to in the debugger with a fine-tooth comb and everything appears to be correct (see below).

I've been looking at hex dumps all day and yet I don't understand why things appear perfectly normal in the debugger.

This is the definition for the Filesystem class class file. I think I'm going to change over to references anyway because the Filesystem Class is mostly an information container and should never be changed:

Code:

---

class Filesystem
{
public:
        /**
        * Initializes the Filesystem class, setups up PhysicsFS and sets any necessary
        * platform directory strings.
        */
        Filesystem(const char *argv_0);
        ~Filesystem();

        /**
        * Gets a path string to the Data directory.
        */
        const char *getDataPath();

        const char *getFile(const char *fileName);
        long int getFileLength(const char *fileName);

        bool addToSearchPath(const char *pathName);
        char **getSearchPath();

        const char *getCompiledVersion();
        const char *getLinkedVersion();

        const char *getLastError();

private:
        std::string mDataPath;                        /**< Data path string. Specific to each platform. */
        std::string mErrorMessage;                /**< Error Message should an error occur */
        std::string mDirSeparator;                /**< */
};

---

const char *getFile(const char *fileName); fails when I make a call to PHYSFS_ so I wonder, is it possible that the library code is failing and not my code? I would find that hard to believe considering that PHYSFS is used in dozens of other projects without apparent problems --

I built PhysFS from source code as it's not distributed as a binary package. I later installed a patch to Microsoft's linker -- is it possible that this introduced a memory problem? That same patch is not installed on the Windows XP machine?

I'm not one to jump to conclusions and I hate to blame code from somewhere else so I was wondering if there's anything immediatly obvious out of the above code that I should be concerned with. I've run the debugger for the last three days inspecting every value I could possibly get a reference out of throught the entire code base and everything appears to be properly initialized and assigned expected values (no 0xbaadf00d or other obviously erronous hex dumps).

Thanks for the time reading through this -- this is a frustrating problem and it's always good to have a second, third, fourth etc. opinion.

Quote:

---

Originally Posted by leeor_net

I've gone through every variable and pointer I have access to in the debugger with a fine-tooth comb and everything appears to be correct (see below).

---

In debug mode everything is intialized to zero if leaved uninitialized in code

so your
if(!prt) ptr = ...

code will work fine in debug mode and fail misarably in release

Quote:

---

Originally Posted by leeor_net

const char *getFile(const char *fileName); fails when I make a call to PHYSFS_ so I wonder, is it possible that the library code is failing and not my code? I would find that hard to believe considering that PHYSFS is used in dozens of other projects without apparent problems --

---

It's always possible that PHYSFS_ is failing, but I'd bet in favour of the problem being in your own code.

You haven't really given enough information to allow anyone to provide help though: the class definition is not enough.

There are two basic rules of code failure due to pointer molestation;

1) The cause of a failure is code executed at or before the failure.

2) Programmers tend to focus on the line where the failure is detected and don't tend to consider the "or before" clause in rule 1.

What I'm basically saying is that the cause of your failure is probably in code executed at some time before you see any symptoms. And the code causing the problem might have been executed a considerable time before the failure occurs. And, in practice, a common mistake by developers is only looking in code within a few lines of where the symptoms occur.

Quote:

---

Originally Posted by leeor_net

I built PhysFS from source code as it's not distributed as a binary package. I later installed a patch to Microsoft's linker -- is it possible that this introduced a memory problem? That same patch is not installed on the Windows XP machine?

---

Without knowing the nature of the patch, it's not possible to be sure whether it is related to your problem or not. I'd bet against it (unless, of course, you have installed a patch unsupported by the vendor).

I wouldn't necessarily bet that changing pointers to references will fix your problems. The compiler will be more likely to pick up some problems (eg it is not possible to create an uninitialised reference) but some problems in yoru code will persist (eg a dangling reference - a reference to an object that no longer exists - results in the same type of symptoms as a dangling pointer).

Thanks again for the helpful replies. As I've stated, I hesitate to blame someone elses code and can only assume that the error lies in my own code -- this is especially true considering that the same code compiled on two different machines behaves, outwardly, the same (e.g., both versions appear to run correctly on WinXP but neither work on Vista). I can only assume this means that Vista is not as forgiving with memory allocation (which is a good thing if you ask me -- it forces me to find nasty bugs that might otherwise frustrate end-users).

The failure appears to happen just after I call Filesystem::getFile(const char*). The odd thing is, in the debugger, the const char* is as expected -- a proper string value. When not running in the debugger, the const char* is either 0 or obvious garbage data.

I can assume that this is from a dangling pointer or uninitialized pointer from earlier in the code and not at the actual 'failure site'. I've attempted a back trace (e.g., just stepping back through the call stack and inspecting values) but as I said, everything appears to be correct.

I'm not sure which parts of the code are truely relevant but, more importantly, I don't know how much posted code would be deemed inappropriate or unhelpful for anybody. I see little point in flooding this thread with 5 or 6 files of C++ code as it would just clutter things up and would probably not be particularly easy to read through.

As this is an open-source project that I'm working on, the code is not private and is available for anybody to look at should they find it interesting.

What are some of the things that I can try to look for that might cause a corrupoted const char*? Maybe a few clues as to what exactly I might be looking for could help me find the mistake that I've made.

Thank you again for all of your help. Everybody has been quite helpful.

I suspect you may have a case of "using local data after the function return", which is undefined behaviour, and as such can cause "anything" to happen.

--
Mats

So instead of guessing, can you track where it crashes in the debugger and why?
Not all debuggers initializes variables to 0. Microsoft's debugger throws an exception if an uninitialized variable is used.

Quote:

---

Originally Posted by Elysia

So instead of guessing, can you track where it crashes in the debugger and why?
Not all debuggers initializes variables to 0. Microsoft's debugger throws an exception if an uninitialized variable is used.

---

No, I can't. It doesn't crash in the debugger in either debug or release and everything appears to be normal which is what is making this so frustrating and why I've posted on cprogramming.com... :) It only crashes when I run the program outside the debugger which isn't exactly helpful.

Sp I've resorted to using messages to let me know exactly when the program stops working. Turns out that it crashes as soon as I try to access member classes of a super class -- class Game.

The member classes are defined within Game as such:

Code:

---

Filesystem *mFilesystem;        /**< File system functions and services. */
Configuration *mConfiguration;        /**< Configuration parser. */
StateManager *mStateManager;        /**< State manager */
Renderer *mRenderer;                /**< Renderer. Initialized on startup. */
Mixer *mMixer;                        /**< Mixer. Initialized on startup. */
Gui *mGui;                        /**< GUI System and Manager. */
Lua *mLua;                        /**< Lua Script Interpreter. */

---

These are all initialized in Game's Constructor:

Code:

---

Game::Game(const char *configFile, const char *argv_0)
{
        Logger::logFile << "Initializing subsystems..." << endl;

        mFilesystem        = new Filesystem(argv_0);
        mConfiguration        = new Configuration(configFile, mFilesystem);
        mRenderer        = new SDL_Renderer(mConfiguration);
        mMixer                = new SDL_Mixer(mConfiguration);
        mStateManager        = new StateManager(mFilesystem, mRenderer, mMixer);
        mLua                = new Lua(mFilesystem);
        mGui                = new Gui(mRenderer, mFilesystem);
       
        Logger::logFile << "Subsystems initialized..." << endl;
        Logger::logFile << "===================================\n" << endl;
}

---

This appears to succeed as the Logger functions work as expected and show up in the log file.

Game has a function defined, ::go() which is basically a giant loop. Once I get into that function I have a line like this:

Code:

---

Logger::logFile << mConfiguration->getGraphicsHeight();

---

All of the above classes have similar access functions return various values...

-----

As I've been writing this out I discovered that mGui has bad values in it. I thought "Maybe if I comment it..." and lo and behold it works.

Thanks again everybody for your help. Without this forum and your replies I'd probably still be banging my head on the desk.... so thank you!

Quote:

---

Originally Posted by matsp

I suspect you may have a case of "using local data after the function return", which is undefined behaviour, and as such can cause "anything" to happen.

---

That's one distinct possibility. That could be confirmed or denied by examination of the implementation of the FileSystem::getFile(const char *) function.

Another distinct possibility is that a code executed before that function call is trashing the memory that this function happens to return (a pointer to).

There are many other possibilities. We're dealing with undefined behaviour here: and there are both many causes and many possible symptoms.

Defintely making progress now.

I looked at the implentation and lo and behold, I do indeed return a char* that is created locally. That should have occured to me when I couldn't find a good place for a 'delete'.

Still having crashing but I'm sure it's other similar stuff. Unintialized variables, missed pointers, local variables that lose scope, etc.

Quote:

---

Originally Posted by leeor_net

I looked at the implentation and lo and behold, I do indeed return a char* that is created locally. That should have occured to me when I couldn't find a good place for a 'delete'.

---

One way to reduce chances of concerns like that is to return a std::string instead. std::string has copy-by-value semantics (i.e. a copy of the local string is returned, rather than a pointer to something that does not exist).

You should not use raw pointers. Use std::string instead of char*, and std::tr1::shared_ptr, or other smart pointers for other types instead of raw pointers.
And for future reference, using Microsoft's IDE, you can use JIT debugging - that is, run it normally, let it crash and then choose to debug. Very handy for these kinds of things.

Quote:

---

Originally Posted by Elysia

You should not use raw pointers. Use std::string instead of char*, and std::tr1::shared_ptr, or other smart pointers for other types instead of raw pointers.
And for future reference, using Microsoft's IDE, you can use JIT debugging - that is, run it normally, let it crash and then choose to debug. Very handy for these kinds of things.

---

I've discovered how convenient std::string is -- no more stupid crap. Requires a few work arounds here and there but for the most part it's all good.

I decided that I'd create the char* as a class member variable. It's handy when it comes to needing to get a reference to the data I'm loading up and it's proved pretty useful so far.

I've use the JIT debugger and, while it's been somewhat helpful, I'm still unable to really figure out how to get certain variables.

Either way, I've localized the problem to a good bit of code that I wrote for the internal 'gui' system. Seems that somewhere in that code memory is being overwritten because as soon as I comment it out all other problems seem to be resolved. I don't know if this is a case of 'false logic' that will come back to bite me in the ass later but I still want to take a different approach to the GUI system anyway. Sometimes it's good to just throw away small sections of code and rewrite them... so my experience has shown at least.

Thanks again for all of the tips and the overwhelming amount of support I've received!

Quote:

---

It's handy when it comes to needing to get a reference to the data I'm loading up and it's proved pretty useful so far.

---

What exactly is this "reference" to the data you are talking about?
Usually, you would use a smart pointer for this task, perhaps even std::string.

As for the JIT debugger... what debugger are you using? People can offer assistance, but they must know which one you use.

I use the built-in VS2009 Debugger. I've had a lot of sucsess with it but there are the nuances that can get confusing sometimes. I'm hesitant to ask about specifics because 1) I don't want to waste someone's time when my question could very well be answered on MSDN and 2) I try to stay away from platform/implementation specific questions in a general C++ forum.

As for not using a std::string for storing file data, the problem is that PhysicsFS (http://icculus.org/physfs/), the Filesystem library that I'm using, requires an address to a char* to which it writes file data to as a series of bytes. Many projects have used it sucsesfully and so I imagine that I will be able to also -- so far it hasn't given me any problems and it provides exactly the sort of disk/file access I want (including transparent reading/writing to archives such as ZIP/PAK/WAD/7ZIP/etc, big huge plus).

The 'data' I'm reffering to is basically a byte array stored in a char*. This is then passed to other components that then read whatever file I loaded using the Filesystem (e.g., an OGG would be loaded by the Mixer, a PNG would be loaded by the Renderer, a plain text XML file would be loaded by the Configuration Parser, etc.). I could simply pass this information out as a std::string but it makes it easier to just throw it out as a const char* as that's the 'format' that it's already in.

I guess you could say my terminology isn't perfect. 'Reference' may have been a poor choice of words.

I want to make clear that my issue is generally resolved. I do appreciate the continued support, suggestions, advice and efforts to offer additional assistance as I've learned a great deal over the last few days. It's great to know that there's a community I can turn to when I have questions and not be told to RTFM or STFI. Thanks again everybody!

Quote:

---

As for not using a std::string for storing file data, the problem is that PhysicsFS (http://icculus.org/physfs/), the Filesystem library that I'm using, requires an address to a char* to which it writes file data to as a series of bytes.

---

You can use vector of chars in this case

Quote:

---

Originally Posted by leeor_net

I use the built-in VS2009 Debugger. I've had a lot of sucsess with it but there are the nuances that can get confusing sometimes. I'm hesitant to ask about specifics because 1) I don't want to waste someone's time when my question could very well be answered on MSDN and 2) I try to stay away from platform/implementation specific questions in a general C++ forum.

---

Do that as you want, but there are a few here who has experience with the VS debugger (me included) and can give you hints, tips and guidance should you require it. Becoming a master programmer also means mastering a debugger, or so I would like to say.

I can definitely agree with that. Debuggers are a beast all of their own and it takes a great deal of finess and some inginuity to be able to use them effectively. I like to think that I'm at least knowledgeable in using my debugger but I wouldn't call myself a master users. Far from it, actually.

Quote:

---

Originally Posted by leeor_net

No, I can't. It doesn't crash in the debugger in either debug or release and everything appears to be normal which is what is making this so frustrating and why I've posted on cprogramming.com... :) It only crashes when I run the program outside the debugger which isn't exactly helpful.

---

So run it outside, wait till it crashes. Then - without closing the error message - use aatach to process fature of the debugger and exemine the stack.

Note that sometime stack could not be displayed even when the exe is compiled in the debug mode which in most cases indicates the memory overrun of some var declared on stack and calling return when the actual return address is overwritten with garbage

There is a way to get stack tracing in release mode when an exception is thrown, however, it requires a bit of work and some assembly code. There are examples of this in books specifically about Microsoft's debugger in Visual Studio. The MSVS debugger is powerful but is usually shipped as a lame duck most of the time. Most of the tricks you can do with it require external code or assembly and/or fairly decent knowledge of its internal workings.

The VS debugger can attach to the process, however, you will only get an assembly output when you do a break all. It is not good at parsing the assembly and giving you good information about what is going on. However there are 3rd party debuggers that are good for this. One that comes to mind is OllyDebug. You can attach to your process, analyze the source, find all intermodular calls, all referenced text strings, and it even recognizes which calls are Win32 calls. It can break down the calls by parameter and show you what each parameter is. Very handy. Perhaps this will show you what is going on.

I read in a Symantec security analysis of Vista that Vista has a technique to randomly allocate memory for programs. This way hacker or malware can not guess the place of data.
For example when you do

Code:

---

int *password = new int;
*password = 23124;
...
delete password;

---

The value of password is stiil there. It is called ghost, if remember correctly. You can read that if you know its address and have the permission to access that address (for example when the original program is terminated or has released the memory. A few time it made a hardtime debugging my code, because it worked correctly in debug mode but not in release mode. It was actually reading ghost value in debug mode. Vista may prevent this to happen.

Quote:

---

Originally Posted by siavoshkc

The value of password is stiil there. It is called ghost, if remember correctly. You can read that if you know its address and have the permission to access that address (for example when the original program is terminated or has released the memory. A few time it made a hardtime debugging my code, because it worked correctly in debug mode but not in release mode. It was actually reading ghost value in debug mode. Vista may prevent this to happen.

---

It's not really much to do with vista: it's more related to memory management in your runtime library that comes with your compiler.

For performance reasons, when your program deallocates memory (or any other resource) the runtime library may choose not to request the operating system to physically deallocate it. That is the reason for "ghosting". However, a subsequent memory allocation might use that memory. The "might" is the reason that dereferening a deallocated pointer yields undefined behaviour (anything can happen, but might not).

The operating system may play similar games (eg when the runtime library asks the OS to deallocate memory, the OS may choose not to get the hardware to deallocate and the next call to the OS for memory may retrieve the same address). That's the same thing as the runtime library does, albeit a second order effect. But, as a rough rule, operating systems do not protect a program from accesses of memory in that program's address space.

Some OS's (eg OpenBSD) do randomise such things, but the attention is more often on overwriting the affected memory than with moving it around.