|
From Task Manager there is already an indication that memory is being consumed, so any suggestions what should be monitored by PerfMon? I've been studying the options this morning. None of them look promising.
Is there something else in Task Manager to check? For instance, when looking at the process list I see the app is using more memory than before, but not nearly as much more as the overall change in memory. The last time I stopped the stand-alone app, Task Manager also showed memory being released gradually instead of all at once. What do these symptoms indicate?
Details if you're interested:
The UI is very simple. Text is either output to a CListBox of limited size which is displayed by the View, or the status bar text is changed. Every few hours the window's caption is changed.
Once every 12 hours a second process is launched which takes about 30 minutes to complete. During this process is the only period when there are multiple timers running.
>>>-----> MikeO
|
|
|
|
|
Mike Osbahr wrote:
when looking at the process list I see the app is using more memory than before, but not nearly as much more as the overall change in memory.
Then it's a handle leak.
Mike Osbahr wrote:
The last time I stopped the stand-alone app, Task Manager also showed memory being released gradually instead of all at once. What do these symptoms indicate?
That you have a lot (a lot) of objects that gets cleaned up at destruction. Are you putting some objects in some container?
Once every 12 hours a second process is launched which takes about 30 minutes to complete. During this process is the only period when there are multiple timers running.
Are your app launching this process? Is it using CreateProcess? You are closing both the process and the thread handle?
|
|
|
|
|
Hi Friend
I am sure you allocate some memeory within your program and u forget to release them properly..so the program allocated memory when it runs...take a close look upon you code..lile new and malloc() or such functions.find it out..!!!
oK??
Trace The Bugs...
|
|
|
|
|
R_Renjith wrote:
I am sure you allocate some memeory within your program and u forget to release them properly..so the program allocated memory when it runs...take a close look upon you code..lile new and malloc() or such
These were the first things that crossed my mind also. I avoid malloc() whenever possible and in this particular app do not use it at all. Every new has a matching delete, though it may be possible that a delete is not being executed.
These types of leaks though usually show up in the output window of the debugger when you terminate. The functions I am using which bother me are GetStringSetBuffer() and ReleaseBuffer(). All of my debug tests indicate they are working properly, but they do allocate and deallocate memory. Any reason to suspect when running stand-alone these behave differently?
>>>-----> MikeO
|
|
|
|
|
From what you have described I have two ideas that might help you.
Check which optimizations you have enabled for the release build. Are you using MinSize or MaxSpeed? If I remember correctly there are a few nasty little bugs waiting to bite you if MinSize is selected. I have run into one before and the result was something similar to your problem.
One other thing that I have run into is a problem with loading DLL libraries dynamically (ala LoadLibrary/LoadLibraryEx). Make sure you are freeing the libraries in an approriate place. I had a situation where memory was being allocated in a DLL but not released before calling FreeLibrary. On Win9? this would leave the DLL in memory.
You might want to disable one at a time and see if you can uncover the problem.
|
|
|
|
|
For now, I am testing running the Debug build stand-alone. Are there any drawbacks to this? It was my understanding that TRACE messages just get dumped when there is no output window available. Other than that, I cannot think of anything in the program that might use memory differently in stand-alone.
>>>-----> MikeO
|
|
|
|
|
There are several problems with this approach.
1) You can't redistribute the debug libraries (MS license)
2) Performance will be much degrade. Amount of performance cost depends on what your program does.
3) ASSERT and VERIFY code is still being executed which can interfere with operation (especially when app is not monitored by a user.) This shouldn't really be too much of an issue if the code has been tested well.
|
|
|
|
|
The points you make about Debug vs. Release code are all valid. My question was with regard to the memory problem. Is there anything in a Debug release that will consume memory while running stand-alone?
The optimization headaches will come later. 
>>>-----> MikeO
|
|
|
|
|
Off the top of my head:
When you build an application with a debug build, the compiler inserts "dog tags" (small areas of memory used to verify the integrity of memory) around your memory and data structures and at runtime these dog-tags are pre-initizliaed with specific values. Then at runtime these dog-tag values are checked against the pre-initialized values. If they differ, you have overrun your memory. This obviously takes more memory depending on the size of your program. Also, MFC maintains a set of handle tables in memory and if I remember correctly, the debug build of MFC can produce very large handle tables. I think it delays the removal of handles from the table so that they can be checked against valid ones later.
When you stay "stand-alone" I assume you mean seperate from the IDE. As far as I know the only difference between a debug build running outside the IDE and one run through the debugger is the prescense of a debug machine which theoritically should not have any impact on your program.
|
|
|
|
|
Someone mentioned something that reminded me of something.
Are you executing any code in an ASSERT or TRACE. If so, this might need to be changed. The code inside of an ASSERT or TRACE isn't execute in release mode.
So things like:
ASSERT (SUCCEEDED (::CoTaskMemFree (pData)));
Wouldn't deallocate the memory in release mode.
The VERIFY macro does execute in release mode.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
That's a great point. Wish I had thought of that.
|
|
|
|
|
This one had not occurred to me. Just checked though and all of the ASSERTs are simple conditionals and the only thing in the TRACEs other than text are some .Format functions for displaying date/times.
As I mentioned to Matt, for testing only, I am running the Debug build of the app outside of the debugger. It has been tested to the point that no ASSERTs will kill it, but what does it do with the TRACE output?
I will see if a release build exhibits the same symptoms. It was my understanding testing the debug code stand-alone would give me a good shake-down before seeing if optimization introduced any problems.
>>>-----> MikeO
|
|
|
|
|
TRACE formats the text and then invokes a Debugger API. If no debugger is present, then nothing happens. The only question is how much time is wasted doing this.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
I'm using on VC6 the SetWindowPos function to set to wndTopMost style for a dialog, but not get the focus. In Win2k it works well, but on Win9x the dialog get the focus.
Anyone know how solve this problem ?
Thanks,
Cristiano ...
|
|
|
|
|
i had a similar problem. i am not sure way it did not work but seem bto be the way the dialog was created. my work around was to shift the x,y pos 1 pixel. this allowed the setwindowpos to work and setfocus.
|
|
|
|
|
Explaining better: I'm using SetWindowPos setting the position too. And is not wished that the dialog get the focus, I want set to TOPMOST style.
[]'s
Cristiano
|
|
|
|
|
if i understand correctly you wish to bring a child dialog to the top without setting focus to the child.
to do this you could use the SWP_NOACTIVATE flag. or you could use a comination of different flags to get the exact settings you require.
SWP_ASYNCWINDOWPOS
SWP_DEFERERASE
SWP_DRAWFRAME
SWP_FRAMECHANGED
SWP_HIDEWINDOW
SWP_NOACTIVATE
SWP_NOMOVE
SWP_NOOWNERZORDER
SWP_NOREDRAW
SWP_NOREPOSITION
SWP_NOSENDCHANGING
SWP_NOSIZE
SWP_NOZORDER
SWP_SHOWWINDOW
|
|
|
|
|
The have tried this ... but no sucess. The problem persist.
Any others solutions ?
[]'s
|
|
|
|
|
not really, but is the dialog modeless. if it is modal you would only have access to the new top level dialog.
sorry thats all i have.
|
|
|
|
|
I have two views in my application . One is Rich edit view and one is a simple edit view. They are both split by the splitter window in the mainframe class. But when I do some operations such as ctrl-x and ctrl-v in the edit view the appication crashes sighting some error in viewrich.cpp but the copying and cutting of the text works fine if I do it through the right click of the Mouse. Can anyone suggest some solution for it.
Samir Sood
|
|
|
|
|
i get this error if a user deletes a record and that record has a duplicate data in the file.
all records are unique though. i do have a time stamp and a userid field that will always create unique records. so the complete record is not duplicated.
the table that i am using is a VFP table with no index attached.
in my application i have no order set.
is there a way to trap this error, ignore and continue.
thank you.
|
|
|
|
|
Catch a CDBExeption object. If you don't know what I mean, lookup try in MSDN.
Good luck,
Bill
|
|
|
|
|
i have created a try/catch/throw handler. it allows me to trap the error with my own message and exit my loop. but what i need is a way to prevent the error from happening at all. is this possible?
actually i did not mention that i am using a crecordset that is setup as snapshot. this is the only way i could get a VFP database to work.
|
|
|
|
|
What is the actual error condition. Your original post didn't mention it. Are you trying to trap an error or avoid it? The difference definitely effects the answer.
Is the problem that the database is actually deleting multiple rows? If so, you can fix the problem(it is not really an error, just a coding mistake) by using more specific criteria in your SQL statements.
Good luck,
Bill
|
|
|
|
|
i have a list box that allows the user to mark items to be deleted.
on exit of the application i check the listbox and delete the records.
i have double checked and none of my records are duplicated. but i do have some logs that have duplicate core data(all but 3 fields the same). the error occurs on the delete function. i have tried a try/catch around the delete function and it will trap the error and exit me out of my loop, but that is not what i need. again i do not have a sort set on the records, my list box takes care of and sorting.
thank you
do{
retval = pCtrl->GetItemState(ckrec,LVIS_STATEIMAGEMASK);
if(retval == LVIS_SELECTED && !m_pSet->IsEOF()){
UpdateData(true);
m_pSet->SetAbsolutePosition(ckrec+1);
DeleteFile(Buffer);
m_pSet->Delete();
}
ckrec++;
}while(ckrec <= pCtrl->GetItemCount());
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
