Bug 1125142 - [abrt] sssd-krb5-common: vasprintf(): ldap_child killed by SIGSEGV
Summary: [abrt] sssd-krb5-common: vasprintf(): ldap_child killed by SIGSEGV
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 21
Hardware: x86_64
OS: Unspecified
Target Milestone: ---
Assignee: Jakub Hrozek
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:959dd35d75abf2c82e3a7ccb21c...
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-31 07:41 UTC by birger
Modified: 2015-11-05 08:27 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-11-05 08:27:04 UTC

Attachments (Terms of Use)
File: backtrace (276.18 KB, text/plain)
2014-07-31 07:41 UTC, birger
no flags Details
File: cgroup (188 bytes, text/plain)
2014-07-31 07:41 UTC, birger
no flags Details
File: core_backtrace (1.59 KB, text/plain)
2014-07-31 07:41 UTC, birger
no flags Details
File: dso_list (2.62 KB, text/plain)
2014-07-31 07:41 UTC, birger
no flags Details
File: environ (225 bytes, text/plain)
2014-07-31 07:41 UTC, birger
no flags Details
File: exploitable (82 bytes, text/plain)
2014-07-31 07:41 UTC, birger
no flags Details
File: limits (1.29 KB, text/plain)
2014-07-31 07:41 UTC, birger
no flags Details
File: maps (12.75 KB, text/plain)
2014-07-31 07:41 UTC, birger
no flags Details
File: proc_pid_status (1.02 KB, text/plain)
2014-07-31 07:41 UTC, birger
no flags Details
File: var_log_messages (571 bytes, text/plain)
2014-07-31 07:41 UTC, birger
no flags Details
coredump file (880.00 KB, application/octet-stream)
2014-08-06 08:13 UTC, birger
no flags Details

Description birger 2014-07-31 07:41:04 UTC
Description of problem:
I installed F20 from a live image, and then immediately used yum to upgrade to F21.

I manually installed krb5-workstation, sssd-dbus, sssd-tools and adcli

Then I tried to add a corporate account through the GUI.

The domain has moved into the list shown by "realm list", the two users I tried to add are listed as permitted logins, but the GUI tells me it cannot find the users. Very likely because of the crash in the LDAP module. :-)

Version-Release number of selected component:

Additional info:
reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        /usr/libexec/sssd/ldap_child --debug-microseconds=0 --debug-timestamps=1 --debug-fd=17 --debug-level=0x0010
crash_function: vasprintf
executable:     /usr/libexec/sssd/ldap_child
kernel:         3.16.0-0.rc7.git1.1.fc21.x86_64
runlevel:       N 5
type:           CCpp
uid:            0

Truncated backtrace:
Thread no. 1 (4 frames)
 #2 vasprintf at /usr/include/bits/stdio2.h:210
 #3 sss_log_ext at src/util/sss_log.c:80
 #4 sss_log at src/util/sss_log.c:65
 #5 ldap_child_get_tgt_sync at src/providers/ldap/ldap_child.c:321

Comment 1 birger 2014-07-31 07:41:09 UTC
Created attachment 922840 [details]
File: backtrace

Comment 2 birger 2014-07-31 07:41:10 UTC
Created attachment 922841 [details]
File: cgroup

Comment 3 birger 2014-07-31 07:41:12 UTC
Created attachment 922842 [details]
File: core_backtrace

Comment 4 birger 2014-07-31 07:41:13 UTC
Created attachment 922843 [details]
File: dso_list

Comment 5 birger 2014-07-31 07:41:14 UTC
Created attachment 922844 [details]
File: environ

Comment 6 birger 2014-07-31 07:41:15 UTC
Created attachment 922845 [details]
File: exploitable

Comment 7 birger 2014-07-31 07:41:16 UTC
Created attachment 922846 [details]
File: limits

Comment 8 birger 2014-07-31 07:41:18 UTC
Created attachment 922847 [details]
File: maps

Comment 9 birger 2014-07-31 07:41:19 UTC
Created attachment 922848 [details]
File: proc_pid_status

Comment 10 birger 2014-07-31 07:41:21 UTC
Created attachment 922849 [details]
File: var_log_messages

Comment 11 Lukas Slebodnik 2014-08-05 14:39:56 UTC
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?

Comment 12 Jakub Hrozek 2014-08-05 20:10:54 UTC
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.

Comment 13 birger 2014-08-06 08:13:03 UTC
Created attachment 924390 [details]
coredump file

core dump

Comment 14 birger 2014-08-06 08:14:09 UTC
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.

Comment 15 Lukas Slebodnik 2014-08-08 14:04:13 UTC
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

Comment 16 Lukas Slebodnik 2014-08-08 14:05:09 UTC
Do you have an idea why there was error:
"Client 'SCH-LF-02899$@SCHIBSTED.NO' not found in Kerberos database"

Comment 17 birger 2014-08-25 11:14:55 UTC
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.

Comment 18 Fedora End Of Life 2015-11-04 10:36:45 UTC
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.

Comment 19 Lukas Slebodnik 2015-11-05 08:27:04 UTC
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.

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