[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

921.0. "Iconic map memory leak V1.1 " by GIDDAY::DRANSFIELD (Mike Dransfield, Sydney RSSG) Wed Apr 17 1991 04:27

    Has anyone else noticed a memory leak with MCC V1.1 SSB and the Iconic
    map PM?
    
    I think that I can reproduce this by starting up the iconic map
    interface, and selection a node and starting two show operations
    I selected a node4 object and did a show identifiers and a show
    counters.
    Then I set the time so that they repeated every 30 seconds and watched
    the process with SHOW PROCESS/CONT and the number of virtual pages
    increases every few minutes.
    
    It does NOT seem to happen if there is only one repeating show going
    on.
    
    I would just like someone else to confirm what I am seeing as I am
    developing an AM and want to make certain that it is not involved in 
    this memory leak.
    
    Thanks,
    Mike
T.RTitleUserPersonal
Name
DateLines
921.1If it were but so simple.TOOK::CALLANDERWed Apr 17 1991 20:0522
To do memory analysis in MCC it isn't as straight foward as doing a 
show process and watching the numbers go up. If you do the same thing
with the FCL you will also see the numbers go up. To understand things
you have to know that there is quite a bit of caching going on in 
the background. Until the cache is full of information it will continue
to grow. Depending upon the commands and their combinations you might
see the numbers go up for quite a while before they stabalize off.
Unluckily I am not the one to tell you if there are leaks in the map,
maybe some one from that team can tell you their results on that. What
I can tell you is that to do memory testing we use fake_vm. To do this
we turn on a numer of logicals that turn off the dictionary caches and
turn off the local mcc memory poll (another cache) and then test.

Another item to note, when you are running the iconic map a number of directives
are done on your behalf so some times it looks like you are doing only one 
thing when the map is doing more.

I know this is a bit unclear but memory management and testing in a large
environment is difficult (without the caches we would be even slower, but
we are working on that one all the time).

921.2I don't think its a caching effect..GIDDAY::DRANSFIELDMike Dransfield, Sydney RSSGThu Apr 18 1991 00:1120
    re: .1
    Thanks Jill. I did use fake_vm to find a leak in my own access module,
    but I failed miserably in getting it to work on the iconic map PM.
    When I moified do_test.com and then ran it, MCC accvio'd when I
    tried to close my show directive window. At that point, I gave up on
    trying to trace the problem any further and did a test with the PHASE
    IV AM.
    Since that also seems to have a leak, then I assume that the problem
    is either in the iconic map, or to do with threads.
    
    I don't think that I am seeing an effect of caching, as using my AM the
    process grew from 18,000 to 30,000 pages over 24 hours doing two show
    commands every thirty seconds.
    Using the phase IV AM doing two show commands every thirty seconds the
    process size has grown from 22512 pages to 24176 pages in 1 hour and 5
    minutes. I will leave it running overnight, but I fully expect it to be
    over 30,000 pages tomorrow.
    
    Thanks,
    Mike
921.3don't closeTOOK::HAOThu Apr 18 1991 11:539
    Mike,
    
    As you found out the hard way, you can't close anything (windows,
    cancelling boxes, etc) in the Iconic Map PM when using fake VM.
    If you want to use IMPM with fake VM, don't close anything until you're
    ready to quit.
    
    Christine
    
921.4in case anyone is interested...POLE::LEMMONThu May 02 1991 20:5811
    Fake VM writes a specific pattern to memory when it is freed.
    The XtDestroyWidget() routine sets a field in the widget
    indicating that it is to be destroyed and then frees the widget memory up.  
    XtIntrisics assumes that the delta time between the freeing of the
    memory and the next time it is accessed is so small that no other
    process will modify the contents of the widget memory.  
    
    This is why Fake VM causes the iconic map to accvio.  

    /Jim