access violation debugging

Started by
7 comments, last by Fruny 19 years, 4 months ago
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]
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).
mmmmmmk...I stuck memset(m_CmdLine->Cmd,0,255); after the line with the "new" statement and I no longer get the access violation.
----------------------------------------------------"Plant a tree. Remove a Bush" -A bumper sticker I saw.
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?
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?
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
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?!
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.
that fixed it - thanks ALOT to both of you

hard to believe it was something that stupid
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.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan

This topic is closed to new replies.

Advertisement