The errors 3719, 5029 are raised when trying to release a latch for a different user, triggering an abnormal shutdown.
The message preceding 3719 provides the current owner, for example:
APPSRV24: (-----) latObjLatchFree: owner 23 of object latch 25 is not me (lockCnt: 29, addr: 0x6130800) latch stack: 1"
Some combinations of shared memory locks are not allowed (conflicts), before getting a mux or index lock. The Progress code does a sanity check before acquiring the new lock in order to make sure that we are not going to get a lock conflict. When this sanity check fails, latObjLatchFree, error 5029 3719 are recorded.
Conversely 3718, 5028 would be thrown if latObjLatchLock() failed, again with the preceeding message for the current owner, for example:
ABL 43: (-----) latObjLatchLock2: latchNum: 19, (lockCnt: 753834, addr: 0x87284a64) latch stack: 1 latches: 0x8005669c
(3718) SYSTEM ERROR: mtlkmux 19, holding 0x0
(5028) SYSTEM ERROR: Releasing regular latch. latchId:<latch-num>
Progress handles these situations by initiating immediate shutdown in order to protect integrity. This is by design:
These symptoms are caused at the time by a smash in shared memory concerning the buffer control structures. Apart from the database primary shared memory, there are also private buffers that the process could have been using (-Bp) and the alternate buffer pool (-B2). Run with -MemCheck and -DbCheck:
Corruption in the index or record blocks could cause shared memory inconsistencies. After such an event:
- It's prudent to initiate a database health check by running DBTOOL Option 3 for data and IDXCHECK for indexes to ensure that there were no corruption or corruption introduced as a result.
System resource issues at the time. For example system paging, disk cache/controller issues etc. can also cause this situation.
How to avoid this situation in future, would entail understanding exactly what was happening in the environment at the time. Refer to related Articles in the Note Section below for known issues in this area.
