DLL heap problem
Author
this is the first time i''ve divided my project into seperate DLL projects and ive run into a strange runtime problem....
here''s what happens:
** In WinMain I declare a vector. I''ve tried both on the stack (no "new") and the heap ("new").
** I then pass by reference that vector to a function which exists in seperate DLL project. That function then does some push_back() commands on the vector.
** Now im back in the scope of WinMain and if i do anything to my vector, such as clear()... i get an "Unhandled exception at 0xAddress in MyProgram.exe: User breakpoint." and it takes me to free.c in the IDE.
If i run my exe outside of the IDE it doesn''t crash or give me a memory access violation, however.
I''ve triple-checked my code and i see nothing wrong. My guess is that i need to setup a compiler defination or a flag so that the compiler/runtime either understands or ignores inter-dll memory or something.
Anyone know what''s wrong or what to do?
Thanks
- Duck
What compiler are you using? Assuming MSVC, did you set the CRT settings for all the projects (both DLL and application) to use the DLL version of the runtime library?
That being said, templated C++ code and DLLs really don''t mix that well. If you''re in a position that you''re passing pointers or references to template containers between separate modules, you should consider refactoring your code.
That being said, templated C++ code and DLLs really don''t mix that well. If you''re in a position that you''re passing pointers or references to template containers between separate modules, you should consider refactoring your code.
Author
I''m on MS Visual C++ .Net Standard.
the only settings that i changed beyond the project defaults were 1) i marked my "main" project as being dependant on the DLL projects, 2) i set the Runtime Library for the main project to Multi-Threaded /MT, and 3) i set Runtime Library for the DLL projects to Multi-Threaded DLL /MD.
beyond those i dont know of any other CRT settings to use.
- Duck
the only settings that i changed beyond the project defaults were 1) i marked my "main" project as being dependant on the DLL projects, 2) i set the Runtime Library for the main project to Multi-Threaded /MT, and 3) i set Runtime Library for the DLL projects to Multi-Threaded DLL /MD.
beyond those i dont know of any other CRT settings to use.
- Duck
I ran into this problem e few years ago also, for some reason you can sometimes get away with this and sometimes not.
Since dll''s and exe''s have separate protected memory areas, I beleive you cannot do this, or rather should not be able to.
When you pass your vector to the dll and perform push_back''s, it will try to change/allocate the memory (pointer to memory owned by the exe).
When the pointer later again is used by the exe, some of the memory has been allocated in the dll and some in the exe... and things get confused.
The way to avoid the problem/feature is to never allocated memory "cross-mem-boundaries", which is also quite good since you will have to pollish your system-design.
/martin
Since dll''s and exe''s have separate protected memory areas, I beleive you cannot do this, or rather should not be able to.
When you pass your vector to the dll and perform push_back''s, it will try to change/allocate the memory (pointer to memory owned by the exe).
When the pointer later again is used by the exe, some of the memory has been allocated in the dll and some in the exe... and things get confused.
The way to avoid the problem/feature is to never allocated memory "cross-mem-boundaries", which is also quite good since you will have to pollish your system-design.
/martin
Then this is probably just one of the generic DLL/template interaction difficulties. You might want to check out this article on how to get STL containers to play nicely with DLLs. But again, consider refactoring.
Author
schlinge, i understand what you are saying, however DLL memory is supposed to be owned by the parent process. I''m reading from Petzold 5th edition here... "Everything the DLL does is done on behalf of the applicaiton. For example, all memory it allocates is owned by the application." I think my problem is just with the debuging features of the C RunTime and i need to disable a portion of the debug features somehow.
Author
quote:Original post by SiCrane
Then this is probably just one of the generic DLL/template interaction difficulties. You might want to check out this article on how to get STL containers to play nicely with DLLs. But again, consider refactoring.
thanks for the link.. i might be able to work something out...
Try linking all projects to the same version of the run time library as SiCrane suggested. You can allocate/deallocate memory wherever you want, as long as each DLL and EXE in your solution is linked to the DLL version of the runtime library.
Matt
Matt
Author
alright im still having difficulties...
what if i change my dll projects into static libraries... will i still have to run through a complicated export of the STL components and/or will i still run into the same problem?
my intent for seperate DLL projects in the first place was to divide up my program into distinct parts with just a single public interface for each part. That way there is less clutter in the IDE when i am trying to organize my components and so i wont have to wait as long to compile the program in some cases.
...Is there another way to break up my program into distinct parts with their own variable space without using DLL's? If all else fails i could just use namespaces but that's kind of a hassle.
-Duck
[edited by - DuckMaestro on May 26, 2004 5:55:40 PM]
what if i change my dll projects into static libraries... will i still have to run through a complicated export of the STL components and/or will i still run into the same problem?
my intent for seperate DLL projects in the first place was to divide up my program into distinct parts with just a single public interface for each part. That way there is less clutter in the IDE when i am trying to organize my components and so i wont have to wait as long to compile the program in some cases.
...Is there another way to break up my program into distinct parts with their own variable space without using DLL's? If all else fails i could just use namespaces but that's kind of a hassle.
-Duck
[edited by - DuckMaestro on May 26, 2004 5:55:40 PM]
You can still go the DLL route, and you have a few options.
1. Least-hassle: switch all the project runtime libraries to [debug] DLL multi-threaded. This is done in the project options page...poke around. This consolidates all the heaps of the projects. Caveat: you now depend on msvcr71.dll *at runtime*, and maybe also msvcp71.dll.
2. Little-hassle: write an STL allocator that allocates within a certain DLL''s heap. This isn''t terribly difficult: export two functions from a certain DLL and override the allocate/deallocate member functions to call those instead of operator new/delete. I have done this before, but I can''t get to my code right now. If you need it, respond and I''ll follow up with it shortly.
3. Most-hassle: refactor so that the implementation details (such as use of a STL vector) are obscured. If you are going the component route, this is what I recommend, but I realize time isn''t cheap.
1. Least-hassle: switch all the project runtime libraries to [debug] DLL multi-threaded. This is done in the project options page...poke around. This consolidates all the heaps of the projects. Caveat: you now depend on msvcr71.dll *at runtime*, and maybe also msvcp71.dll.
2. Little-hassle: write an STL allocator that allocates within a certain DLL''s heap. This isn''t terribly difficult: export two functions from a certain DLL and override the allocate/deallocate member functions to call those instead of operator new/delete. I have done this before, but I can''t get to my code right now. If you need it, respond and I''ll follow up with it shortly.
3. Most-hassle: refactor so that the implementation details (such as use of a STL vector) are obscured. If you are going the component route, this is what I recommend, but I realize time isn''t cheap.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement