Bug 1775766 - [abrt] sssd-common: dp_client_register(): sssd_be killed by SIGSEGV
Summary: [abrt] sssd-common: dp_client_register(): sssd_be killed by SIGSEGV
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 31
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Pavel Březina
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:996c4e8c0d04ba4f440f3580f8d...
: 1684824 1768670 1770467 1773758 1785707 1793450 1808849 1822745 1826238 1883228 1886436 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-22 18:18 UTC by Flávio Schefer
Modified: 2020-10-19 16:58 UTC (History)
22 users (show)

Fixed In Version: sssd-2.4.0-1.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-19 16:58:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (27.31 KB, text/plain)
2019-11-22 18:18 UTC, Flávio Schefer
no flags Details
File: core_backtrace (3.42 KB, text/plain)
2019-11-22 18:18 UTC, Flávio Schefer
no flags Details
File: cpuinfo (2.23 KB, text/plain)
2019-11-22 18:18 UTC, Flávio Schefer
no flags Details
File: dso_list (6.85 KB, text/plain)
2019-11-22 18:18 UTC, Flávio Schefer
no flags Details
File: environ (276 bytes, text/plain)
2019-11-22 18:18 UTC, Flávio Schefer
no flags Details
File: exploitable (82 bytes, text/plain)
2019-11-22 18:18 UTC, Flávio Schefer
no flags Details
File: limits (1.29 KB, text/plain)
2019-11-22 18:18 UTC, Flávio Schefer
no flags Details
File: maps (40.38 KB, text/plain)
2019-11-22 18:18 UTC, Flávio Schefer
no flags Details
File: mountinfo (2.09 KB, text/plain)
2019-11-22 18:18 UTC, Flávio Schefer
no flags Details
File: open_fds (2.61 KB, text/plain)
2019-11-22 18:18 UTC, Flávio Schefer
no flags Details
File: proc_pid_status (1.28 KB, text/plain)
2019-11-22 18:18 UTC, Flávio Schefer
no flags Details
File: var_log_messages (153 bytes, text/plain)
2019-11-22 18:18 UTC, Flávio Schefer
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 5298 0 None closed [abrt] sssd-common: dp_client_register(): sssd_be killed by SIGSEGV 2021-02-17 11:12:45 UTC

Description Flávio Schefer 2019-11-22 18:18:28 UTC
Description of problem:
I do not know, it just crashed

Version-Release number of selected component:
sssd-common-2.2.2-3.fc31

Additional info:
reporter:       libreport-2.11.3
backtrace_rating: 4
cgroup:         0::/system.slice/sssd.service
cmdline:        /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
crash_function: dp_client_register
executable:     /usr/libexec/sssd/sssd_be
journald_cursor: s=a7fa74212aae4cfc8040a6b34ab268c8;i=16da;b=cc63c4befafc43ea801971a845c4ac64;m=42aa18c;t=597d7ca1eebc6;x=4eaac48583ca5150
kernel:         5.3.11-300.fc31.x86_64
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            0

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 dp_client_register at src/providers/data_provider/dp_client.c:107
 #1 _sbus_sss_invoke_in_s_out__step at src/sss_iface/sbus_sss_invokers.c:682
 #2 tevent_common_invoke_timer_handler at ../../tevent_timed.c:370
 #3 tevent_common_loop_timer_delay at ../../tevent_timed.c:442
 #4 epoll_event_loop_once at ../../tevent_epoll.c:922
 #5 std_event_loop_once at ../../tevent_standard.c:110
 #6 _tevent_loop_once at ../../tevent.c:772
 #7 tevent_common_loop_wait at ../../tevent.c:895
 #8 std_event_loop_wait at ../../tevent_standard.c:141
 #9 server_loop at src/util/server.c:721

Potential duplicate: bug 1684824

Comment 1 Flávio Schefer 2019-11-22 18:18:32 UTC
Created attachment 1638838 [details]
File: backtrace

Comment 2 Flávio Schefer 2019-11-22 18:18:34 UTC
Created attachment 1638839 [details]
File: core_backtrace

Comment 3 Flávio Schefer 2019-11-22 18:18:35 UTC
Created attachment 1638840 [details]
File: cpuinfo

Comment 4 Flávio Schefer 2019-11-22 18:18:37 UTC
Created attachment 1638841 [details]
File: dso_list

Comment 5 Flávio Schefer 2019-11-22 18:18:39 UTC
Created attachment 1638842 [details]
File: environ

Comment 6 Flávio Schefer 2019-11-22 18:18:40 UTC
Created attachment 1638843 [details]
File: exploitable

Comment 7 Flávio Schefer 2019-11-22 18:18:42 UTC
Created attachment 1638844 [details]
File: limits

Comment 8 Flávio Schefer 2019-11-22 18:18:44 UTC
Created attachment 1638845 [details]
File: maps

Comment 9 Flávio Schefer 2019-11-22 18:18:45 UTC
Created attachment 1638846 [details]
File: mountinfo

Comment 10 Flávio Schefer 2019-11-22 18:18:47 UTC
Created attachment 1638847 [details]
File: open_fds

Comment 11 Flávio Schefer 2019-11-22 18:18:48 UTC
Created attachment 1638848 [details]
File: proc_pid_status

Comment 12 Flávio Schefer 2019-11-22 18:18:50 UTC
Created attachment 1638849 [details]
File: var_log_messages

Comment 13 Pavel Březina 2019-11-29 12:01:04 UTC
This can be reproduce by postponing backend startup.

--- a/src/providers/data_provider_be.c
+++ b/src/providers/data_provider_be.c
@@ -702,6 +702,8 @@ int main(int argc, const char *argv[])
     uid_t uid;
     gid_t gid;

