On Wed, Apr 20, 2016 at 09:57:03AM -0400, Simo Sorce wrote: > 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.
Yes, I can prepare a branch on github with fixup patches and ask you if it's OK to squash the fixups into your patches. > > > 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
