[PATCH] Cache messaging dgm connections

Jeremy Allison jra at samba.org
Thu Sep 15 05:32:47 UTC 2016


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.



More information about the samba-technical mailing list