DLL problem why ??? (c++)
Author
Dear community , consider the following case :
i have a class CMaterial : public CSerializable where CSerializable is an abstract class that define methods for saving and writing to a file.
the method looks like this in CMaterial which is implemented in the dll :
void CMaterial::SaveToFile(FILE **f)
{
fwrite(...,...,...,*f); // THIS DOESN'T WORK AND THE POINTER *f IS THE SAME AS IN THE EXE
}
In the executable :
FILE *f = fopen(...);
CMaterial *mat = new CMaterial();
fwrite(..,...,...,f); // THIS WORK
mat->SaveToFile(&f); // THIS DOESN'T WORK AND CRASH WITH 0xc000005 while in the DLL the pointer has the same value as in the exe
I can't understand the problem, i need help , thanx in advance for your help...
First some remarks.
Why use a pointer to a pointer? Why not just use FILE*?
Do your DLL need to modify the value of the pointer (not likely).
Why use FILE* at all since this is not very C++'ish?
The problem I think is that the FILE* contains a structure that allocates something on the heap. The DLL and the EXE uses different heaps.
My guess is that the fwrite call in the DLL free's some previously allocated memory but since that memory was allocated using another heap it gets into trouble.
This should work if you're using a DLL compatible crt (run time library).
What compiler etc are you using?
On the old MSDEV6 the settings are under "Project\Settings...\C/C++\Code Generation\Use run-time library:"
Quote:void CMaterial::SaveToFile(FILE **f)
Why use a pointer to a pointer? Why not just use FILE*?
Do your DLL need to modify the value of the pointer (not likely).
Why use FILE* at all since this is not very C++'ish?
The problem I think is that the FILE* contains a structure that allocates something on the heap. The DLL and the EXE uses different heaps.
My guess is that the fwrite call in the DLL free's some previously allocated memory but since that memory was allocated using another heap it gets into trouble.
This should work if you're using a DLL compatible crt (run time library).
What compiler etc are you using?
On the old MSDEV6 the settings are under "Project\Settings...\C/C++\Code Generation\Use run-time library:"
Author
i use FILE ** for test purposes as it doesn't work with FILE * so don't bother with that , anyway thanx for your response it helps me to understand a little more those DLLs,
i use MSVC 2005 for compiler and the project properties is Multithreaded Debug DLL ...
do you think i will not have this pbm with iostream ?
thanx again.
i use MSVC 2005 for compiler and the project properties is Multithreaded Debug DLL ...
do you think i will not have this pbm with iostream ?
thanx again.
What's the exact error message? You say it's an access violation, but is it reading or writing, and what's the address?
Did you compile the DLL and EXE with the same version of visual studio? If not, then all bets are off as to whether it'll work or not.
Did you compile the DLL and EXE with the same version of visual studio? If not, then all bets are off as to whether it'll work or not.
Author
Quote:Original post by Evil Steve
What's the exact error message? You say it's an access violation, but is it reading or writing, and what's the address?
Did you compile the DLL and EXE with the same version of visual studio? If not, then all bets are off as to whether it'll work or not.
techdemo1.exe: 0xC0000005: Access violation writing location 0x00000010.
then it breaks into malloc.c
here
if (__active_heap == __SYSTEM_HEAP) {
return HeapAlloc(_crtheap, 0, size ? size : 1);
All the code is built with the same environment...
The location of the error message points to a NULL pointer access.
Somewhere there's a NULL access in your code.
Somewhere there's a NULL access in your code.
Are you sure fopen() succeeded? It returns NULL on failure, and if you then try to fwrite() to a NULL file handle, you'll get a crash that looks exactly like that.
Author
Quote:Original post by Evil Steve
Are you sure fopen() succeeded? It returns NULL on failure, and if you then try to fwrite() to a NULL file handle, you'll get a crash that looks exactly like that.
Okay , thanx to all for your help , i checked that the pointer wasn't null but i still have the crash.
Nevertheless EQ was right , i tried to do the same thing with ofstream class and it is okay.
I consider using ofstream rather than fwrite ...
Thanx all and EQ !
I'd be more inclided to track down the cause of the null pointer (using the debugger's call stack) than just going "Oh well" and moving on. For all you know the problem might still exist, just hidden in a different way.
Author
Quote:Original post by Evil Steve
I'd be more inclided to track down the cause of the null pointer (using the debugger's call stack) than just going "Oh well" and moving on. For all you know the problem might still exist, just hidden in a different way.
i'm sorry but i have no time for this...i would like to but i have to write so many functionality that what i want is only the job to get done.
Even better i think it's better to use stl::iostream than old fwrite , fread ect...so that's why i'm giving up on this...again sorry, my conclusion is when passing FILE* to the DLL like said eq , the heap is not the same because the FILE structure hold a pointer wich is statically assigned from the heap where the structure has been initialized : the exe client ( i was calling fopen in the exe side not in dll)
Since the heap are different , the pointer contain weird data that's why when i call fwrite in the dll it cause 0xc000005 for writing.
hopes we are in truth with this and help someone else.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
