Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

File locking exhausts PGFLQUOTA

SOLVED
Go to solution
Stehlik Tomas
Occasional Contributor

File locking exhausts PGFLQUOTA

Hi all,

Attached test program just locks 1 byte in file for read then escalate this lock for read-write than again lower it from exclusive to shared access and finally unlock it. If it runs in loop it allocate memory pretty fast increasing VIRTUALPAGECNT until exhaust PGFLQUOTA.

Documentation for fcntl says:
â All locks associated with a file for a given process are removed when a file descriptor for that file is closed by that processâ

http://www.openvms.compaq.com/doc/83final/5763/5763pro_033.html#index_x_888

It happens on IA64 OpenVMS with last patches.
Is problem in this test or system?
5 REPLIES
H.Becker
Honored Contributor

Re: File locking exhausts PGFLQUOTA

Your test looks fine to me. The documentation only talks about the locks being removed. It doesn't say anything about memory being used.. In that sense the documenation seems OK. But it looks like a sub-optimal behavior, which is either a bug or seems worth to be documented as a (current/temporary/???) limitiation.
John Gillings
Honored Contributor

Re: File locking exhausts PGFLQUOTA

This needs more investigation before calling it a bug. Memory depletion can be a leak, or it can be due to usage pattern pathology, like checkerboarding.

I'm not familiar with the C++ locking interface, so I don't know the expected lifecycle of the structures involved - perhaps there's some kind of "Free" operation? What happens if you remove the F_UNLCK? Can you keep bouncing between F_RDLCK and F_WRLCK forever? Is there a null lock mode? (ie the lock still exists, but it doesn't block any other lock mode).

Try adding calls to LIB$STAT_VM to see if there's a pattern of depletion. Try sampling all statistics at the bottom of each loop. Output a timestamp, and a comma separated list of statistics, including loop counters for both loops (i and j). Give it a T4 header, and you can examine the timeline of VM usage.

If you want finer detail, use FAKE_RTL to trace all calls into VM routines. This will tell you if there's a genuine leak, or some VM usage pathology.
A crucible of informative mistakes
H.Becker
Honored Contributor
Solution

Re: File locking exhausts PGFLQUOTA

>>>
This needs more investigation before calling it a bug.
<<<

True. Given the simple source and the fact that it does work as expected on other systems, for example Linux, the investigation should be done by HP.

The byte range locking (aka file locking) is defined in the X/Open standard. It is (more or less) new to the VMS CRTL. The source code (although it has the type cpp) is plain C. There are no user-allocated/-controlled data structures on the heap involved.



Stehlik Tomas
Occasional Contributor

Re: File locking exhausts PGFLQUOTA

Heap Analyzer shows that changing lock level on the same offset and range allocates another memory SYS$EXPREG. Why it is not just reused?

In the mean time I found workaround to use in pairs for each lock also unlock not just to change lock level.

I start to investigate this while using Sqlite ported to OpenVMS where they for UNIX code branch that is used also for VMS just escalate and again lover locking level.
JagadishM
Occasional Advisor

Re: File locking exhausts PGFLQUOTA

Hello,

This looks like an OpenVMS CRTL issue, and requires future investigation.

Please open a QUIX case with HP, with decc$shr.exe image information.

Thank you,
Jagadish M.