Bug 7131 - net tool: crash in authentication subsystem
Summary: net tool: crash in authentication subsystem
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Tools (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: samba4-qa@samba.org
URL: http://lists.samba.org/archive/samba-...
Depends on:
Blocks: 6600
  Show dependency treegraph
Reported: 2010-02-12 04:22 UTC by Matthias Dieter Wallnöfer
Modified: 2010-03-24 11:42 UTC (History)
1 user (show)

See Also:

GDB log (17.83 KB, text/plain)
2010-02-12 04:24 UTC, Matthias Dieter Wallnöfer
no flags Details
Valgrind log (8.36 KB, application/x-gzip)
2010-02-12 04:24 UTC, Matthias Dieter Wallnöfer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Dieter Wallnöfer 2010-02-12 04:22:32 UTC
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]
Comment 1 Matthias Dieter Wallnöfer 2010-02-12 04:24:25 UTC
Created attachment 5335 [details]
GDB log
Comment 2 Matthias Dieter Wallnöfer 2010-02-12 04:24:51 UTC
Created attachment 5336 [details]
Valgrind log
Comment 3 Matthias Dieter Wallnöfer 2010-02-12 04:27:08 UTC
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?
Comment 4 Stefan Metzmacher 2010-02-12 05:52:54 UTC
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.
Comment 5 Matthias Dieter Wallnöfer 2010-03-24 11:42:23 UTC
I think this has been fixed.