Already unlocked mutex gets unlocked again when locks are exhausted

Question

The current (4.7.25) implementation of error handling in __lock_get_internal suffers from a deficiency described below (visible in DIAGNOSTIC mode only though).
Consider the current error-exit cleanup code (lock.c, line 1019):
err:     if (!LF_ISSET(DB_LOCK_UPGRADE | DB_LOCK_SWITCH))
          LOCK_INIT(*lock);
done:     if (newl != NULL &&
     (t_ret = __lock_freelock(lt, newl, sh_locker,
     DB_LOCK_FREE | DB_LOCK_UNLINK)) != 0 && ret == 0)
          ret = t_ret;
     OBJECT_UNLOCK(lt, region, ndx);
     return (ret);
The OBJECT_UNLOCK tries to unconditionally unlock the previously locked partition mutex. Unfortunately this mutex is not always locked.
Initially, when trying to lock, a partition mutex is correctly locked (lock.c, line 585):
          /* Allocate a shared memory new object. */
          OBJECT_LOCK(lt, region, obj, lock->ndx);
          ndx = lock->ndx;
          if ((ret = __lock_getobj(lt, obj, lock->ndx, 1, &sh_obj)) != 0)
               goto err;
But, when a new lock is allocated, the following code is used (lock.c, line 758):
          part_id = LOCK_PART(region, ndx);
          /* Allocate a new lock. */
          if ((newl = SH_TAILQ_FIRST(
          &FREE_LOCKS(lt, part_id), __db_lock)) == NULL) {
               if ((ret = __lock_alloclock(lt, part_id)) != 0)
                    goto err;
               /* Dropped the mutex start over. */
               goto again;
This one calls __lock_alloclock that MAY (but does not always do, see the partition size check, lock.c, line 477) unlock the current partition mutex.
So, when locks/partitions are exhausted in DIAGNOSTIC mode, the failure leads to an environment DB_RUNRECOVERY panic instead of a simple ENOSPC being returned. I cannot say if this does any harm in non-DIAGNOSTIC mode, but I think that unlocking the same mutex twice won't do any good.
Thanks for your attention.

Answer 1

Thank you for your reply.
Yes, I considered myself that relocking mutex back is the easiest solution, but did not bother implementing it since the problem arises only when locks are exhausted which is a showstopper by itself.
As for my case, I just increased locks and lock objects limit tenfold (its okay since I delete several thousands of records via one transactional cursor and this isn't used in a production application, more of a test), so even DIAGNOSTIC build works properly.
Also, I think I have a small suggestion not related to the original topic. When upgrading to 4.7.25 from 4.5.20, I was very happy to discover that environments (region structures I think) are now properly distinguished between platforms (different binary layouts, probably a hash of some internal data or structure size check), so the x64 binary trying to open x86-created environment (or vice versa) doesn't just crash with an assert or an access violation (yes, I run BDB on Win32/Win64 and happy with it) -- it checks some sort of region structure hash and bails out with proper error message about incompatibility.
Unfortunately, the DIAGNOSTIC vs non-DIAGNOSTIC builds still suffer from the aforementioned problem -- they crash/assert when opening incompatible environments (i.e. DIAGNOSTIC environment tries to open non-DIAGNOSTIC one or vice versa). I fully understand that different builds are not intended to be binary compatible, but adding something like you did for region structures to differentiate DIAGNOSTIC and non-DIAGNOSTIC environment formats would be a very good idea.
Thank you for your time.
Message was edited by:
onyXMaster