Each time you try a "vampire" or "samsync" you get a stacktrace like the following one (extracted from the post of Brian Dickson on the technical list): net -U Administrator vampire CONCERTIA Password for [CONCERTIA\Administrator]: talloc: double free error - first free may be at librpc/rpc/dcerpc_connect.c:809 Bad talloc magic value - double free PANIC: Bad talloc magic value - double free BACKTRACE: 36 stack frames: #0 net(call_backtrace+0x2b) [0x86e2ce7] #1 net(smb_panic+0x226) [0x86e2fc1] #2 net [0x86fbc2b] #3 net [0x86fbcd4] #4 net [0x86fbde2] #5 net [0x86fc544] #6 net(_talloc_steal_loc+0xb4) [0x86fc79b] #7 net(data_blob_talloc_named+0x58) [0x86e85a2] #8 net [0x81c1793] #9 net(gensec_update+0x3a) [0x81b93c5] #10 net [0x81e8511] #11 net [0x81e9612] #12 net(gensec_update+0x3a) [0x81b93c5] #13 net [0x815a262] #14 net(smb_composite_sesssetup_send+0x1a7) [0x815a5b3] #15 net [0x8158219] #16 net [0x815884e] #17 net [0x8158939] #18 net [0x8162718] #19 net(packet_recv+0x756) [0x821361e] #20 net [0x8161601] #21 net [0x86d3524] #22 net [0x86d3bd4] #23 net(_tevent_loop_once+0xdf) [0x86cff4f] #24 net(composite_wait+0x44) [0x8248abe] #25 net [0x80dc8f3] #26 net(libnet_RpcConnect_recv+0xb4) [0x80dcce6] #27 net(libnet_RpcConnect+0x5e) [0x80dcd7a] #28 net(libnet_JoinDomain+0x197) [0x80de162] #29 net(libnet_Vampire+0x1bd) [0x80ea9a2] #30 net(net_vampire+0x17f) [0x80d282f] #31 net(net_run_function+0xc5) [0x80d0d11] #32 net [0x80d151e] #33 net(main+0x22) [0x80d15b8] #34 /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xf742b685] #35 net [0x80d0941] Aborted
Created attachment 5335 [details] GDB log
Created attachment 5336 [details] Valgrind log
I've analysed a bit the valgrind log and it seems to be related to the gensec auth backends. Could it be that a certain backend has been initialised and another one is going to be used for the update operation? Since the backend called by the update operation (GSSAPI I think) doesn't seems to have it's memory context working (that means not allocated). abartlet or metze, could you do some investigation?
That's the known nested event loop bug that happens when we get a connection error. There's a timeout error (see the valgrind log). My long term plan is to convert all client libraries to use tstream_context instead of packet_recv() and use a much easier talloc hierachie. If someone finds a hacked patch to avoid this, please tell me.
I think this has been fixed.