Jump to content
  • Advertisement
Sign in to follow this  
merdre

access violation debugging

This topic is 5048 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

i'd look for the info myself but i have no idea where to start at i'm trying to do a linked list it's still not really a linked list since i only have 1 node (or whatever you call linked list items) thats my struct
struct m_stcCommand
{
	char Cmd[255];
	DWORD Len;

	m_stcCommand* Next;
};
m_stcCommand* m_CmdLine;
then i init
m_CmdLine = new m_stcCommand;
m_CmdLine->Cmd[0] = NULL;
m_CmdLine->Len = 0L;
m_CmdLine->Next = NULL;
but then when i try to print it
sprintf(buffer, ">%s", m_CmdLine->Cmd );
i get an access violation if i try to "%d" instead i get random numbers changing every frame.. and if i try the same sprintf line just after init it works fine i tried malloc instead of new but it didnt helped. what am i doing wrong? it looks like im not the only one using that memory block... but maybe im just not declaring something right also i'd like to know if theres a way to set a breakpoint on a memory address with vc6 .. and maybe some hints on how to debug such things by myself. thanks [Edited by - merdre on November 28, 2004 1:22:17 PM]

Share this post


Link to post
Share on other sites
Advertisement
If that sprintf works just fine after the init code but screws up in other places you may have a buffer overrun/underrun somewhere or prehaps you've deallocated the memory somewhere before the printf statement executes.

Oh and as you're using C++ you'd be better off using std::list instead of linked lists and std::string for strings. Indeed you should really be using the entire C++ standard library as opposed to the C one (i.e. using stringstreams instead of sprintf).

Share this post


Link to post
Share on other sites
mmmmmmk...I stuck memset(m_CmdLine->Cmd,0,255); after the line with the "new" statement and I no longer get the access violation.

Share this post


Link to post
Share on other sites
thx for the quick replys

actually i know i could rewrite the whole thing another way...

but i find it really frustrating when i have no idea how to deal with something. i hoped i could get some general debugging advices..

how can i find whats going wrong between the init and the printf?
i searched in my code for any reference to m_CmdLine and there is NONE except for what i posted above.
so then i copied that code in a new project ... it didnt crash

i used to program in VB where debugging was REALLY easy. and here my app just crashs on me .. for reasons beyond my understanding

i believe that if i ever get more than a noob in C++ it will be when i'll be able to debug properly

so.. how would you deal with that kind of things?

Share this post


Link to post
Share on other sites
Quote:
Original post by merdre
how can i find whats going wrong between the init and the printf?
i searched in my code for any reference to m_CmdLine and there is NONE except for what i posted above.


Are you referring to an object which might be located in memory near m_CmdLine, contains an array, the bounds of which you might have overstepped?

Share this post


Link to post
Share on other sites
you were right Fruny thx alot - did you guessed that?!

took me a while to figure out how to find out - i stepped line by line watching my m_CmdLine->Cmd pointer (just found out about the watch window)

its when i assign a value to DWORD m_fKeyLastInput[256]; m_fKeyLastInput[256] = timeGetTime(),
its writting over my m_CmdLine->Cmd pointer... now why would i receive memory already assigned when i create my m_CmdLine?!

Share this post


Link to post
Share on other sites
The last element of an array with size 256 is numbered 255 not 256. So when you wrote to the 256th element of the array you overwrote memory which wasn't part of the array and happened to part of the m_stcCommand structure you allocated causing your crash.

Share this post


Link to post
Share on other sites
It's such a common error that I don't have much merit 'guessing' it. For what it's worth, errors where, on delete, VC reports an assertion failure in dbgheap.c involve exactly the same problem.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!