|
led mike wrote: I have no idea what you mean with that statement. You can't "mix" memory addresses across processes because you don't have access to them. Therefore you can't get that "trouble".
Sorry, maybe it was not clear: your dll has its own heap manager (which manages the heap memory) and the exe has its own heap manager too. If, inside a function of your dll, you allocate memory, it will be allocated by the heap manager of your dll. If you return this pointer to your exe (simply a return from the function) and you try to delete inside your exe, the memory will be released by the heap manager of your exe, which doens't recognize it (of course, because it didn't allocate it). Thus, you got the problem.
Seing his code, if he didn't do any stupid things inside his dll (so if he simply allocate the memory as normal) that's the only thing that can cause the crash.
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
I don't understand what you describe. Could you be more explicit ? What are these clsobt, clobj, cls and cls1 ?? 
bujji_bec wrote: delete []p; // this statement giving problem
What problem ? You get a crash ? A compile error ? A blue cow is getting out of the screen (this one is highly improbable I think  ).
Anyway, what I think you are doing is using a new inside your dll (you call a function from your dll in which you allocate memory with new), you store this pointer into the variable p and then you try to free the memory. And there BANG, you get an assertion.
It is because the heap manager of your exe and of your dll are different, thus you CANNOT delete memory that has been allocated by your dll and vice-versa. To avoid this problem, use a std::string (but beware you have to link to the same run-time libraries in both of your project settings or you'll get the same problem)
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
Cedric Moonen wrote: A blue cow is getting out of the screen (this one is highly improbable I think ).
no no. this happened to me just two days ago. i was doing a delete [] on something i had allocated with HeapAlloc then resized with _realloc. the cow was pissed, and it broke my desk.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Cedric Moonen wrote:
A blue cow is getting out of the screen (this one is highly improbable I think ).
Chris Losinger wrote:
no no. this happened to me just two days ago. i was doing a delete [] on something i had allocated with HeapAlloc then resized with _realloc. the cow was pissed, and it broke my desk.
You should have derived from CGrassEater instead of CVegetarian.
Now you've made the CHolyCow angry!
It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"
|
|
|
|
|
Roger Stoltz wrote: You should have derived from CGrassEater instead of CVegetarian.Now you've made the CHolyCow angry!
Hope, he doesn't derived CHolyCow from CMenEater.....
Sorry Cedric Just Jokin!
"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
|
|
|
|
|
Cedric Moonen wrote: It is because the heap manager of your exe and of your dll are different, thus you CANNOT delete memory that has been allocated by your dll and vice-versa.
 What in the name of X86 are you talking about! 
"What classes are you using ? You shouldn't call stuff if you have no idea what it does"
Christian Graus in the C# forum
led mike
|
|
|
|
|
Cedric Moonen wrote: t is because the heap manager of your exe and of your dll are different, thus you CANNOT delete memory that has been allocated by your dll and vice-versa.
This problem arises in COM dll not normal DLL, as Memory allocation in Normal DLL is under the Excutable who is calling Function.
similarly, you can see CoTaskMem* series, which deal with same!
"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 problem arises in COM dll not normal DLL, as Memory allocation in Normal DLL is under the Excutable who is calling Function
Nope, not at all ! Try it: call a function from your dll in which you allocate memory, return this memory and delete it in your program, you will get a crash. I'm sure of that. There are two heap managers: one for the exe and one for the dll. If you try to release memory in your exe that has been allocated by your dll, that won't work.
Also, ask toxcct, he got the problem 
COM dll are just standard dll's (they just provide a set of existing functions and they provide them in a defined way).
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
Cedric Moonen wrote: There are two heap managers: one for the exe and one for the dll.
There can be if the author of a DLL creates a private heap (I have never seen this). However that does not happen by default. There is one and only one default heap across an entire process.
reference[^]
The Process heap is used for allocating blocks if no other heap is used. Language
run times also can create separate heaps within a process. (For example, C run time
creates a heap of its own.) Besides these dedicated heaps, the application program or
one of the many loaded dynamic-link libraries (DLLs) may create and use separate heaps.
COM does not change any of that. If you load a COM dll in process then it shares the same heap. If it is out of process then any memory resources you obtain in the local process from the COM interfaces is marshaled into the local process. This means memory is allocated in the local process and the data has been copied into it from the COM remote process. The local process has NOT been given an address in memory from the remote process.
"What classes are you using ? You shouldn't call stuff if you have no idea what it does"
Christian Graus in the C# forum
led mike
|
|
|
|
|
led mike wrote: There is one and only one default heap across an entire process.
Maybe heap manager was not the good term. Ok, they have the same heap but still, you cannot delete memory that hasn't been allocated by the same module:
Both the DLL and the executable file (EXE) maintain their own lists of allocated memory blocks, which they maintain through the malloc memory allocator. The C++ new and delete functions also rely on these lists of memory blocks, so that C++ tends to use dynamic memory allocation more often than C. If the DLL allocates some memory—for example, for the creation of a new instance of a class—this memory is marked in the allocation list of the DLL. If the EXE tries to free this memory, the run-time library looks through its list of allocated memory blocks and fails (usually with a GP fault). Thus, even if the memory between the DLL and the EXE is completely shared, the logic for managing allocation breaks if two modules mix their allocation schemes.
Reference[^]
And furthermore, something that is more relevant than hundred of articles: I experienced this problem. And it was solved by following this guideline: never free mem that has been allocate by your dll in your exe.
And, also, try it yourself, it will be the best proof: make a simple dll with a simple function that only allocate some memory (a char array for example) and return this pointer. Then, in your program, delete this memory. You'll see what happen
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
The article you reference does clearly state your position. The one I referenced seems to contradict it and is 4 years newer than the one you reference.
I just did a sample application (EXE is: MFC dialog project) and a second project is( Win32 DLL project)
The DLL exports a function which allocates memory and returns the pointer.
MYDLL_API char* allocCharOnHeap()
{
char* p = new char[12];
ZeroMemory(p, sizeof(char) * 12);
strcpy(p, "Hello Heap");
return p;
}
The MFC EXE project calls this, outputs the string and deletes the memory. No errors occur. If I comment out the delete line the IDE reports a memory leak as expected.
char* pFromDll = allocCharOnHeap();
TRACE("%s\r\n", pFromDll);
delete [] pFromDll;
It would appear that the article I referenced is correct while the older one my not be entirely accurate.
Of course it is not a good design to return pointers from functions and rely on the user code to free the memory regardless of DLL vs EXE or anything else. 
"What classes are you using ? You shouldn't call stuff if you have no idea what it does"
Christian Graus in the C# forum
led mike
|
|
|
|
|
Hello !
I tried it myself too and, to my big disapointement, it didn't crash  . I then checked something else: using two different runtime libraries (multi-threaded debug for the exe and multi-threaded debug dll for the dll). And now it assert (on the expression _CrtIsValidHeapPointer(pUserData) ). So, in that case, the heaps are different and that is why I got the error previously probably.
Anyway, it is strange that the article I sent you contradict this fact . I'll try this evening with VC6 to see if the behavior is different (which I doubt).
Thanks for the discussion
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
Hi,
I am using following code to add ToolTip in my code,
m_tooltip.Create(this);
m_tooltip.Activate(TRUE);
CString text;
text.Format("Tool-Tip");
m_tooltip.AddTool(GetDlgItem(IDC_BUTTON1), text);
This shows single line ToolTip on Button.
When I use,
text.Format("Tool-Tip \n Line2");
It is not showing ToolTip properly.It is showing rectangle instead of new line.
Here how can I show more than one line ToolTip (Multiple Line ToolTip)on that Button?
Best Regards,
Aniket
-- modified at 10:15 Thursday 18th May, 2006
|
|
|
|
|
Instead of using Create ,use CreateWindowEx with the style TTS_ALWAYSTIP
m_hWndToolTip = ::CreateWindowEx(WS_EX_TOPMOST,<br />
TOOLTIPS_CLASS,<br />
NULL,<br />
TTS_NOPREFIX | TTS_ALWAYSTIP,<br />
CW_USEDEFAULT,<br />
CW_USEDEFAULT,<br />
CW_USEDEFAULT,<br />
CW_USEDEFAULT,<br />
m_hWnd,<br />
NULL,<br />
NULL,<br />
NULL);
then use
::SendMessage(m_hWndToolTip, TTM_SETMAXTIPWIDTH, 0, SHRT_MAX);
Appu..
"If you judge people, you have no time to love them."
|
|
|
|
|
Hi,
Thanks for your suggestion. It's working. I am using following code.Is this correct code?
CToolTipCtrl m_tooltip;
m_tooltip.m_hWnd = ::CreateWindowEx(WS_EX_TOPMOST,TOOLTIPS_CLASS,NULL,
TTS_NOPREFIX | TTS_ALWAYSTIP,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,
this->m_hWnd,NULL,NULL,NULL);
::SendMessage(m_tooltip.m_hWnd, TTM_SETMAXTIPWIDTH, 0, SHRT_MAX);
CString text;
text.Format("Tool-Tip \n OK");
m_tooltip.AddTool(GetDlgItem(IDC_BUTTON1), text);
Best Regards,
Aniket
-- modified at 11:47 Thursday 18th May, 2006
|
|
|
|
|
Hi,
2 statments given by you, What is the operation performed by that statments ?
Best Regards
Aniket
|
|
|
|
|
hi all
can somebody explain what is a .lib file ?
what advantages it has when using in projects , against simple classes .cpp and .h files?
thank you.
|
|
|
|
|
A library is used by your project to load particular symbols (funcions or variables). It contains compiled code.
In brief the purpose of the lib file is to provide a 'package' that can be reused in several applications without divulging the source files (only headers are supplied).
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
Cedric Moonen wrote: In brief the purpose of the lib file is to provide a 'package' that can be reused in several applications without divulging the source files (only headers are supplied).
It means instead loading the .cpp and .h files to his project, he will be including the header file only ?
and writing
#include someClass.h
Does the .lib file have to be in the same directory as the project ?
|
|
|
|
|
.cpp -- Simple C++ implemenation File
.h -- Header file
.obj -- a description of the program suitable for linking
.lib -- an index of the contents of a dll used by the linker
.exp -- an index of the symbols exported by a dll
.exe -- an executable program
.dll -- a dynamic link library located at run time using PATH env variable
.def -- a text file which tells the linker what to put into a .dll
Appu..
"If you judge people, you have no time to love them."
|
|
|
|
|
wrote: .lib -- an index of the contents of a dll used by the linker
A lib is not always associated with a dll. You can simply have a static library that export symbols without having a dll. The difference is that the code of your lib file will be 'added' to your application at link time (unlike a dll, which is at run-time).
Cédric Moonen
Software developer
Charting control
-- modified at 10:41 Thursday 18th May, 2006
There is a problem in your name, please fix it because it screw things when I quote text from you
|
|
|
|
|
In addtion to what cedric has said,lib files are used to link the DLL implicilty.
your .h -> .lib ->.dll .
<marquee scrollamount="1" scrolldelay="1" direction="up" height="10" step="1">--[V]--
[My Current Status]
|
|
|
|
|
VuNic wrote: In addtion to what cedric has said,lib files are used to link the DLL implicilty.
your .h -> .lib ->.dll .
 Really ? .lib and .dll are two complete different things to me. A .lib is sort of a collection of .obj, and a .dll is, well, a .dll. Completely independant. So the .lib ->.dll, I do not understand ...
~RaGE();
|
|
|
|
|
If you want to implicitely load your dll (so, include the header files to your app and not call LoadLibrary and GetProcAddress), a lib file is needed. Dll and lib files are not so different, the only difference that I know is that the lib will be added to your app during the linkage of your app, and the dll will be added at run-time.
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
lib and .dll are completely different .
The .lib file is a file that has the stuff the linker needs to build your executable program. Windows cannot use them, but compilers and linkers can. Its a lot like a .obj file really, except it contains everything needed for all the stuff in your 'library' whereas an obj is from a single source file. It also contains a protocol for the associated .dll (basicaly, offsets of where functions start, the name and parameters(?) of the functions, calling conventions(?) and things like this).
A .dll can have a lot of different stuff -- data, functions, anything really. A dll that has shared routines is what the OS needs to run those routines -- compare this to a 'mini executable'. A program smoothly jumps from its own executable statements to the ones in the .dll and back again. Windows does some smoke and mirrors here to make the file loading efficient(ish).
Appu..
"If you judge people, you have no time to love them."
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
