|
"a heap error on the deletion of the std::vector tokens"
I cant see any deletion of anything called tokens but in anycase, you dont want to delete a stack variable. It gets cleaned up when the func exits. You only delete stuff you have allocated with new.
==============================
Nothing to say.
|
|
|
|
|
Run app verifier on it. It looks s if the heap vector is getting corrupted somehow.
==============================
Nothing to say.
|
|
|
|
|
I was able to solve the problem by setting all of the libraries to use multi-threaded dll instead of some multi-threaded and others multi-threaded dll. I had to use the /FORCE:MULTIPLE option but it works now without a heap error. Question though: Where do I find this app verifier you mentioned?
Nothing is impossible, It's merely a matter of finding an answer to the question of HOW? ... And answering that question is usually the most difficult part of the job!!!
|
|
|
|
|
Application Verifier is a Microsoft download. You can get it of MSDN
==============================
Nothing to say.
|
|
|
|
|
In Win32, when you pass an object through DLL boundaries you cannot allocate memory in one module (DLL) and delete it in another module (your main program, another DLL), unless you use the Global Heap for allocation/deallocation. Another approach is to create a deallocator function in the same module and pass it to another module to delete the object.
In Win64, there will be no problem: you can allocate objects in one module and delete them in another.
|
|
|
|
|
hi all,
i have hexadecimal values in the form of CString in my list control.
i want to sort them and my list according to those sorted values.
How can i do this??
|
|
|
|
|
If they are strings then you can use a simple string comparison.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Simple String Comparison will lead to dictionary type sorting. OP would also have to verify the length of string
as example
ABE
AB
ACD
ABEF
If you sort simply comparing string then the output will be look like
AB
ABE
ABEF
ACD
But If you do sorting(mathematical) Then it would be
AB
ABE
ACD
ABEF
So, I will suggest to consider the length of the string too
|
|
|
|
|
You may use your custom sorting function in ListView_SortItemsEx[^] call.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi,
what is difference between windows 7 and windows 2003 sever in memory heap allocation?
i have a project in visual studio 2008 C++ with using Unicode for character setting.
my project run in 2003 sever without any problem. but when i run it in windows 7, my project is breaked on a "memory allocation" line in code, like:
int i_size = 50;
wchar_t* wch = new wchar_t[i_size];
with this error message:
this maybe due to a corruption of the heap, which indicate a bug in my.exe or any of the Dlls it has loaded.
please help me.
Zo.Naderi-Iran
|
|
|
|
|
This means that the heap has been corrupted somewhere else in your code. you will need to do some debugging to discover where it happens; usually caused by overrunning a buffer somewhere.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
but my project compile and run in windows 2003 sever without any heap corruption!
what difference between windows 2003 and windows 7 ?
Zo.Naderi-Iran
|
|
|
|
|
Different is Windows 7 is giving you better security(probably)
Here is an example of how heap crashed
In one of my application I defined a string variable with the size of 20, I was reading the text from a text box. But User Put more than 20 character in that box.
It never crash in xp. But Do worse it destroy another value which has been defined right after that sting variable.
So, Its better it crashed cause at least you know where you can find the problem
|
|
|
|
|
i guess that my problem is not in size of memory allocation. However, i will check it.
but, is any other reason?
Zo.Naderi-Iran
|
|
|
|
|
zon_cpp wrote: is any other reason?
Such as what? If the heap is corrupted that means there is a piece of code that is writing somewhere in memory at an address that it does not own - it's a bug.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Just because it runs successfully in one system does not mean it is bug free. If it crashes because of heap corruption it is almost guaranteed that there is a bug in your code somewhere.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
You have a bug in your code, so run App Verifier on it and it will tell you exactly where it is happening.
--edit--
Who is the prick who one voted this?
If you are developing code and not running it through app verifier you are missing out on an opportunity to boost your products quality.
==============================
Nothing to say.
modified 22-Dec-11 13:05pm.
|
|
|
|
|
In case it's not been clear in the other messages:
A heap corruption message, and specifically that message, is telling you that somewhere, somewhen, the internal stuctures of the heap's memory management have been overwritten (corrupted). Because it did not or could not detect it at the moment it happened, heap corruptions are reported when you do something that requires the heap and that's when the run time library runs a "heap consistency check" and throws the error message.
So, it's not telling you that the particular call you did was wrong, it's just that the call was the first place it detected a previous corruption. So it's important to not focus on that particular call as the source of the problem. However, that call does give you a point in time when the corruption occurred. If you have other allocation / deallocation calls in your code, you know that the corruption occurred sometime between the last heap call and this one. That gives you a chance to narrow down the section of code to look at.
Lastly, heap corruption detection only happens in debug mode code / libraries as it is a performance hog. So, you can have had this bug for a long time and never notice it in production mode code.
|
|
|
|
|
If I had to guess, that line is probably not the problem, your problem is elsewhere. Just happens to break at that point, can you look at the call stack and see what calls happened prior to the error?
|
|
|
|
|
Hello,
I'm working on a project that deals with DLLs extensively. One bit of information that I've learned so far is that an executable will retrieve a DLL's exported function that it needs, and put the function address in the executable's Import Address Table (IAT). One question that I have is "How do functions from one DLL get called to another DLL within Windows?" Does a DLL also have an IAT in which it holds function pointers that it used from another DLL, or are these kinds of function calls also added to the executable's IAT?
Any help would be appreciated!
Thanks!
|
|
|
|
|
ryan2189 wrote: Does a DLL also have an IAT in which it holds function pointers that it used from another DLL
Yes.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
dlls and exes are essentially the same
|
|
|
|
|
I'm sure this is c++ 101
I build a class to encrypt and decrypt, but when I use the function multiple times, it changes the values of the previous buffers I stored the values in.
This is the first time I have called a function multiple times, so I'm not sure how to handle it.
CA_Encryption caEncrypt;
WCHAR *szSecretAnwser_Secure = new WCHAR[12];
szSecretAnwser_Secure = caEncrypt._encrypt_3DES(szSecretAnwser);
WCHAR *szPassword_Secure = new WCHAR[12];
szPassword_Secure = caEncrypt._encrypt_3DES(szPassword);
const int MD5_SIZE = 16;
BYTE *szPassword_Encoded = new BYTE[MD5_SIZE];
szPassword_Encoded = caEncrypt._create_MD5_Hash(szPassword);
|
|
|
|
|
I'm not sure where this code actually exists as you have not shown where in the function it is, or really what it is trying to do. however when you allocate a buffer with a new operator it creates a new buffer every time you pass that line of code (you should also delete[] them when finished with). If you want some permanent buffer then you should allocate it outside the function and pass it in as a reference on the function call. Something like:
int myfunc(buffer* pszBuffer)
{
return 1;
}
char* nbuff = new char[64];
int val = myfunc(nbuff);
delete[] nbuff;
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
I didn't want to post the function because I had no idea where my poor use of buffers was. I made a class, and wrote 5 functions in it.
Normally I would of wrote 5 public functions, and do the work in private functions.
But no matter which function I run in the same class, it changes the previous buffer values to the last function ran in the class.
I think I understand now why everyone had there encryption function separated into 3 aspects.
Let me try that first.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
