Article View: comp.sys.dec
Article #1604VMS4.5 CRTL fstat does not free() malloc()ed memory (apparently)
From: Steve D. Majewski
Date: Wed, 06 Jun 1990 23:38
Date: Wed, 06 Jun 1990 23:38
57 lines
3493 bytes
3493 bytes
** (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
Technical Details
Message-ID:
<1990Jun6.233823.16060@murdoch.acc.Virginia.EDU>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!haven!uvaarpa!murdoch!newsShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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