![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Memory Leaks & Large Dialog Boxes Topic Summary: Created On: 5-Jun-2008 18:19 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I have a very large dialog box I've been developing for a long time. It really is more of an alternate user interface to DOORS. It's 130 DBEs and growing.
Through earlier posts, discussions and suggestions, I've managed to do a fairly good job of organizing the code for all the DBEs, placement, callbacks, user-built functions, etc. However, a newer problem I'm having is the dreaded memory leaks. I've read all the posts I can find on the issue. Many suggestions are to delete Skip lists, use buffers instead of strings, etc. To my knowledge, I've done this the best I can. The problem seems to be, the longer my dialog box runs, the more memory it uses (and the slower it gets). If I monitor the Windows Task Manager and the doors.exe "Mem Usage", I can see that the allocated memory continues to increase as buttons are pushed, callbacks are called, etc. The allocated memory never goes down, until the dialog box is closed. My concern is, even if I delete Skip lists as appropriate, use buffers where I can, etc., it seems that memory is not actually released until the dialog box is closed (i.e., the dialog box script actually ends). Can anyone confirm this behavior? |
|
![]() |
|
![]() |
|
Hi David,
From my experience so far I would say that the release of memory does take place immediately, and does not wait for the dialog box to be closed. However, sometimes you have to be very careful if you delete things, e.g. if you have created a Skip list with buffer values. In this case, simply deleting the Skip list does not release the memory, instead you must first loop through the Skip list and delete the buffer values before you delete the Skip list. The same is true for DxlObjects etc. On a lower scale, even "normal" Skip lists do not fully release all memory if the "delete myList" command is not followed by a "myList = null". I have attached a small script which uses the "tasklist" system command under Windows to get the memory currently used by DOORS. If you place it before and after the deletion of your variables, you can check if the release of memory actually was successful. But note that the script is _very_ slow, at least on my machine it takes several seconds before returning the value. But it is still very helpful for debugging memory leaks, as you don't have to watch the Task manager all the time any more. Cheers, Peter Edited: 6-Jun-2008 at 08:29 by Peter Albert |
|
![]() |
|
![]() |
|
Hi Peter,
Thanks for the myList = null tip. I didn't think about that. I usually only set dialog boxes to null after they're closed. To David, I have some fairly large dialog box scripts (70ish DBEs) and while I do notice memory being consumed, I haven't had really any slow down. I've sort of done the same thing as you though with trying to give an alternative UI for some modules in DOORS. Especially recently where we have a program that requires us to work in read only mode. So I wrote tools to let people add and edit objects in read only, and when they submit the tool handles the locking of the module/object. Part of this is because you cannot set a new object for share in shared edit mode, even one created underneath a locked section. It's working quite well so far. The only thing a tad cumbersome right now is creating links but I plan to improve it. ------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
|
![]() |
|
![]() |
|
Another suggestion that I frequently follow is that I release the memory held by the dialog box itself. For example, if I have a DB named box that is no longer needed, I'll use code like this:
|
|
![]() |
|
![]() |
|
Thanks for the ideas. I think my problem revolves around not properly deleting Skip lists. I will try the skipList = null idea.
I have some functions that will fetch some data from a module and return it in a Skip list. Then I have other functions that take those Skip lists and populate them into listViews, choices, and/or text fields. So I have something like... Skip getSkipList() { Skip tempSkip = create // get some stuff, populate the skip list return tempSkip } void populateListView(DBE xListView) { Skip popSkip = getSkipList() String temp int i = 0 for temp in popSkip do { insert(xListView,i,temp) i++ } delete popSkip } I think part of the problem is, even though I delete "popSkip" in the 2nd function, I am not sure the memory is relased for "tempSkip" from the 1st function. |
|
![]() |
|
![]() |
|
Tweaked your code. Instead of finding the first process named 'doors.exe' it displays a temporary dialog box, then finds the process that's displaying that window. This should, I believe, find the current DOORS process in the case that there's two DOORS running on the same client; except in the very unlikely case that both DOORS are running the same function.
Am curious about what you think of it. - Louie |
|
![]() |
|
![]() |
|
Hi Louie,
I like your idea, but I disliked the dialogue box popping up again and again. I therefore modified the code again and am using your idea in the first call in order to get the process ID. In subsequent calls, I am just filtering tasklist for this PID. Regards, Peter |
|
![]() |
|
![]() |
|
Very nice. Now we just convert the result into an integer (in K-pages) and we might have something useful.
That useful might be my 'fResidual' functions intended to periodically close residually open invisible-read modules when memory gets low, as such modules get opened when your script polls lots of modules and lots of linked modules, it being hard to keep track of what to close when. - Louie |
|
![]() |
|
![]() |
|
Good point. This version has an 'int fMemoryUsage()' perm which returns the K-pages used by Doors. I also put back in the original version using the "imagename eq "doors.exe" filter for tasklist in case Doors is running in batch mode and therefore Dialogue boxes can't be created.
Peter Edited code following Louies next comment, perm now really return kBytes, not Mbytes Edited following Roy's observation that GB usage is not properly reported (updated regular expression) Edited: 9-Jan-2009 at 14:30 by Peter Albert |
|
![]() |
|
![]() |
|
The tasklist command already returns the 'K'b pages. Your int function seems to return the 'M'b pages. Perhaps you can take "57,565 K" and strip out all the commas and the ' K' leaving "57565", then take the intOf that.
|
|
![]() |
|
![]() |
|
True, it returned MBytes. I changed the code in the previous post.
Peter |
|
![]() |
|
![]() |
|
I have been using this script to monitor memory usage in some big hairy scripts, and have seen that when memory usage goes above 1GB that the returned value is incorrect. Any chance of a fix?
Thanks, Roy. |
|
![]() |
|
![]() |
|
I would like to test this, but my PC refuses to give me more than 1GB of memory...
Could you please tell me what the task manager shows in such a case? It is probably just that it does not report kB anymore but MB instead, in which case the regular expression in the script fails. This is easy to fix, but I'd need confirmation about what the task manager shows, first. Peter |
|
![]() |
|
![]() |
|
I have just run my scripts again, and currently the Process List in the Task Manager is showing doors.exe with a Mem Usage of "1,006,768 K" and the script is returning "006,768 K"
I too suspect it's a problem with the Regular Expression, but I have to admit I've no real experience (and so no real success) with the darn things... Roy |
|
![]() |
|
![]() |
|
Thanks for the info, I have updated the regular expression in the code in the above post. It now matches multiple commas.
Regards, Peter |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Memory Leaks & Large Dialog Boxes
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.