Bug 1125142
| Summary: | [abrt] sssd-krb5-common: vasprintf(): ldap_child killed by SIGSEGV | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | birger <b1r63r> | ||||||||||||||||||||||||
| Component: | sssd | Assignee: | Jakub Hrozek <jhrozek> | ||||||||||||||||||||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||
| Version: | 21 | CC: | abokovoy, b1r63r, dpal, jhrozek, lslebodn, pbrezina, preichl, sbose, sgallagh, ssorce | ||||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||||||
| URL: | https://retrace.fedoraproject.org/faf/reports/bthash/54118b7056d5b522ff5f74242107d39ab5f915bb | ||||||||||||||||||||||||||
| Whiteboard: | abrt_hash:959dd35d75abf2c82e3a7ccb21ceb11b1b79a986 | ||||||||||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||||||
| Last Closed: | 2015-11-05 08:27:04 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: | |||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||
|
Description
birger
2014-07-31 07:41:04 UTC
Created attachment 922840 [details]
File: backtrace
Created attachment 922841 [details]
File: cgroup
Created attachment 922842 [details]
File: core_backtrace
Created attachment 922843 [details]
File: dso_list
Created attachment 922844 [details]
File: environ
Created attachment 922845 [details]
File: exploitable
Created attachment 922846 [details]
File: limits
Created attachment 922847 [details]
File: maps
Created attachment 922848 [details]
File: proc_pid_status
Created attachment 922849 [details]
File: var_log_messages
Could you also attach coredump? It should be stored in directory /var/tmp/abrt/ccpp-2014-07-31-09:23:01-2995. Did crash occur just once? Is it always reproducible? btw the crash seems to be happening in the debug message that warns about a wrong keytab -- so the first step should be to fix the keytab.. We should still fix the crash, though. Created attachment 924390 [details]
coredump file
core dump
I tried again yesterday. This time it worked. At the time of the crash it failed for 2 different users, but I didn't reboot and retry then. Thank you very much for coredump. It seems to be bur in glibc, because there are strande data in va_list. On the other hand, I am not very familiar with handling va_list in glibc. I just read documentation [1] on page 54-55.
sssd crashed while debug message was printed.
(gdb) l 320,326
320 sss_krb5_get_error_message(context, krberr));
321 sss_log(SSS_LOG_ERR,
322 "Failed to initialize credentials using keytab [%s]: %s. "
323 "Unable to create GSSAPI-encrypted LDAP connection.",
324 KEYTAB_CLEAN_NAME,
325 sss_krb5_get_error_message(context, krberr));
From va_list, I found strings which should be printed.
(gdb) x/xg ap.reg_save_area+16*0
0x7fff5ed43620: 0x00007f0ad81628c0
(gdb) x/s 0x00007f0ad81628c0
0x7f0ad81628c0: "Client 'SCH-LF-02899$@SCHIBSTED.NO' not found in Kerberos database"
^^^^^
error message from function sss_krb5_get_error_message
(gdb) x/xg ap.reg_save_area+16*1
0x7fff5ed43630: 0x00007f0ad769a5a0
(gdb) x/s 0x00007f0ad769a5a0
0x7f0ad769a5a0: "default"
^^^^
expanded macro KEYTAB_CLEAN_NAME
(gdb) x/xg ap.reg_save_area+16*2
0x7fff5ed43640: 0x6e6920646e756f66
(gdb) x/s 0x6e6920646e756f66
0x6e6920646e756f66: <error: Cannot access memory at address 0x6e6920646e756f66>
sssd crashed due to pointer with malformed data. A I already mentioned it could be bug in glibc or somehow related to upgrade of glibc.
(gdb) x/xg ap.reg_save_area+16*3
0x7fff5ed43650: 0x0000000000000000
[1] http://www.x86-64.org/documentation/abi.pdf
Do you have an idea why there was error: "Client 'SCH-LF-02899$@SCHIBSTED.NO' not found in Kerberos database" that would be my pc. I can understand that the PC object didn't exist when creating the first user. In our domain a user can register a limited number of devices without involving a domain admin, so registering the PC should have worked. And it seemingly did when I tried again a week later. This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. I think it would be fair to not rely on "Fedora End Of Life" and close this ticket as INSUFFICIENT_DATA because we do not know how to reproduce it and it's not clear from coredump what should be fixed. |