While creating a transitive two-way external trust using the MMC snap-in I recieved the following stack trace to my console (running samba -i -M single): =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= INTERNAL ERROR: Signal 11 in pid 5780 (4.0.0alpha12-GIT-5a88e43) Please read the file BUGS.txt in the distribution =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= PANIC: internal error BACKTRACE: 25 stack frames: #0 sbin/samba(call_backtrace+0x2b) [0x8a3ee6f] #1 sbin/samba(smb_panic+0x22d) [0x8a3f150] #2 sbin/samba [0x8a3f2a9] #3 sbin/samba(fault_setup+0) [0x8a3f2de] #4 [0x407400] #5 sbin/samba(ndr_pull_policy_handle+0x66) [0x8a28a2d] #6 sbin/samba(ndr_pull_samr_Close+0x459) [0x8817239] #7 sbin/samba(dcerpc_ndr_request_recv+0x1fe) [0x83a32bf] #8 sbin/samba [0x836df15] #9 sbin/samba [0x836e0fb] #10 sbin/samba [0x83a19a5] #11 sbin/samba [0x83a0bd2] #12 sbin/samba [0x83a7718] #13 sbin/samba [0x84a9fdb] #14 sbin/samba(packet_recv+0x764) [0x8557dad] #15 sbin/samba [0x84a8e79] #16 sbin/samba [0x8a5e782] #17 sbin/samba [0x8a5edc2] #18 sbin/samba(_tevent_loop_once+0xdd) [0x8a5ae81] #19 sbin/samba(tevent_common_loop_wait+0x26) [0x8a5b0a0] #20 sbin/samba(_tevent_loop_wait+0x1d) [0x8a5b152] #21 sbin/samba [0x80ecbcd] #22 sbin/samba(main+0x31) [0x80ecc23] #23 /lib/libc.so.6(__libc_start_main+0xe6) [0x891a66] #24 sbin/samba [0x80ebb41] Aborted [root@teadc1 samba]# 2.6.30.5-43.fc11.i686.PAE #1 SMP Thu Aug 27 21:34:36 EDT 2009 i686 i686 i386 GNU/Linux Other domain is a windows2000 AD domain. This is in a completely sanitized test environment built for the purpose of implementing samba4.
Another time the procedure how to provide us helpful stacktraces. Since the form you provided is in most cases useless for us. (citation by Andrew Bartlett): >> Can you double-check this with a clean build after ./configure.developer and >> run samba like: >> >> gdb --args bin/samba -i -M single -d3 >> >> then get me a 'bt full' when it crashes. >> >> Thanks. So we know all relevant function and variable names and states. Thanks.
If you cannot provide us the debug stacktrace we need to close this with "INVALID". We are sorry, but we really need this information.
Closing with "INVALID" until we hear us again (with more informations: logfiles, detailed stacktraces ...).