|
You are missing the point, devvvy. You have two problems:
a) the new/delete pairing, which you said you've fixed (original post was new/free pairing which is not correct).
b) the actual location of the new/delete pairing - this is causing the CRASH.
devvvy wrote:
I tried:
(a) "new" with "delete"
and
(b) "free" with "malloc"
Still crashing the very same way... and besides I think I'm already doing this.
You are pairing new with free(), not with delete, so you need to make the change.
However, you need to use the correct pairing (new & delete) in the same routine.
Your logic:
Create a new buffer in main();
Free buffer in main(); // Works okay
Create a new buffer in the DLL;
Free that buffer outside of the DLL, in the main program; // Crashes
You can't do that because the main program and the DLL have different heaps. The main program does not have access to the DLL's heap, so the pointer is invalid upon return to main.
Either create the 2nd buffer in main and also pass the 2nd buffer to NullTerminateString, or add a new method to the CUtilities class that deletes pszResult when you are done with it.
Reread the comments on the _CrtIsValidHeapPointer() before the _ASSERTE(). That describes your problem exactly.
devvvy wrote: /*
* If this ASSERT fails, a bad pointer has been passed in. It may be
* totally bogus, or it may have been allocated from another heap.
* The pointer MUST come from the 'local' heap.
*/
<br />
It is difficult to tell the intended purpose of NullTerminateString(). The logic (use of string.size()) and variable names (pszData) both indicate the input is already a null-terminated string, but my brain says that you actually want to add a null to a non-null-terminated string. Not clear...<br />
<br />
I assume the purpose of NullTerminateString() is therefore to add a second null to the end of an already null-terminated string, because the routine fails if char * pszData is not already null terminated. (It can't determine proper size at string.size().)<br />
<br />
<br />
<blockquote class="FQ"><div class="FQA">devvvy wrote:</div>ch = pszBuffer[5]; // Should be '\0'<br />
free(pszBuffer); << LOCATION2: CRASH Here!<br />
</blockquote><br />
<br />
Note: pszBuffer[5] WILL BE NULL even without calling NullTerminateString()!<br />
Set szBuffer1 to 'a','b','c','d','e','f','g','h','i','j' and watch things go crazy.<br />
Gary
|
|
|
|
|
Thanks - I did take care not to allocate and disallocate memory from different dll... howeever, may be I missed certain places the trouble remains.
Advised by another developer, I changed some of the methods to take "const string &" as supposed to just "string" - after which the problem persists when debugged under Visual Studio 6. And the problem disappeared when debugged under Visual Studio 2005...
passing by value invokes "temporaries", and destructor won't work properly for these temporaries when passed across dll boundaries? But still why it crashed with VS6 and not VS2005??
baffling!!
I can send you the code if you are willing to look at it. Thanks!
devy
|
|
|
|
|
The computer I am using havn't been installed MSDN.I want to know that how to use CreatePolygonRgn(CONST POINT*,int,int).Could somebody send the information about the function in MSDN?Thank you.
And is the function PtInRgn exist?I want to use the both function to judge if a point in a polygon region.
Thanks for your help.
|
|
|
|
|
If you can access the Internet, you can go to http://msdn.microsoft.com
|
|
|
|
|
|
Strangely enough if you google createpolygonrgn the first listed linkage is TADA[^]
|
|
|
|
|
Did you ever realize that if you want to find help for a function on MSDN, it is much more efficient to use google than the MSDN search ?
|
|
|
|
|
hey, MSDN site has been refactored, and i find it very very much powerful by now !
|
|
|
|
|
I only have the modem connection and google is quicker, MSDN takes at least a minute to load, the same again to return the list of linkages.
|
|
|
|
|
toxcct wrote: very very much powerful by now
But Speed the same na?
|
|
|
|
|
Cedric Moonen wrote: Did you ever realize that if you want to find help for a function on MSDN, it is much more efficient to use google than the MSDN search
You are right. I used to do so..
|
|
|
|
|
please help me to develope registry cleaner for window xp
|
|
|
|
|
do you want us to write the code for you ?
or you're stuck on a particular point ?
please ask a specific question !
|
|
|
|
|
it depends on what you want to do, to clean.
to access to the registry there are many functions in the form Reg****Key , as RegOpenKeyEx , RegCloseKey , RegDeleteKey , RegSetValueEx , ...
Russell
|
|
|
|
|
Write to me. I accept paypal.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->ßRÅhmmÃ<-·´¯`·.
|
|
|
|
|
brahmma wrote: Write to me. I accept paypal
classic...
me accept payment in kind (if his GF is correct enough) :->
|
|
|
|
|
I'm imagining you in a dark street, holding up a sign...
"Will code for nookie!"
Iain.
|
|
|
|
|
I am currently working on an asset register as a project and would like to acquire information on the hardware as well as software installed on a host
Can anyone help!!
Kim
|
|
|
|
|
kim007 wrote: I am currently working on an asset register as a project and would like to acquire information on the hardware as well as software installed on a host
Sounds fun. Good luck.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
|
Hello,
I have a major problem with the .h header files.
The Compiler (VS2003) does not seem to care about my function definition in the header file if implemented in another .cpp file.
Here is an example:
[myfunc.h]
#pragma once
int DLLInit(char* DLLInfo);
[myfunc.cpp]
#include "myfunc.h"
int DLLInit(int DLLInfoInt)
{
return 0;
}
I seem to be missing the whole point of a header file if the compiler does not detect the false declaration of variable name and type....
I want to include the header file in the project using the dll, too, so it is important to check parameter and type of function parameters, etc.
Maybe this is a very simple problem but I can't find a solution yet..
Any help?
thx in advance
|
|
|
|
|
sGrabert wrote: [myfunc.h]
#pragma once
int DLLInit(char* DLLInfo);
[myfunc.cpp]
#include "myfunc.h"
int DLLInit(int DLLInfoInt)
{
return 0;
}
check your code once again...
you declare a function that gets a char* , but you define a function that gets an int ...
why the compiler wouldn't complain then ?
|
|
|
|
|
sGrabert wrote: I seem to be missing the whole point of a header file if the compiler does not detect the false declaration of variable name and type....
Why would it ? Function overloading is possible in C++ and you don't need to have a declaration for your functions. So, in your case you have a declaration of a function but no body for this function. As long as you don't call that function, everything will be fine. But once you call that function, you'll get a linker error.
So, actually, what is your real problem ? I don't understand what you are trying to achieve...
|
|
|
|
|
Cedric Moonen wrote: you have a declaration of a function but no body for this function. As long as you don't call that function, everything will be fine.
that's not true anymore under VS2005 AFAIK (but didn't tested actually)...
|
|
|
|
|
toxcct wrote: that's not true anymore under VS2005 AFAIK (but didn't tested actually)...
I never heard of that and I hardly imagine that...
Suppose that you have three files:
- One main.cpp that contains the main function
- One header file (file.h) that contains a function declaration
- One cpp file (file.cpp) that contains the function definition (of the previous function).
Suppose that you call this function in the main function. How can the compiler know, when compiling main.cpp that this function is actually defined in file.cpp ? What if you didn't include file.cpp in your project ?
Thus the error is generated at link time, when the linker cannot find the compiled function in the object files.
|
|
|
|