Bug 1349577
Summary: | Values of dbcachetries/dbcachehits in cn=monitor could overflow. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Noriko Hosoi <nhosoi> |
Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> |
Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.3 | CC: | nhosoi, nkinder, rmeggins |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 389-ds-base-1.3.5.9-1.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-11-03 20:43:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Noriko Hosoi
2016-06-23 17:44:28 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! (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 |