Possible reason for error code 75 (no locks available)

[zinal]

Hello and have a good time of day!

I'm trying to resolve a problem which seems to be a sort of system misconfiguration (although I'm not sure).

On our Integrity server (rx2660, if that matters) running OpenVMS V8.4 I tried to work with a ported SQLite library. Everything works fine, except that POSIX range locking fails to work. The very first call to fcntl(... F_SETFL ...) which tries to set a shared single-byte lock returns (-1) and errno is set to 75 (no locks available, according to strerror()).

I tried to reproduce the problem in a smaller example, but it just worked fine with no errors.

I also posted a message to VMS programming forum, and got the answer that a patched SQLite works (including POSIX locking part) on OpenVMS V8.3/Alpha.

So now I think we have a system configuration problem. I tried to read the documentation, to google on that topic - no ideas. I checked the resource limits - they are relatively high, see the output from SH PROC/ALL:

$ sh proc/all 

20-NOV-2012 22:57:41.62   User: ZINAL            Process ID:   000D691F
                          Node: DATUM            Process name: "ZINAL"

Terminal:           TNA29:  (Host: box.srv.tver.pg Port: 55491)
User Identifier:    [DBA,ZINAL]
Base priority:      4
Default file spec:  DATUM$DKB0:[USERS.ZINAL]
Number of Kthreads: 1 (System-wide limit: 2)

Devices allocated:  TNA29:

Process Quotas:
 Account name:         
 CPU limit:                      Infinite  Direct I/O limit:       150
 Buffered I/O byte count quota:    749808  Buffered I/O limit:     150
 Timer queue entry quota:             100  Open file quota:        250
 Paging file quota:               1492272  Subprocess quota:        10
 Default page fault cluster:           64  AST quota:              298
 Enqueue quota:                     16000  Shared file limit:        0
 Max detached processes:                0  Max active jobs:          0

Accounting information:
 Buffered I/O count:       105  Peak working set size:       4512
 Direct I/O count:          22  Peak virtual size:         177824
 Page faults:              371  Mounted volumes:                0
 Images activated:           2
 Elapsed CPU time:          0 00:00:00.03
 Connect time:              0 00:14:27.46
 
Authorized privileges:
 NETMBX       TMPMBX
 
Process privileges:
 NETMBX               may create network device
 TMPMBX               may create temporary mailbox
 
Process rights:
 ZINAL                             resource
 INTERACTIVE                       
 REMOTE                            
 ORA_DBA                           
 
System rights:
 SYS$NODE_DATUM                    
 
Auto-unshelve: on
 
Image Dump: off
 
Soft CPU Affinity: off
 
Parse Style: Traditional
 
Case Lookup: Blind
 
Symlink search mode: No wildcard
 
Units: Blocks
 
Token Size: Traditional
 
Home RAD: 0
 
Scheduling class name: none

Process Dynamic Memory Area  
  Current Size (KB)               528.00   Current Size (Pagelets)      1056
  Free Space (KB)                 503.96   Space in Use (KB)           24.03
  Largest Var Block (KB)          496.00   Smallest Var Block (bytes)    112
  Number of Free Blocks                4   Free Blocks LEQU 64 bytes       0

There is 1 process in this job: 

  ZINAL (*)

So - does anyone know any possible reason for errno 75 (no locks available) and what can be done against it? Any help will be appreciated.

Best regards,

  Maxim Zinal

[H.Becker]

I would start with a second VMS session and a SHOW PROCESS /CONTINUOUS to watch the status, quota and virtual address space of the SQLite process. HELP SHOW PROCESS /CONTINUOUS explains how to do that. I assume that file range locking within the CRTL uses some memory and the usual resources $ENQ needs: ENQ and AST quota.

>>> I tried to work with a ported SQLite library

Is this comparable to the shell/sqlite3 test on Alpha? Or do you have an own main image linked with the SQLite object/-library or a shareable image? How big in virtual address space is the application, which "works with SQLite"? Other than the above show command, for the main and/or the shareable image an output of analyze/image should give a rough estimation. Images on I64 are bigger than on Alpha. If your main allocates much memory and/or SQLite allocates much (to map the DB or parts of it - what do I know about DBs) you may run out of VA space. The test on Alpha didn't use much resources but that simple test may be totally different from what you are trying to do. 

>>> The very first call to fcntl

You have the sources and SQLite tracing enabled, so you can set a breakpoint to the trace routine and try to debug or try to get a process dump (see set process/dump=now and analyze/crash <process-dump>