|
Also either call
memset(m_FileName,0,(strlen(FileName)+1));
after the new,
or call
m_FileName[strlen(FileName)] = '/0';
after strcpy.
These sort of issues are commonly caused by the program not seeing the end of the string and it overruns it's buffer.
Another possible issue is if you are assigning a pointer to that string elsewhere that is still using it. Check the debugger to ensure anything that needs to reference the string stored in m_FileName after it's deleted has made it's own copy.
eg. code like this is BAD
class MyClass
{
private:
char* mystring;
public:
void SetMyString(const char* const newstring) { mystring = newstring; }
};
void somefunction()
{
MyClass mc;
const char* conststring = "test me"
char* addstring = new char*[strlen(conststring)+1];
memset(addstring, 0, strlen(conststring)+1); // strlen(conststring)+1 could be assigned to an integer
strcpy(addstring, conststring);
mc.SetMyString(addstring);
delete[] addstring; // BAD - because mc now contains an invalid pointer!!!!!
}
-- modified at 3:12 Thursday 22nd December, 2005
|
|
|
|
|
lastgen wrote: Also either call
memset(m_FileName,0,(strlen(FileName)+1));
after the new,
or call
m_FileName[strlen(FileName)] = '/0';
after strcpy.
Nope. strcpy will copy the terminating zero so you don't need to do it yourself.
|
|
|
|
|
OK, I didn't think it did. I've been programming for about 20 years but not a lot of C until recently
|
|
|
|
|
Cedric Moonen wrote: Nope. strcpy will copy the terminating zero so you don't need to do it yourself.
Cedric, actual problem is that.. vikas is allocating memroy many time and deleting memory only one time... let me explain that by small example...
class MemLeak
{
char *pFile;
public:
void allocatemem()
{
pFile=new char[100];
}
~MemLeak()
{
if(pFile)
delete []pFile;
}
};
In this case it will work fine
MemLeak a;
a.allocatemem() ;
and on destruction 100 byte will deleted so no Memory leak, but let me consider a another case
MemLeak a;
a.allocatemem() ;
a.allocatemem() ;
so on destruction only 100 byte is freed so there is memory leak. i believe vikas can code something like this
class MemLeak
{
char *pFile;
public:
MemLeak()
{
pFile=NULL;
}
void allocatemem()
{
if(pFile)
delete [] pFile;
pFile=new char[100];
}
~MemLeak()
{
if(pFile)
delete []pFile;
}
};
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
We don't know if he allocates the memory several times or not. But something that is sure is that this is not the source of the crash: allocating several times memory without freeing it lead to memory leaks but it won't crashes for sure. So the problem must be somewhere else...
But still, your suggestion is good: memory leaks are a bad programming practice 
|
|
|
|
|
Cedric Moonen wrote: But still, your suggestion is good: memory leaks are a bad programming practice
You are Right (as Always).. But i believe original author never mention there is crash , here is original comment from vikas :-
I get a error at the delete keyword ,
Damage After normal Block 0x00000034
am i wrong some where
this type of error/message usually occur when there is memroy leak...
[ot] anyways... Hows your Xmas prepartion going on.... Marry Xmas
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
ThatsAlok wrote: this type of error/message usually occur when there is memroy leak...
Nopem this type of error occur when the pointer of your array has been corrupted (there are some bytes in front of your data that contains information about your array, such as the size and things like that, and these bytes are being overwritten). This may come because you write outside the bounds of the memory that is just before your array.
ThatsAlok wrote: Hows your Xmas prepartion going on.... Marry Xmas
Lot of things to do during these holidays  (visiting families and things like that). Merry Christmas to you also !
|
|
|
|
|
Cedric Moonen wrote: this type of error occur when the pointer of your array has been corrupted (there are some bytes in front of your data that contains information about your array, such as the size and things like that, and these bytes are being overwritten).
It seems its very rare error.... could you give me some example relating to same 
Cedric Moonen wrote:
Lot of things to do during these holidays (visiting families and things like that). Merry Christmas to you also !
yeap thanks
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
If I remember correctly (not sure anymore), this can happen when for example int this case:
class MyClass<br />
{<br />
char Temp1[10];<br />
char Temp2[10];<br />
}
And then, you copy something that is bigger than 10 char in the Temp1 array. Not sure that this will generate the error each time, you have to check it
|
|
|
|
|
Well, I maintain that the message observed Damage After normal Block 0x00000034 is usually encountered when you overwrite a guard byte at the end of an allocated memory block. Internally, the memory pool manager reserves a 'few' extra bytes at the end of an allocation because these stupid c-string off by one errors are so F_____G common. So, when you go to free the memory, the memory pool manager code checks the guard bytes to see if the values have change (yes, he over wrote one of them with a zero) and it issue a warning.
No shirt, no shoes, no brains, no service.
|
|
|
|
|
No , i am not allocating the memory
many times i have just done it once
its not the cause
Vikas Amin
Embin Technology
Bombay
vikas.amin@embin.com
|
|
|
|
|
vikas amin wrote: many times i have just done it once
ohh, in that case why don't you use CString or stl::string class... is there any problem using them
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
vikas amin wrote: In my class the code is as
char *m_FileName;
m_FileName=new char[strlen(FileName)];
strcpy(m_FileName,FileName);
are you calling this code in Constructor or some where else... You have delete memory every time you allocate it.. it seems you allocating memory many times but deallocating only one time, at time of destruction.
better use CString class instead of new
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
ThatsAlok wrote: are you calling this code in Constructor or some where else... You have delete memory every time you allocate it.. it seems you allocating memory many times but deallocating only one time, at time of destruction.
Good point using the example code I gave earlier the fix would be to add this to the MyClass class
//constructor
MyClass() { mystring = NULL; } // could also create a constructor that assigns the string
~MyClass() { if (mystring) delete[] mystring; }
SetMyString(const char* const newString)
{
if (mystring) delete[] mystring;
mystring = new char*[strlen(newString)+1];
strcpy(mystring, newString);
}
|
|
|
|
|
|
So, you still get the crash apparently... Are the two files (the header and the source file) big ? If not, post them completely, we will try to help you. Cause with the suggestion we gave you, it should work, so the problem is probably elsewhere: you probably write outside some other boundary that overwrite on the m_FileName address (thus corrupting some internal information at the begining of the array).
|
|
|
|
|
Ok i will just docment the files
and send u .
Vikas Amin
Embin Technology
Bombay
vikas.amin@embin.com
|
|
|
|
|
Hello !
I have a problem in my solution which use extensively STL.
When we remove pointer from list<> in A.dll to B.dll [OK]
When we put back from B.dll to A.dll [ACCESS VIOLATION]
We have : prim.dll, env.dll and app.exe (multithread)
[prim.dll] Shape* newLine();
[app.exe] list<Shape*> obj;
[env.dll] list<Shape*> undo;
The senario :
[create line] Shape* line=newLine(); obj.push_back(line);
[delete line] obj.remove(line); undo.push_back(line);
[undo delete] obj.push_back(undo.front());
[problem ] obj.front()=0xfeeefeee
Object was never delete until now, but we got an invalid pointer. Your idea and comments would be very helpful.
Thanks.
|
|
|
|
|
Did you accidentally mix-up the calls? Maybe you deleted it during one call because you swapped two lines of source?
Or you have a , where a ; should be?
Cheers,
Sebastian
--
Contra vim mortem non est medicamen in hortem.
|
|
|
|
|
Thank you for your comments. I would scan for , and ; misplaced.
Sovann.
|
|
|
|
|
I'm not new to programming, I am however new to Visual Studio C++. I'm adapting an old engine to use some newer libraries. I know the code in the new libraries is fine as we use it in several other projects, however whenever I try to call some functions in this one project I get LNK2019 errors.
A sample of the message is:
st_model.obj : error LNK2019: unresolved external symbol "public: static void __fastcall Graphics::NodeBin::QueueForDelete(class Graphics::Node *)" (?QueueForDelete@NodeBin@Graphics@@SIXPAVNode@2@@Z) referenced in function "public: void __thiscall Tool::Model::Free(void)" (?Free@Model@Tool@@QAEXXZ)
with the source code generating the error :
st_model.cpp
<br />
#include "gr_node_bin.h"<br />
<br />
namespace Tool<br />
{<br />
void anyfunction()<br />
{<br />
<br />
::Graphics::NodeBin::QueueForDelete(NULL);
<br />
}<br />
}
the QueueForDelete interface
gr_node_bin.h
namespace Graphics<br />
{<br />
class NodeBin<br />
{<br />
<br />
public:<br />
<br />
static void QueueForDelete(Graphics::Node *node);<br />
<br />
};<br />
}
the QueueForDelete implementation
gr_node_bin.cpp
namespace Graphics<br />
{<br />
<br />
void NodeBin::QueueForDelete(Graphics::Node *node)<br />
{<br />
}<br />
<br />
}
I've tried several different calling conventions within the project but they don't seem to have any effect.
Can anyone help me here? Are there any decent online references to tell me what the symbols mean?
|
|
|
|
|
Nevermind. One of the dependancies wasn't ticked in the project settings. Don't you just love when something that looks so complex turns out to be so simple.
|
|
|
|
|
I dont know the solution of ur problem
but
the symbols are generated by the compiler
which is know as NAME MANGLING .
It is essential in C++ as there are overloaded
functions , and the compiler have to differenciate
them .so it generate a different name for it .
could not find much detials u see this site
http://www.cs.virginia.edu/~cs216/labs/lab6/Linking/MS%20Visual%20C++%20and%20Assembly.htm
http://www.google.co.in/search?hl=en&q=vc+compiler+changes+the+name+of+function&btnG=Google+Search&meta=
Vikas Amin
Embin Technology
Bombay
vikas.amin@embin.com
|
|
|
|
|
Thanks. Now that you mention it name mangling rings a bell.
|
|
|
|
|
You can get your 'unmangled' names declared this way:
<br />
extern "C" {<br />
#include "gr_node_bin.h"<br />
}<br />
In other words, when you include header in CPP file for that of library written in C, you need to let compiler know now to make your OBJ look for UN-mangled names, since they will be UN-mangled in the other C-style library.
No shirt, no shoes, no brains, no service.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
