|
That looks like you're trying to use an uninitialised object of some sort.
And you only ever use delete when:
- you've newed an object
- the API you're using says you delete objects it supplies
In both cases use a pointer class to manage your memory though to reduce the complexity of your code.
Cheers,
Ash
|
|
|
|
|
Aescleal wrote: In both cases use a pointer class to manage your memory though to reduce the complexity of your code.
Can you please be a little bit exact on what I should do?
|
|
|
|
|
T.RATHA KRISHNAN wrote: Should I delete gui::IGUISkin* skin?
Normally not but you have to check what is said in the documentation.
But anyway, it seems the problem is elsewhere: did you use your debugger to see if device was created properly ? Check also the return of getGUIEnvironment and the return of createSkin.
|
|
|
|
|
T.RATHA KRISHNAN wrote: gui::IGUISkin* skin = device->getGUIEnvironment()->createSkin(EGUI_SKIN_TYPE::EGST_WINDOWS_METALLIC);
How CreateSkin internally creating the object!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
what is data Serialization in MFC framework
|
|
|
|
|
Instead of writing a long description here, I suggest you take a look at this article[^] (it's part of a series of 3 articles that fully cover the subject).
|
|
|
|
|
In addition to Cédric reply, you may have a look at official documentation too "Serialization in MFC"[^] (if I remember well, isn't bad).
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 all,
i m working on MFC SDI type application,when i change my DPI Settings to 120 than all application forms looks bigger than its actual size but all are properly displayed here,scrollbar is display if form is looks more bigger.
my problem is that when i saw a print preview and here Zoom the view at its maximum point and than close the print preview window now the form is display more bigger and controls are not properly displayed here.
please help me what can i do here.
thanks in advance.
|
|
|
|
|
Maybe your GDI mapping mode got changed from MM_TEXT to something else during print preview. I noticed when I used Visual Studio 2010 project generator and specified a CFormView-based class, it warned me that the printing would automatically be disabled, so there must be some funky incompatiilbity in there. I do not know what the real problem is, but based upon how you said things got all wierd, the mapping mode would be my first guess.
|
|
|
|
|
What's the latest best approach to finding memory leaks in unmanaged C++ MFC code? I've read about LeakDiag but the latest version of that is a bit old (which leads me to guessing its not maintained anymore).
I have a case where I get persistent memory growth after an operation. I do the operation which loads a bunch of data, then I free it all, and at the end my memory usage is up a bit from where it was before I loaded the data. I'm looking at Private Bytes and Working Set in Process Explorer and my app uses directly the Windows Heap APIs as well as CRT new/delete for allocating/freeing memory.
I ran in the debugger (I'm using VS2005) and it didn't complain about any leaks as it sometimes does when you have leaks.
|
|
|
|
|
Sorry i can't answer your actual question, since i don't know what cool memory leak detection ways there are but i not so long ago we ran into some memory-fragmentation problems with our projects and we had to dig a bit deeper into memory management to cope with it and we leartn a few new things.
You might be experiencing slight memory usage increase because -as far as i know- CRT doesn't always "physically" free up memory when you call delete/free, it preserves some amount so it can quickly reuse it when new allocations are needed, i think it mostly does that for smaller allocations because it is more efficient that way, am not sure how you could test if this is the case or not though...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I thought that too, but I wrote a small test app which did a bunch of new ops then, when requested, freed them all.
What I noticed was that (when viewing these columns in Process Explorer) the virtual size never dropped back down. It just stayed where it was after all the new calls. But, the private bytes and working set did drop right back down after freeing the memory. And its these 2 columns where I'm seeing the persistent growth.
I check the memory usage, then load the data, the free it all, then check again and repeat this multiple times with the same instance of the app. Each time I get a growth in those columns.
|
|
|
|
|
|
About Visual Leak Detector, you'd better try the most recent versions @ codeplex : http://vld.codeplex.com/
(pre-emptive WTF, the clicky thing stopped working in Safari?!?!)
Watched code never compiles.
|
|
|
|
|
Thanks for the links! I'll take a look at those.
|
|
|
|
|
The best approach isn't to leak any memory, then you don't have any leaks to find. So instead of using raw pointers use a wrapped pointer of some sort, instead of dynamically allocated arrays use std::vector. The moral is if you don't manually manage it you can't leak it.
Cheers,
Ash
|
|
|
|
|
of course
|
|
|
|
|
Aescleal wrote: The moral is if you don't manually manage it you can't leak it.
Where's the fun, then (OK I didn't notice it was a 'moral'...).
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]
|
|
|
|
|
You can also try Microsoft's Application Verifier.
|
|
|
|
|
Maybe I need to look at that again too. Thanks!
|
|
|
|
|
The built-in detection mechanisms of the VS work very well for me ie., define new to DEBUG_NEW and so on. When you stop your application it will tell you where the leaks are if you do this.
But, as others have said, the heap manager does not always release unused memory back to the OS. It tries to reuse the free blocks but sometimes memory gets fragmented and it has to allocate more to get a contiguous block of the needed size. You can 'manually' force it to release the memory back to the OS by calling _heapmin().
|
|
|
|
|
I've successfully used the built-in VS leak stuff with DEBUG_NEW, etc in the past. For this, though, its not reporting any leaks. However, when I load a file, then do file>>new and dispose of everything, then repeat the process, I see a roughly constant growth each time. I'm looking at the process private bytes counter.
I wrote a small test app which does HeapCreate/HeapAlloc/HeapFree/HeapDestroy and also new/delete. In either case, when I allocate a bunch of memory and then free it the private bytes immediately drops back down. Whereas in my app I get this persistent repeatable growth each time, yet the VS leak detection isn't kicking in.
I'm not at all concerned about memory being released back to the OS. If the heap manager is holding onto it after my app has freed it (HeapFree/delete) that's acceptable and its an OS issue. I'm worried about cases where I've allocated and not freed the memory myself (regardless of whether or not its been returned to the OS).
|
|
|
|
|
We use Memory Validator here at work and it is fairly awesome.
It will show where both the growth and leaks are occuring, assuming you generate proper PDB files for your project.
|
|
|
|
|
I'll take a look at that. Thanks!
|
|
|
|
|
Hello all,
I hooked NtSetInformationFile to intercept delete call, This is done, Now i have a file which contains name of files and folder need to be protected, Protecting file is no problem as i get the file name from file handle and using strcmp i decide whether to delete the file or not, But how to determine that the file handle i get in NtSetInformationFile is folder?
I tried using GetFileInformationByHandleEx with FileStandardInfo which should give me whether the handle is directory or not, But it always returns TRUE(folder) when there are no files inside and FALSE(not folder) when there are files inside.
Thanks all.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
