Jump to content

  • Log In with Google      Sign In   
  • Create Account

C++ Runtime Error With Odd Workaround


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 bryanismagic   Members   -  Reputation: 107

Like
0Likes
Like

Posted 13 August 2014 - 09:54 PM

I'm experiencing a runtime error in Visual C++ 2010. I can work around it, but I don't understand the error and I don't understand why the workaround works. I'm going to try and strip this down to as basic of an example as possible.

class Object
{

   int data[10];

};

 

class A : public Object

{

   void Init();

};

 

A::Init()

{

   data[0] = 24;

}

 

class B : public Object

{

   void Init();

};

 

B::Init()

{

   data[0] = 48;

}

Object * gpObj;

A a;

B b;

 

void main()

{

   a.Init(); // <--this line creates an access error, unless...

   b.Init();

   gpObj = &a; // <--if I put this line first, a.Init() and b.Init() work as intended

}

 

It's very confusing for me why I need to reorder the code in this way to get it to work. I could understand if gpObj were being used to access the variable, obviously, but it's not. The only thing I'm changing is the order of the instructions. Any insight the community may have is welcome.



Sponsor:

#2 fastcall22   Crossbones+   -  Reputation: 4457

Like
4Likes
Like

Posted 13 August 2014 - 10:04 PM

Unable to reproduce.

 

What is the exact code that produces the error?


Edited by fastcall22, 13 August 2014 - 10:06 PM.

c3RhdGljIGNoYXIgeW91cl9tb21bMVVMTCA8PCA2NF07CnNwcmludGYoeW91cl9tb20sICJpcyBmYXQiKTs=

#3 tonemgub   Members   -  Reputation: 1146

Like
1Likes
Like

Posted 14 August 2014 - 12:50 AM

Your basic example is incomplete. Most likely you are using the global gpObj variable in one of the Init functions, and the Init functions are called before you assign a valid pointer to gpObj...



#4 SeanMiddleditch   Members   -  Reputation: 7156

Like
1Likes
Like

Posted 14 August 2014 - 11:55 AM

I'm confused how this is even compiling, due to this:

class Object
{
   int data[10];
};


Class members are _private_ by default. That means that derived classes will not be able to access these members. You will need to declare the `data` member in a protected or public access level for `A` to have access to it.

--

The runtime error makes no sense. This probably isn't the actual code you're testing. Are these class definitions in separate files, by chance, and is your actual test function not `main`? Global variable initialization orders could explain this, though they would all be initialized before `main` is executed.

#5 bryanismagic   Members   -  Reputation: 107

Like
0Likes
Like

Posted 14 August 2014 - 10:51 PM

Unable to reproduce.

 

What is the exact code that produces the error?

 

I've tried my best to maintain the essence of what the code is doing in my example. I know you're thinking, the answer must be in something he's doing in the REAL code that's not represented in this example. But it's really not. I'm not uploading the exact code because it's just too big. I realize that's not helpful. Try to focus on the fact that moving the green line ahead of the red line fixes the problem. Because that part of the example is exactly the same as the source, minus some name changing.
 

 

Your basic example is incomplete. Most likely you are using the global gpObj variable in one of the Init functions, and the Init functions are called before you assign a valid pointer to gpObj...

