[PATCH] Cache messaging dgm connections

[Ralph Böhme]

On Wed, Sep 14, 2016 at 10:32:47PM -0700, Jeremy Allison wrote:
> On Wed, Sep 14, 2016 at 10:13:13PM -0700, Jeremy Allison wrote:
> > 
> > My money is on the event context getting freed with
> > active connections. I'm cheating here as this is
> > something metze already discovered with Volker's
> > tmsgd work :-).
> > 
> > Metze's patch for this is attached (modified to
> > compile in master). I'm trying a private autobuild
> > with it now.
> 
> FYI. The reason I think that is in the gdb trace
> we have (going in reverse):
> 
> #65 0x00002b6f747fae31 in binary_smbd_main (binary_name=0x2b6f747fb711 "samba", argc=6, argv=0x7ffc43367318) at ../source4/smbd/server.c:489
>         opt_daemon = false
>         opt_interactive = true
>         opt = -1
>         pc = 0x2b6f77f071c0
>         static_init = {0x2b6f7494f905 <server_service_auth_init>, 0x2b6f74952041 <server_service_echo_init>, 0x0}
>         shared_init = 0x2b6f77f53e70
>         event_ctx = 0x2b6f77f28e00
> 
> #64 0x00002b6f7494fc95 in server_service_startup (event_ctx=0x2b6f77f28e00, lp_ctx=0x2b6f77f084a0, model=0x2b6f77f077b0 "standard", server_services=0x2b6f77f0beb0) at ../source4/smbd/service.c:95
> 
> #63 0x00002b6f7494fb52 in server_service_init (name=0x2b6f77f0c2c0 "drepl", event_context=0x2b6f77f28e00, lp_ctx=0x2b6f77f084a0, model_ops=0x2b6f78013b60 <standard_ops>) at ../source4/smbd/service.c:63
> 
> #62 0x00002b6f74951748 in task_server_startup (event_ctx=0x2b6f77f28e00, lp_ctx=0x2b6f77f084a0, service_name=0x2b6f7b08935f "drepl", model_ops=0x2b6f78013b60 <standard_ops>, task_init=0x2b6f7b076ce7 <dreplsrv_task_init>) at ../source4/smbd/service_task.c:114
> 
> #61 0x00002b6f78011fe7 in standard_new_task (ev=0x2b6f77f28e00, lp_ctx=0x2b6f77f084a0, service_name=0x2b6f7b08935f "drepl", new_task=0x2b6f749515ae <task_server_callback>, private_data=0x2b6f7f7218f0) at ../source4/smbd/process_standard.c:364
> 
> #60 0x00002b6f749226f0 in _tevent_loop_wait (ev=0x2b6f77f28e00, location=0x2b6f780127c8 "../source4/smbd/process_standard.c:364") at ../lib/tevent/tevent.c:822
> 
> #59 0x00002b6f74929444 in std_event_loop_wait (ev=0x2b6f77f28e00, location=0x2b6f780127c8 "../source4/smbd/process_standard.c:364") at ../lib/tevent/tevent_standard.c:145
> 
> #57 0x00002b6f7492233d in _tevent_loop_once (ev=0x2b6f77f28e00, location=0x2b6f780127c8 "../source4/smbd/process_standard.c:364") at ../lib/tevent/tevent.c:680
> 
> #55 0x00002b6f7492c4e6 in epoll_event_loop_once (ev=0x2b6f77f28e00, location=0x2b6f780127c8 "../source4/smbd/process_standard.c:364") at ../lib/tevent/tevent_epoll.c:930
> 
> #53 0x00002b6f767c8461 in poll_funcs_fde_handler (ev=0x2b6f77f28e00, fde=0x2b6f7f7198e0, flags=1, private_data=0x2b6f7f8f38e0) at ../lib/poll_funcs/poll_funcs_tevent.c:610
> 
> Note how in all of the above the tevent_ctx == 0x2b6f77f28e00.
> 
> At the crash site we have:
> 
> #8  0x00002b6f74922a4b in tevent_debug (ev=0x2b6f813acd80, level=TEVENT_DEBUG_TRACE, fmt=0x2b6f7492d638 "Destroying timer event %p \"%s\"\n") at ../lib/tevent/tevent_debug.c:93
> 
> Now ev==0x2b6f813acd80
> 
> Something's not right here.

good catch, probably an event context talloced in ldb_init(...,
ev_ctx=NULL).

Cheerio!
-slow