|
Looks like you are trying to delete the same pointer twice, or trying to delete something which is not a pointer to a heap based object.
If you can post some of the code, then we can help.
|
|
|
|
|
The normal debug configuration of a VS C++ project checks the heap hasn't been corrupted when you exit. If these assertions fire, the heap has been corrupted.
This is a wild-write bug. Somewhere, you're using a bad pointer, or have made a mistake in pointer calculation, or allocated too little space for a buffer, or written off the end of a buffer. These are very hard to track down. Ensure that you always initialize pointers to NULL or to a real value, so you don't get random stack garbage that could point anywhere.
If it's consistently the same address, you can use a data breakpoint to see when the data at that address changes. See 'data breakpoints' in MSDN Library.
|
|
|
|
|
|
according to the following call stack
<br />
NTDLL! 7c901230() <br />
NTDLL! 7c96cd80() <br />
NTDLL! 7c960af8() <br />
KERNEL32! 7c85e9cf() <br />
_CrtIsValidHeapPointer(const void * 0x00032b78) line 1697<br />
_free_dbg_lk(void * 0x00032b78, int 1) line 1044 + 9 bytes <br />
_free_dbg(void * 0x00032b78, int 1) line 1001 + 13 bytes operator <br />
delete(void * 0x00032b78) line 351 + 12 bytes <br />
CString::FreeData() line 146 + 15 bytes <br />
CString::~CString() line 213 $E155() + 34 bytes <br />
doexit(int 0, int 0, int 0) line 353 <br />
exit(int 0) line 279 + 13 bytes <br />
mainCRTStartup() line 345 <br />
KERNEL32! 7c816fd7()<br />
It is clear the error was occuring tryin to free the CString objects which incidentally I had made global due to the requirements. Hence I refactored my application and passed them as reference.
What I inferred from the situation is that while tryin to free up the Cstring memory it encountered that the heap had already been unintiallized. however it is still unclear to me how was the heap cleared before even C Runtime tried to unregister it. I never explicitly have defined any destructors.
There are only two kinds of people who are really fascinating-people who know absolutely everything, and people who know absolutely nothing.
Oscar Wilde (1854-1900)
Regards...
Shouvik
|
|
|
|
|
HELLO to every one..
my question is if i click a menu item from IDR_MAINFRAME window MENU BAR ,i have to be switched to IDR_MENU1 window..
plz help me..
vikram..
|
|
|
|
|
You could create a handler for that menu item, and inside it, call SetMenu ?
Sounds like a potentially bad design though, so I hope you have a really good reason for doing it this way.
Iain.
|
|
|
|
|
I was thinking about your question but I dont know your questions is advance or I dont understand your question.
|
|
|
|
|
To load a plugin from an application - the ATL/COM connection points are used for communication and handling events between host and plugin. If i were to add a second plugin which would load all dlls from a different path and replicating the mechanism of the first plugin, do i need to do any handling for memory management or threading issues? The two plugins will not communicate to one another, and user would switch between the plugins as necessary but the dlls for both plugins will be loaded at the start of the application and unloaded only when application is shutdown.Am not clear if i should inbuild any mechanism for threading or memory ownership issues? Could you also point me to a reference article if any?
Thanks
|
|
|
|
|
The issues you've mentioned don't relate directly to memory ownership or threading so it's a little difficult to give an answer. Your new plugin will need to follow the same threading model as the old one because that is what the client expects. It will need to manage parameter memory ownership the same way as the old one because that is what the client expects.
Also remember that if you link your new DLL statically to the C Runtime e.g. LIBCMT then it will get its own heap. If you link it dynamically with MSVCRT then it will share a heap with the client if and only if the client also links to the CRT dynamically.
Careful examination of the interfaces you're implementing, some guesswork and a lot of testing should get you there 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Hi
I am creating an object using new.
But when the control passes to the Ctor.Its not executing any of the lines in Ctor.
I have set break point in every line of Ctor.
CStateDescription::CStateDescription()
{ //Control comes her
int i = 10;
BOOL boo1 = FALSE;
DWORD dwFlashPictureRate = FlashingMedium; // medium
BOOL boo = FALSE;
//Then the control passes here directly. i is assigned as 0.and others garbage value.
}
Whats the problem here
-- modified at 22:37 Tuesday 19th June, 2007
VIBIN
"Fool's run away,where angle's fear to tread"
|
|
|
|
|
vibindia wrote: CStateDescription::CStateDescription()
{ //Control comes her
int i = 10;
BOOL boo1 = FALSE;
DWORD dwFlashPictureRate = FlashingMedium; // medium
BOOL boo = FALSE;
//Then the control passes here directly. i is assigned as 0.and others garbage value.
}
All the above variables are local to the contructor's scope. Thus, they don't exist when the constructor returns.
You need to do something like the following:
CStateDescription::CStateDescription()
{
i = 10;
boo1 = FALSE;
dwFlashPictureRate = FlashingMedium;
boo = FALSE;
}
Or better yet:
CStateDescription::CStateDescription()
: i(10), boo1(FALSE), dwFlashPictureRate(FlashingMedium), boo(FALSE)
{}
-- modified at 22:59 Tuesday 19th June, 2007
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
Not sure but I think it may be the cause.
Try to rebuild the application after clean all.
And my stupid thinking says me that you are trying to debug the application in Release mode 
Regards
Anil
|
|
|
|
|
_anil_ wrote: And my stupid thinking says me that you are trying to debug the application in Release mode
You can so long as you have configured your release build to produce a .PDB symbolic information file.
|
|
|
|
|
Basically, in what I'm programming, I use the WndProc function to direct input at my window, however, WndProc must be either a global or a static function. When a function is static, it can only access static members, unless they are created within the scope of the static function. There are two things I can do.
1 - Make the non-static members that I want to call static.
2 - Use static GetInstance() methods to get static instances of the classes which contain my members, and use those classes to access the members.
1 is a lot more arbitrary -- you can apply static to anything, and everything will become static. 2 is a lot cleaner, as I may have to access many members of my class and it would be easier to just get one static instance than make everything in that class static. I'm thinking of going with 2, as the classes of which I'd need to get an instance of, are singletons, so it's not even much of a problem, however, does anyone else have this obsessive anti-static dilemma, where they just want to get rid of everything that's static for the sake of object-oriented programming?
(Note: by the way, if anyone knows how to do these kinds of things without going static at all, that would be even better!)
|
|
|
|
|
The WindowProc needs to be static but that's it.
I try to find any way I can in callbacks to get a pointer passed in there. That pointer is always
a pointer to an object relevent to the callback. One cast, one call, and you're back in non-
static OOP land
It's no different with a windowproc - it's easy to add a pointer to an HWND.
I guess that's your method 2, except the GetInstance method IS the callback.
My 2 cents,
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Yes, there is a way to do that: register the pointer to your object (the this pointer) with SetWindowLong[^] (with the type GWL_USERDATA for the nIndex). Once your WndProc is called, you can retrieve your object pointer by calling GetWindowLong, cast it back to your class and you can call a specific non-static member function to handle the message.
|
|
|
|
|
Interesting, I'll give that a try.
Thanks.
|
|
|
|
|
The advice is good but you may run into a catch 22 when you call CreateWindow. Calls will be made to your WndProc before CreateWindows returns the HWnd to you for you to associate a pointer with. If you ignore those calls to WndProc because the HWnd passed doesn't have an associated pointer then window creation may actually fail and you'll never se your new window. A special case would seem to be required where if your WndProc recieves a call for an HWnd it knows nothing about. One option is to actaully create the Object at this point and do the association before processing the first message. I bet the first message you recieve won't be what you'd expect either 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I almost can not understand such problems:
I declare a variable first and do some thing after this (especially using atoi() and memset() function).When it gothrough it,the variable would change surpriing.
The CString variable would become NULL and the int variable would become 0.
I know I did not do any work to these surprisingly changed variable.
Why?
GOOD LUCK
|
|
|
|
|
What does the code look like? Is your memset count correct?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
yes.One condition is like this:
int curPlayer=12;
TCHAR Rools[12];
int index=0;
int temp;
TCHAR* q=Rools;
while(1)
{temp=5;
itoa(temp,q++,10);
if(index>=curPlayer)
break;
}
when the loop is brocken,the value of curPlayer became 0!
|
|
|
|
|
kcynic wrote: when the loop is brocken,the value of curPlayer became 0!
The way you've written the code, the loop will never exit in a controlled manner since the value of neither index nor curPlayer changes inside the loop.
The loop exits because the address space of the index variable will be overwritten in the call to itoa() when q points to that address space. Then index will get a value greater than curPlayer.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
I am sorry that ,I forgot the code:"++index;" in the loop.
|
|
|
|
|
kcynic wrote: I am sorry that ,I forgot the code:"++index;" in the loop.
Ok, so where do you want to put it? Like this:
int curPlayer = 12;
TCHAR Rools[12];
int index = 0;
int temp;
TCHAR* q = Rools;
while(1)
{
temp = 5;
itoa( temp, q++, 10 );
if( index >= curPlayer )
{
break;
}
++index;
}
Actually I mixed up the order of which the variables are located on the stack in my previous post. What happens is that curPlayer gets overwritten by itoa() with the terminating zero.
In the code above curPlayer will be overwritten when index equals 11.
You have basically made two errors:- You have an array with 12 elements which means that the highest index is 11 and you are deliberately accessing index 12, which is out of bounds. In C/C++ everything is zero-based so the first index is 0 and not 1.
- You haven't accounted for the fact that
itoa() adds a terminating zero to the target string after the conversion.
I suggest you debug the code and step through the loop while watching the memory window so you can see how the array contents change when itoa() is called.
If you increase the Rools array size to 13 you may find extra bytes allocated on the stack due to variable alignment between the Rools array and curPlayer. Those bytes shall never be accessed.
In my opinion you should use a for-loop instead of a "while-forever-loop". It will make more sense and it's also easier to read and understand what the code is supposed to do.
If you want a working example to compare with it could look like this:
int curPlayer = 11;
TCHAR Rools[12];
int index = 0;
int temp = 5;
TCHAR* q = Rools;
for( index = 0; index < curPlayer; ++index )
{
itoa( temp, q++, 10 );
}
Hope this helps
--
Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks,I do know what error happened in the codes,now.
And I would be more carefully in future.
BEST WISHES.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
