![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Has the DOORS memory leak issue been fixed? Will it ever be fixed? Topic Summary: A Request for a function to release memory without closing DOORS Created On: 23-May-2005 21:57 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Has the DOORS memory leak issue been fixed? Is there a function to release the memory used by the string table? or from using RegExp? Will this ever be fixed?
![]() ------------------------- Bruce Tuskey Sr. Principle Engineer Tuskey@gmail.com "All that is gold does not glitter, not all those who wander are lost:..." - Gandalf the Grey (JRR Tolkien) Edited: 13-Apr-2006 at 21:47 by Bruce Tuskey |
|
![]() |
|
![]() |
|
Easy way is to shut-down the client
![]() Actually, I am using DOORS 7.1 here, and with some of my large scripts I will purposely shut-down the client and restart it again w/DXL to avoid the memory issue. As far as I know (and experience) DOORS is still a memory hog. ------------------------- pete.kowalski(at)motorola.com Edited: 23-May-2005 at 22:29 by Pete Kowalski |
|
![]() |
|
![]() |
|
That is the same way we have to deal with it. We get allot of complaints about it though.
------------------------- Bruce Tuskey Sr. Principle Engineer Tuskey@gmail.com "All that is gold does not glitter, not all those who wander are lost:..." - Gandalf the Grey (JRR Tolkien) |
|
![]() |
|
![]() |
|
Has anyone noticed that minimising the explorer window "seems" to release memory?
Open windows task manager and start doors. Run a script that eats up memory and watch the memory consumption increase. Note that memory is not released when the script terminates. Now minimise the doors explorer window, don't close doors. Notice that memory use reported by task manager is reduced. ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
Do what? You've got DXL that knows its a hog and will initiate a new client and close DOORS?
Was practicing with techniques to reduce memory leak. I finally came across the buffer extract technique: if (bufSubString == bufFullString[i:i+sizeof(bufSubString)-1]), since that's advertised to not use the string table. Yup, that's true: running that thousands of times didn't expand memory use. But the DXL slowed down linerally with the number of loops. The first 10k loops may take 2 seconds wherease the 8th 10k loop took perhaps 20 seconds. Very curious. Even more curious was that every now and then the speed would reduce before increasing again: the 4th may take 8secs, the 5th take 12secs, the 6th take 3secs, the 7th take 5secs. I took this to mean that DXL has some sort of clean up function. Sent the reproduction script to Telelogic. They confirmed my observation but (of course) had nothing to say. Anyway, I concluded that I was better off with a little memory leak instead of this feature, at least for this library function that finds the offset of a string within a bigger string. - Louie BTW, RegExp searches proved to be extremely inefficient, especially when the search string is dynamic which means its got to be conferted to a ReqExp before use. |
|
![]() |
|
![]() |
|
Hi All,
it seems really difficult to deal with memory leak problem! I got a function named memoryIsLow() without documentation (I forget how did I get it!). From name, it can assume that it will return true if the memory is low. But seems its not working! So, now problem is - we are exporting bunch of embedded OLEs and the script is running approx 2 hrs (exported 250 OLEs) and then crashed for memory problem (although we have 1GB RAM + additional increased virtual memory).... If some how we can reduce the memory leak then we can finish the process. By the way, even DOORS 7.1 standard word exporter also faces the same memory problem. If we can have something following then I think we can handle the memory problem: //Check memory is low or not if (memoryIsLow()) { releaseMemory() Or, freeUpMemory() Or, garbageCollection() etc etc. } Is it possible that telelogic provide us some work around? Is there any documentation that how many OLEs we can export? or, how many OLEs we can put into the DOORS module (or, the file size)? Many greetings to all... Rony =================== Iftakher Uddin (Rony) Iftakher.Uddin@HOOD-Group.com |
|
![]() |
|
![]() |
|
We have some scripts that do the same, it's a real pain though
------------------------- Graham Stradling, Alcatel-Lucent. |
|
![]() |
|
![]() |
|
Wow, that's pretty cool. So is there a way to minimize the window through DXL or OLE or IPC?
------------------------- Shawn Stepper shawn.e.stepper@wellsfargo.com |
|
![]() |
|
![]() |
|
quote: "Do the same"... 1. Export bunch of OLEs or 2. Cleanup memory :-) Rony =================== Iftakher Uddin (Rony) Iftakher.Uddin@HOOD-Group.com |
|
![]() |
|
![]() |
|
I was tempted to try two techniques: [1] bundle up a memory hog utility and fire it off with "eval_". [2] Coordinate a large bundle of memory-hog DXL and fire it off using Windows Scheduled Tasks: perhaps the main program deals with a bunch of modules but schedules tasks that log into DOORS and deals only with one such module. The main program would need to wait for the Scheduled task to finish and I didn't think I'd have any trouble figuring that part out. [2a] would feature a main program that in advance planned the sequence of tasks and fired off the first one. Each such schedule task, right before it ended, would check the list and if there were remaining tasks reschedule itself.
I suspected that [1] would not work (probably "eval_" memory table coexists with the main programs), but [2] of course would. - Louie |
|
![]() |
|
![]() |
|
Hi Louie,
could you please explain bit more about "large bundle of memory-hog DXL"? Last week, I tried to get some third party software which can reduce the unused memory... but didnt get a suitable one. Do you know one? Greetings, Rony =================== Iftakher Uddin (Rony) Iftakher.Uddin@HOOD-Group.com |
|
![]() |
|
![]() |
|
I was replying to Tony's post, so we have scripts that monitor memory, we actually completely close down DOORS and then re-start the script from the point at which it was halted. It's a shame we have to go to these lengths
![]() ------------------------- Graham Stradling, Alcatel-Lucent. |
|
![]() |
|
![]() |
|
Lets suppose your script plows through all the modules of a project, and for each module does a huge chunk of string stuff, like looking for sub-strings. You could theoretically bundle the "FindStringInModule" function that performs just for a single module, and find a way to fire it off with the Scheduler or some other method. The main would wait for each module to finish, gather its results, then fire off the next module.
Perhaps instead of "large bundle" I should have said "many small" memory-hog DXL functions. I'm not system savy enough to even think of looking for a 3rd party tool. I don't think such tools can reduce wasted space within an application; ones's I've heard of figure out if the operating system has accidentally marked memory "in use" when there is no application using it, and then "reclaims" it. That's a completely different issue since DOORS is in fact "using" all this virtual memory, even if it doesn't know how to reclaim it. - Louie |
|
![]() |
|
![]() |
|
Another technique I discovered on my own is simply this.
Find a free memory utility such as http://www.yourwaresolutions.c...ftware.html#framxpro. Run the utility before you run DOORS and afterwards run it again. This helps my team a bit when we have to run "large" scripts against our "big" database. On a side note, DOORS 8.1 still has these memory leaks. I don't have any metrics yet if these memory leaks have gotten worser or better yet. ------------------------- pete.kowalski(at)motorola.com |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.