Bug 1349577 - Values of dbcachetries/dbcachehits in cn=monitor could overflow.
Summary: Values of dbcachetries/dbcachehits in cn=monitor could overflow.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-23 17:44 UTC by Noriko Hosoi
Modified: 2016-11-03 20:43 UTC (History)
3 users (show)

Fixed In Version: 389-ds-base-1.3.5.9-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 20:43:23 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2594 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2016-11-03 12:11:08 UTC

Description Noriko Hosoi 2016-06-23 17:44:28 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/48899

Due to the type of the internally used variable, dbcachehits and dbcachetries could overflow and dbcachehitratio shows above 100%.
dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config
dbcachehits: 4060909425
dbcachetries: 113237295
dbcachehitratio: 3586

See also [Private]
Bug 1121807 - Overflow dbcachetries/dbcachehits should be warned as possible

Comment 2 Viktor Ashirov 2016-09-19 16:17:19 UTC
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!

Comment 3 Noriko Hosoi 2016-09-19 16:52:02 UTC
(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!

Comment 4 Viktor Ashirov 2016-09-19 17:51:37 UTC
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.

Comment 6 errata-xmlrpc 2016-11-03 20:43:23 UTC
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


Note You need to log in before you can comment on or make changes to this bug.