Build tested:
389-ds-base-1.3.5.10-11.el7
(I rebuilt it with -O0, otherwise gdb wouldn't work properly).

(gdb) break monitor.c:245
Breakpoint 1 at 0x7f9af13e4cda: file ldap/servers/slapd/back-ldbm/monitor.c, line 245.
(gdb) c
Continuing.
[Switching to Thread 0x7f9ae27fc700 (LWP 27388)]

Breakpoint 1, ldbm_back_monitor_search (pb=0x7f9ae27fba70, e=0x7f9ab8001170, entryAfter=0x0, returncode=0x7f9ae27f6b3c, 
    returntext=0x7f9ae27f6930 "", arg=0x7f9afe7e7a20) at ldap/servers/slapd/back-ldbm/monitor.c:245
245	    sprintf(buf, "%lu", (unsigned long)mpstat->st_cache_hit);
(gdb) set mpstat->st_cache_hit = 4294967296
(gdb) set mpstat->st_cache_miss = 5294967296
(gdb) c
Continuing.

$ ldapsearch -x -D "cn=Directory Manager" -w Secret123  -b "cn=monitor,cn=ldbm database,cn=plugins,cn=config" -LLL
...
dbcachehits: 4294967296
dbcachetries: 9589934592
dbcachehitratio: 44
...


But I noticed that there is another overflow in performance counters:
./ldap/servers/slapd/back-ldbm/perfctrs.h:
 33     PRUint32    page_access_rate;

./ldap/servers/slapd/back-ldbm/perfctrs.c:
167             perf->cache_size_bytes = mpstat->st_gbytes * ONEG + mpstat->st_bytes;
168             perf->page_access_rate = mpstat->st_cache_hit + mpstat->st_cache_miss;       <===
169             perf->cache_hit = mpstat->st_cache_hit;
170             perf->cache_try = mpstat->st_cache_hit + mpstat->st_cache_miss;              <===

Also objects-locked has the value of page_access_rate:
260     { SLAPI_LDBM_PERFCTR_AT_PREFIX "objects-locked",
261             offsetof( performance_counters, page_access_rate ) },
262     { SLAPI_LDBM_PERFCTR_AT_PREFIX "page-create-rate",
263             offsetof( performance_counters, page_create_rate ) },

ldapsearch -x -D "cn=Directory Manager" -w Secret123  -b "cn=monitor,cn=ldbm database,cn=plugins,cn=config"  -LLL dbcachetries  nsslapd-db-objects-locked
dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config
dbcachetries: 509565

dn: cn=database,cn=monitor,cn=ldbm database,cn=plugins,cn=config
nsslapd-db-objects-locked: 509565


Noriko, should I open a separate bug or it can be fixed in the scope of this one?

Thanks!

(In reply to Viktor Ashirov from comment #2)
> But I noticed that there is another overflow in performance counters:
> ./ldap/servers/slapd/back-ldbm/perfctrs.h:
>  33     PRUint32    page_access_rate;
> 
> ./ldap/servers/slapd/back-ldbm/perfctrs.c:
> 167             perf->cache_size_bytes = mpstat->st_gbytes * ONEG +
> mpstat->st_bytes;
> 168             perf->page_access_rate = mpstat->st_cache_hit +
> mpstat->st_cache_miss;       <===
> 169             perf->cache_hit = mpstat->st_cache_hit;
> 170             perf->cache_try = mpstat->st_cache_hit +
> mpstat->st_cache_miss;              <===
> 
> Also objects-locked has the value of page_access_rate:
> 260     { SLAPI_LDBM_PERFCTR_AT_PREFIX "objects-locked",
> 261             offsetof( performance_counters, page_access_rate ) },
> 262     { SLAPI_LDBM_PERFCTR_AT_PREFIX "page-create-rate",
> 263             offsetof( performance_counters, page_create_rate ) },

Agh... True...  Thanks for finding them out.

> Noriko, should I open a separate bug or it can be fixed in the scope of this
> one?

I think it's ok to use this bug since the fix is done in the same way and localized in the same file.  Please reopen this bug with a blocker flag...

I'm reopening the upstream ticket.

Thanks a lot, Viktor!

Per weekly meeting, I mark this bug as VERIFIED. And the issue mentioned in c#3 will be addressed in a separate bug in 7.4, since it's minor and been around for at least 11 years.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2594.html