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

Conference clt::rtl

Title:OpenVMS Run-Time Libraries
Notice:Routines documented in the Run-Time Library volumes covered here
Moderator:LOWFAT::DIETER
Created:Sat Jan 25 1986
Last Modified:Wed May 28 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:966
Total number of notes:4598

966.0. "lib$sys_trnlog memory leak?" by CSC32::J_HENSON (Don't get even, get ahead!) Tue May 27 1997 16:12

I guess it's my turn to ask about lib$sys_trnlog.  

A customer who just upgraded to OpenVMS Alpha V7.1 is claiming that
there is a memory leak with lib$sys_trnlog.  I haven't yet verified
the claim, but have decided to take some pro-active steps in case
he's right.

If there really is a memory leak with this RTL function, is there
anything that I can do about it?  If I SPR/QAR it, what happens?
Will it be ignored because it is based on an obsolete system
service, or will we try to fix it.

Jerry
T.RTitleUserPersonal
Name
DateLines
966.1QUARK::LIONELFree advice is worth every centTue May 27 1997 17:407
Just because it is obsolete, that doesn't mean it's unsupported.

I haven't looked at the source for this routine, but I would first check to
see if the user's program passes a dynamic string and if so, what they do
with it afterwards.

				Steve
966.2lib$sys_trnlog fails to release its dynamic descriptorCSC64::BLAYLOCKIf at first you doubt,doubt again.Tue May 27 1997 18:0251
The customer is correct.  There is a memory leak in the
Alpha version of the code (not on VAX).  It's a new bug
for V7 of OpenVMS Alpha so someone should hopefully fix it.

Just because it is obsolete does not mean it should not
work correctly.


C $ type test.c

#include <stdio.h>
#include <unistd.h>
#include <lib$routines.h>
#include <str$routines.h>
#include <descrip.h>

main( )
{
    $DESCRIPTOR(sysout, "SYS$OUTPUT") ;
    struct dsc$descriptor outd = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_D, 0} ;

    for(;;) {
        lib$show_vm(0, 0, 0) ;
        lib$sys_trnlog(&sysout, 0, &outd) ;
        lib$show_vm(0, 0, 0) ;
        str$free1_dx(&outd) ;
        lib$show_vm(0, 0, 0) ;
        sleep(1) ;
    }
}
C $ run test
 2 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 0 bytes still allocated
 3 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 56 bytes still allocated
 3 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 24 bytes still allocated
 3 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 24 bytes still allocated
 4 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 80 bytes still allocated
 4 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 48 bytes still allocated
 4 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 48 bytes still allocated
 5 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 104 bytes still allocated
 5 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 72 bytes still allocated
 5 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 72 bytes still allocated
 6 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 128 bytes still allocated
 6 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 96 bytes still allocated
 6 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 96 bytes still allocated
 7 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 152 bytes still allocated
 7 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 120 bytes still allocated
 7 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 120 bytes still allocated
 8 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 176 bytes still allocated
 8 calls to LIB$GET_VM, 0 calls to LIB$FREE_VM, 144 bytes still allocated
...
966.3SSPADE::GRECOWed May 28 1997 12:525
    Yes, we were made aware of this memory leak in lib$sys_trnlog a
    few months back and plan to fix it for V7.2.  I think it has been
    a problem for a while and not just in V7.1.
    
    Frank