Nothing even sort of close to that is happening. But specifically, I can assure you, the global pointer is not referenced in any way in a.Init() or by anything it calls (it actually doesn't call anything). It really is as benign as assigning a literal value to member data.
 

 

I'm confused how this is even compiling, due to this:
 

class Object
{
   int data[10];
};

Class members are _private_ by default. That means that derived classes will not be able to access these members. You will need to declare the `data` member in a protected or public access level for `A` to have access to it.

--

The runtime error makes no sense. This probably isn't the actual code you're testing. Are these class definitions in separate files, by chance, and is your actual test function not `main`? Global variable initialization orders could explain this, though they would all be initialized before `main` is executed.

 

 

To answer the first part, I'm using structs, not classes, so that's a flaw in the example. It does indeed compile, and in the given scenario, works as expected.

The structs Object, A, and B, are each defined in seperate files. The instances in question, gpObj, a, and b, are declared globally as extern, and then created globally in the cpp file that references them. The function that references them is not main, but as you say, they are all initialized by the time this code is executed.

And regardless to all other concerns, putting the green line in front of the red line fixes the problem, where there is positively no reference to the global pointer as a result of the call to a.init().

Thanks to all for considering this issue and for your feedback. Just to reiterate, no code will be posted. Feel free to conclude that you have insufficient information to understand the problem.

I don't think the answer is even in the code, at least not in any straightforward way. I think my problem is in my lack of understanding of how, where, and why memory is allocated to a large number of bulky, complex global variables. I think somewhere somehow something is getting created over top of something else, in a way that's beyond my ability to anticipate. But that's just my guess.



#6 Endurion   Crossbones+   -  Reputation: 3683

Like
3Likes
Like

Posted 14 August 2014 - 11:13 PM

The problem and "solution" you describe is pretty much a symptom of either accessing uninitialized memory or writing out of bounds.

 

Not much more can be said without seeing the real code. The problem is simply not in that sample code you posted.


Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

#7 bryanismagic   Members   -  Reputation: 107

Like
1Likes
Like

Posted 15 August 2014 - 02:24 AM

Endurion, as an aside, it's funny that you quoted the word "solution", as you were the only one to use it. It's not important, just an interesting non sequitor.

Anyway, dear everyone, I take back everything I said. There was a reference to gpObj in a.init() (about 6 calls deep) that I didn't catch before. I sort of blame VC++ for reporting the wrong line # at which the access error occurs. But the bottom line is that I'm a stupid idiot and wasted everyone's time. The problem was in the code and it wasn't even that complicated. Oh well. At least my universe makes a little more sense now. And I'm slightly less paranoid about ninja heap errors. Just a little.

For what it's worth, your collective feedback did help me come to the realization.


Edited by bryanismagic, 15 August 2014 - 02:26 AM.


#8 Endurion   Crossbones+   -  Reputation: 3683

Like
0Likes
Like

Posted 15 August 2014 - 02:49 AM

I quoted the word "solution" since if the problem was writing out of bounds, it would not actually solve the problem. It would merely hide the symptom until it reappears somewhere else.

 

Anyhow, you found the actual problem and fixed it. That's what we're here for.


Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

#9 tonemgub   Members   -  Reputation: 1146

Like
0Likes
Like

Posted 16 August 2014 - 01:54 AM


Most likely you are using the global gpObj variable in one of the Init functions, and the Init functions are called before you assign a valid pointer to gpObj...

 

 


There was a reference to gpObj in a.init() (about 6 calls deep) that I didn't catch before.

Never doubt the <awesome> power of guesswork! smile.png


Edited by tonemgub, 16 August 2014 - 01:55 AM.


#10 rip-off   Moderators   -  Reputation: 8726

Like
2Likes
Like

Posted 16 August 2014 - 11:28 AM

I'd recommend in future making it very clear if your example program actually demonstrates the behaviour or if it is just intended to be a simplification. I'd also recommend actually trying to make your example program exhibit the behaviour: the process of reducing the problem to the minimum conditions that reproduce it can be a very effective way of solving the problem.

 


I sort of blame VC++ for reporting the wrong line # at which the access error occurs

This is surprising. It is unclear to me how experienced you are, but regardless, are you sure you weren't a simple mistake like trying to debug a release build? I've heard of the debug database getting corrupt or out of date in older versions, maybe a clean build would have helped.

 

It might be worthwhile re-introducing such a bug and trying to get VC++ to give you the correct information, as you'll almost certainly need to investigate similar issues in future.



#11 brightening-eyes   Members   -  Reputation: 174

Like
2Likes
Like

Posted 17 August 2014 - 02:37 AM

hi,

i must say first of all build a debug version of your application, then debug it

if an error occurs, you can fined it easyly


when you can't see well like me, you can't test your applications and you can't read something

AmirOS: an Open Source Operating system

Audio Game Kit: an open source game engine to develop audio games


#12 Stragen   Members   -  Reputation: 301

Like
0Likes
Like

Posted 20 August 2014 - 12:23 AM

Something to be wary of, and i've seen it happen to my code, if the compiler is doing any form of optimization, functions, classes, and variables may not be executed in the order that you expect... quite aside from a declaration being made in another piece of code.

 

When the error occurs (say an out of bound or buffer overrun) it may not breakpoint properly and can give wrong line numbers in extreme cases.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS