Xref: utzoo comp.sys.dec:3361 comp.os.vms:26409
Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!haven!uvaarpa!murdoch!news
From: sdm7g@dale.acc.Virginia.EDU (Steve D. Majewski)
Newsgroups: comp.sys.dec,comp.os.vms,uva.vms
Subject: VMS4.5 CRTL fstat does not free() malloc()ed memory (apparently)
Keywords: fstat malloc free VAXCRTL memory
Message-ID: <1990Jun6.233823.16060@murdoch.acc.Virginia.EDU>
Date: 6 Jun 90 23:38:23 GMT
Sender: news@murdoch.acc.Virginia.EDU
Followup-To: sdm7g@virginia.edu
Organization: University of Virginia
Lines: 57


  ** (apparent) PROBLEM WITH VMS (4.5) CRTL routine fstat() not free()ing
  malloc()ed memory. 

  Since VMS does not have UNIX-y things like "tee file" to fork the output 
  to stdout & file, and I got tired of duplicating: 
	fprintf( stdout, ... );
	fprintf( stderr, ... );
  for all of the information that I wanted both on-screen and in a log-file,
  I wrote a routine: stdprintf( same args as fprintf ), which prints to 
  (one, two, or all ) of ( stdout, stderr, & file ) - checking first that 
  they are not the same file ( as defined as having the same inode number ).

  ( OK - maybe this was overkill: I could have just made it duplicate output
    to stdout & stderr,  but I thought I might as well write a nice generalized
    utility routine ..., etc. ) 

  The routine calls fstat to get the inodes ( or in VMS: FID's ). The
  terminal & _NLA0: ( and probably  other non-file devices ) are all 
  FID(0,0,0), but that's OK as a restriction. It will do what I want
  in most cases. ( MailBox:'s probably return the same. How about tape
  file ? ) 

  Basically, it works fine, except when I actually used it in my 30 hour data
  acquisition program,  it dies after logging ~2000 points.  First I get a 
  "PAGE FILE FRAGMENTED" message on the console and eventually it dies with an
  access violation.  Debugging at this stage is like molasses of course ! 

  It appears that memory is being allocated and not being deallocated, and 
  things seem to point to those fstat calls.  I can see the virtual page 
  count grow with "show proc /cont". fstat DOES call malloc, but I have been
  unable to confirm more that that. 

  *Q1) Can anyone confirm that "fstat" is in fact the culprit ?
  *Q2) Is this feature removed in a leter version of VMS/CRTL/fstat ? 

  I suppose that the OTHER way of doing something like this in VMS would be 
  a process that reads its mailbox ( or pipe ) and forks it's output to 
  a file & stdout. The VMS-ese equivalent ( of UNIX: 
  "program args | tee file | more ") would be something like:
  "TEE file Program-to-spawn [ and it's args ... ]"
  *Q3) Has anyone done this ? *Q4) Does anyone have a suggestion ? 

  And a somewhat unrelated question: You can go from *FILE to (int)
  file-descriptor with fileno(). (How) Can you do the reverse ? 
  ( and can you map either of the above to RMS $FAB's without doing
    a RMS$OPEN ? )

  *** NOTE: system is VMS 4.5, VaxStationII, 3MB memory. 
  Since starting to write this note, I'm running a test with my 
  same_file() routine always returning TRUE & the fstat calls commented out.
  It got past 4000 points without dieing so far, so I'm willing to 
  believe the initial diagnosis. The immediate fix if to probably 
  keep a static table of inodes/FIDs and only call fstat ONCE per file.
                                                                       
  - Steve Majewski  / UVA Physiology
  sdm7g@virginia.edu