+    sleep(5);
+
     struct poptOption long_options[] = {
         POPT_AUTOHELP
         SSSD_MAIN_OPTS

There is a race condition when a responder connects to data provider before connection function is set. I.e. sometime between sbus_server_create_and_connect_send and dp_init_done.

Comment 14 Pavel Březina 2019-12-03 10:21:27 UTC
It is a race condition:

- dp_init_send
  - sbus_server_create_and_connect_send
    - sbus_server_create (*)
- dp_init_done (callback for sbus_server_create_and_connect_send)
  - sbus_server_create_and_connect_recv
  - sbus_server_set_on_connection (sets clients data and creates dp_cli)

At (*) sbus server is already created and accepts new connections once we get into tevent loop. So it is possible that the client connects to server before sbus_server_set_on_connection is called and thus the client is not properly initialized. However it should not happen in normal start because providers are started before responders and it can happen only if data provider startup is somehow delay.

Flávio, do you have any sssd logs from this crash? Thank you.

Comment 15 Flávio Schefer 2019-12-09 02:49:22 UTC
I do not know... How I do find those?

Comment 16 Sumit Bose 2019-12-09 07:28:51 UTC
(In reply to Flávio Schefer from comment #15)
> I do not know... How I do find those?

Hi,

please add 'debug_level = 9' to the [domain/...] section in /etc/sssd/sssd.conf and restart SSSD. The logs can be found in /var/log/sssd/. If you are interested you can find more details in https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html.

HTH

bye,
Sumit

Comment 17 delgadoramirezhenryjesus@gmail.com 2019-12-20 18:16:44 UTC
*** Bug 1785707 has been marked as a duplicate of this bug. ***

Comment 18 Alexey Tikhonov 2020-01-16 13:20:52 UTC
*** Bug 1684824 has been marked as a duplicate of this bug. ***

Comment 19 Alexey Tikhonov 2020-01-20 16:20:17 UTC
*** Bug 1770467 has been marked as a duplicate of this bug. ***

Comment 20 Alexey Tikhonov 2020-01-20 16:22:05 UTC
*** Bug 1768670 has been marked as a duplicate of this bug. ***

Comment 21 Giliard Lourenço 2020-01-21 11:37:19 UTC
*** Bug 1793450 has been marked as a duplicate of this bug. ***

Comment 22 kb1000 2020-03-01 15:37:22 UTC
*** Bug 1808849 has been marked as a duplicate of this bug. ***

Comment 23 Alexey Tikhonov 2020-04-16 13:18:42 UTC
*** Bug 1822745 has been marked as a duplicate of this bug. ***

Comment 24 robert fairbrother 2020-04-20 05:03:31 UTC
Similar problem has been detected:

for some reason i leave my computers root partition is filling up when i am logged in 

reporter:       libreport-2.12.0
backtrace_rating: 4
cgroup:         0::/system.slice/sssd.service
cmdline:        /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
crash_function: dp_client_register
executable:     /usr/libexec/sssd/sssd_be
journald_cursor: s=dd23ba7da38f49cf939e8bee5ee2453c;i=1e11;b=778e80a92aa24301b6b85bc4ad76fc73;m=a2717ee96;t=5a3a55ecf10ac;x=29abd41eb4e243e
kernel:         5.5.17-200.fc31.x86_64
package:        sssd-common-2.2.3-13.fc31
reason:         sssd_be killed by SIGSEGV
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            0

Comment 25 Debajit Dutta 2020-04-21 09:51:29 UTC
*** Bug 1826238 has been marked as a duplicate of this bug. ***

Comment 26 Alexey Tikhonov 2020-06-15 15:50:39 UTC
*** Bug 1773758 has been marked as a duplicate of this bug. ***

Comment 27 Fedora Update System 2020-07-27 14:07:14 UTC
FEDORA-2020-63a418c824 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-63a418c824

Comment 29 Pavel Březina 2020-07-28 08:16:33 UTC
This is still an issue and was included in the update by accident.

Comment 30 Pavel Březina 2020-08-26 10:48:19 UTC
Upstream ticket:
https://github.com/SSSD/sssd/issues/5298

Comment 31 Pavel Březina 2020-08-26 11:43:26 UTC
Upstream PR:
https://github.com/SSSD/sssd/pull/5299

Comment 32 Pavel Březina 2020-09-17 12:17:04 UTC
Pushed PR: https://github.com/SSSD/sssd/pull/5299

* `master`
    * 4a84f8e18ea5604ac7e69849dee492718fd96296 - dp: fix potential race condition in provider's sbus server

Comment 33 Alexey Tikhonov 2020-09-29 08:43:16 UTC
*** Bug 1883228 has been marked as a duplicate of this bug. ***

Comment 34 Alexey Tikhonov 2020-10-01 14:19:20 UTC
Pushed PR: https://github.com/SSSD/sssd/pull/5344

* `master`
    * 7fbcaa8feeb968711ff52f51705c45062fd81394 - be: remove accidental sleep

Comment 35 Pavel Březina 2020-10-08 13:02:44 UTC
*** Bug 1886436 has been marked as a duplicate of this bug. ***

Comment 36 Fedora Update System 2020-10-12 12:14:50 UTC
FEDORA-2020-5a1603a348 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5a1603a348

Comment 37 Fedora Update System 2020-10-12 14:31:37 UTC
FEDORA-2020-5a1603a348 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-5a1603a348`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5a1603a348

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 38 Fedora Update System 2020-10-19 16:58:04 UTC
FEDORA-2020-5a1603a348 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


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