On Wed, 2016-04-20 at 11:55 +0200, Jakub Hrozek wrote: > On Tue, Apr 05, 2016 at 02:54:10PM -0400, Simo Sorce wrote: > > On Tue, 2016-04-05 at 12:57 -0400, Simo Sorce wrote: > > > Thanks, IIRC the int-instead of enum use is intentional, I will look > > > at the others. > > > > The last coverity/clang thing is a false positive, but I initialized > > reply to NULL anyway, I expect now it will start complaining of possible > > NULL dereference :-) > > > > Attached find patches that fixes all other issues (hopefully), one of > > them simply dropped an entire function as it turned out I wasn't using > > it. > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > From 02e259e44631d228e0ec8311392e4a1a1a661b89 Mon Sep 17 00:00:00 2001 > > From: Simo Sorce <s...@redhat.com> > > Date: Fri, 8 Jan 2016 17:51:06 -0500 > > Subject: [PATCH 04/15] Responders: Make the client context more generic > > This patch breaks the PAM responder: > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000000000 in ?? () > (gdb) bt > #0 0x0000000000000000 in ?? () > #1 0x0000000000413512 in accept_fd_handler (ev=0x653a40, fde=0x668970, > flags=1, ptr=0x6604b0) at /sssd/src/responder/common/responder_common.c:478 > #2 0x00007f8fe25d5bf3 in epoll_event_loop (tvalp=0x7ffd4e5d41b0, > epoll_ev=0x653c80) at ../tevent_epoll.c:728 > #3 epoll_event_loop_once (ev=<optimized out>, location=<optimized out>) at > ../tevent_epoll.c:926 > #4 0x00007f8fe25d4137 in std_event_loop_once (ev=0x653a40, > location=0x7f8fe5f88aed "/sssd/src/util/server.c:689") at > ../tevent_standard.c:114 > #5 0x00007f8fe25d038d in _tevent_loop_once (ev=ev@entry=0x653a40, > location=location@entry=0x7f8fe5f88aed "/sssd/src/util/server.c:689") at > ../tevent.c:533 > #6 0x00007f8fe25d052b in tevent_common_loop_wait (ev=0x653a40, > location=0x7f8fe5f88aed "/sssd/src/util/server.c:689") at ../tevent.c:637 > #7 0x00007f8fe25d40d7 in std_event_loop_wait (ev=0x653a40, > location=0x7f8fe5f88aed "/sssd/src/util/server.c:689") at > ../tevent_standard.c:140 > #8 0x00007f8fe5f67b55 in server_loop (main_ctx=0x654e90) at > /sssd/src/util/server.c:689 > #9 0x0000000000406f57 in main (argc=6, argv=0x7ffd4e5d4598) at > /sssd/src/responder/pam/pamsrv.c:426 > (gdb) frame 1 > #1 0x0000000000413512 in accept_fd_handler (ev=0x653a40, fde=0x668970, > flags=1, ptr=0x6604b0) at /sssd/src/responder/common/responder_common.c:478 > 478 ret = accept_ctx->connection_setup(cctx); > (gdb) p accept_ctx > $1 = (struct accept_fd_ctx *) 0x6604b0 > (gdb) p accept_ctx->connection_setup > $2 = (connection_setup_t) 0x0 > > Do you want me to fix this and proceed or will you?
If you already know what's wrong, feel free to fix it, if you have to spend time analyzing I can do it, should be an easy fix. > The NSS, autofs and IFP responders seem to work fine. I haven't tested > the others yet. Ok, sorry for that, I did install SSSD at various times, but was more concentrated on testing the secrets stuff, and the tests went smoothly, but I now realize they fake the connection handling. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
