Fields changed

blockedby: =>
blocking: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
milestone: NEEDS_TRIAGE => SSSD 1.10.0
priority: major => critical
review: True => 0
selected: =>
testsupdated: => 0

Fields changed

rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=967012 967012] => [https://bugzilla.redhat.com/show_bug.cgi?id=967012 967012] todo

Fields changed

changelog: =>
owner: somebody => mzidek
status: new => assigned

Not a regression, not blocking the 1.10.0 release.

milestone: SSSD 1.10.0 => SSSD 1.10.1

725         slot = mcc->hash_table[hash];
726         if (slot > MC_SIZE_TO_SLOTS(mcc->dt_size)) {
727             ret = ENOENT;
728             goto done;
729         }
730
731         while (slot != MC_INVALID_VAL) {
732             rec = MC_SLOT_TO_PTR(mcc->data_table, slot, struct sss_mc_rec);
733             data = (struct sss_mc_grp_data *)(&rec->data);
734
735             if (gid == data->gid) {

From backtrace:

• sssd_nss crashed at line 735
• rec is not NULL (line 732, rec <- 0x7f77d8f58e98)
• rec != NULL therefore data could not be NULL (line 733, data <- 0x7f77d8f58eb8)

The main problem is that pointer "data" has very big value. Reason is count of slots (variable with name slot) is also too big [[BR]]
slot <- 100,689,267. I can not understand why is this value so big, because there is a check on line 726.

Value of some variables:

• can be directly find in backtrace
• another values was indirectly calculated from cpu registers

*some values can not be retrieved, because values was stored only in registers (optimized out) and later overridden with another values (ex. mcc->dt_size)

Possible explanation:

• mcc->dt_size is also very big, therefore ENOENT was not returned
• size of allocated data (mcc->data_table) is not the same as mcc->dt_size.
• mcc must be corrupted

It is impossible to find real reason without core file or log files.

_comment0: {{{
725 slot = mcc->hash_table[hash];
726 if (slot > MC_SIZE_TO_SLOTS(mcc->dt_size)) {
727 ret = ENOENT;
728 goto done;
729 }
730
731 while (slot != MC_INVALID_VAL) {
732 rec = MC_SLOT_TO_PTR(mcc->data_table, slot, struct sss_mc_rec);
733 data = (struct sss_mc_grp_data *)(&rec->data);
734
735 if (gid == data->gid) {
}}}

From backtrace:
sssd_nss crashed at line 735
rec is not NULL (line 732, rec <- 0x7f77d8f58e98)
* rec != NULL therefore data could not be NULL (line 733, data <- 0x7f77d8f58eb8)

The main problem is that pointer "data" has very big value. Reason is count of slots (variable with name slot) is also too big [[BR]]
slot <- 10,689,267. I can not understand why is this value so big, because there is a check on line 726.

Value of some variables:
can be directly find in backtrace
another values was indirectly calculated from cpu registers
*some values can not be retrieved, because values was stored only in registers (optimized out) and later overridden with another values (ex. mcc->dt_size)

Possible explanation:
mcc->dt_size is also very big, therefore ENOENT was not returned
size of allocated data (mcc->data_table) is not the same as mcc->dt_size.
* mcc must be corrupted

It is impossible to find real reason without core file or log files. => 1375720857977492

Fields changed

cc: => lslebodn@redhat.com

Moving tickets that didn't make 1.10.1 to the 1.10.2 bucket.

Moving tickets that didn't make 1.10.1 to 1.10.2

milestone: SSSD 1.10.1 => SSSD 1.10.2

This is a duplicate of #2018 that has better information, so I'm going to fold them into one.

resolution: => duplicate
status: assigned => closed

Fields changed

rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=967012 967012] todo => [https://bugzilla.redhat.com/show_bug.cgi?id=967012 967012]

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2990

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.