The Samba server crashed (unsure of the reason). Here is the backtrace found in the logs: [Tue Feb 16 22:46:36 2010 EST, 0 lib/cmdline/popt_common.c:58:popt_s4_talloc_log_fn()] Bad talloc magic value - double free [Tue Feb 16 22:46:36 2010 EST, 0 ../lib/util/fault.c:143:smb_panic()] PANIC: Bad talloc magic value - double free [Tue Feb 16 22:46:36 2010 EST, 0 ../lib/util/fault.c:62:call_backtrace()] BACKTRACE: 47 stack frames: #0 /usr/local/samba/sbin/samba(call_backtrace+0x2b) [0x8a1e9ff] #1 /usr/local/samba/sbin/samba(smb_panic+0x226) [0x8a1ecd9] #2 /usr/local/samba/sbin/samba [0x8a37ad7] #3 /usr/local/samba/sbin/samba [0x8a37b80] #4 /usr/local/samba/sbin/samba [0x8a37c8e] #5 /usr/local/samba/sbin/samba(_talloc_reference_loc+0x37) [0x8a3812c] #6 /usr/local/samba/sbin/samba(ndr_pull_init_blob+0x7d) [0x8a04a5b] #7 /usr/local/samba/sbin/samba(ndr_pull_struct_blob+0x2b) [0x8a06755] #8 /usr/local/samba/sbin/samba [0x83ee649] #9 /usr/local/samba/sbin/samba(notify_trigger+0x2e) [0x83ef6a3] #10 /usr/local/samba/sbin/samba [0x83d279d] #11 /usr/local/samba/sbin/samba [0x8a38959] #12 /usr/local/samba/sbin/samba [0x8a38ae1] #13 /usr/local/samba/sbin/samba [0x8a38ae1] #14 /usr/local/samba/sbin/samba [0x8a38ae1] #15 /usr/local/samba/sbin/samba(_talloc_free+0xad) [0x8a392a7] #16 /usr/local/samba/sbin/samba [0x839a2a6] #17 /usr/local/samba/sbin/samba [0x8a38959] #18 /usr/local/samba/sbin/samba [0x8a38ae1] #19 /usr/local/samba/sbin/samba [0x8a38ae1] #20 /usr/local/samba/sbin/samba [0x8a38ae1] #21 /usr/local/samba/sbin/samba [0x8a38ae1] #22 /usr/local/samba/sbin/samba(_talloc_free+0xad) [0x8a392a7] #23 /usr/local/samba/sbin/samba [0x8a14f74] #24 /usr/local/samba/sbin/samba(stream_terminate_connection+0xe4) [0x80fd84c] #25 /usr/local/samba/sbin/samba [0x80fd900] #26 /usr/local/samba/sbin/samba [0x80fd94a] #27 /usr/local/samba/sbin/samba [0x8a3edd8] #28 /usr/local/samba/sbin/samba [0x8a3f445] #29 /usr/local/samba/sbin/samba(_tevent_loop_once+0xdf) [0x8a3b70a] #30 /usr/local/samba/sbin/samba(tevent_common_loop_wait+0x26) [0x8a3b92b] #31 /usr/local/samba/sbin/samba(_tevent_loop_wait+0x1d) [0x8a3b9e9] #32 /usr/local/samba/sbin/samba [0x8a14d47] #33 /usr/local/samba/sbin/samba [0x80fdfa7] #34 /usr/local/samba/sbin/samba [0x8a3edd8] #35 /usr/local/samba/sbin/samba [0x8a3f445] #36 /usr/local/samba/sbin/samba(_tevent_loop_once+0xdf) [0x8a3b70a] #37 /usr/local/samba/sbin/samba(tevent_common_loop_wait+0x26) [0x8a3b92b] #38 /usr/local/samba/sbin/samba(_tevent_loop_wait+0x1d) [0x8a3b9e9] #39 /usr/local/samba/sbin/samba [0x8a14ed8] #40 /usr/local/samba/sbin/samba(task_server_startup+0x89) [0x80ffc98] #41 /usr/local/samba/sbin/samba [0x80fd588] #42 /usr/local/samba/sbin/samba(server_service_startup+0x109) [0x80fd6b7] #43 /usr/local/samba/sbin/samba [0x80f711b] #44 /usr/local/samba/sbin/samba(main+0x38) [0x80f7207] #45 /lib/libc.so.6(__libc_start_main+0xe5) [0xb7a90705] #46 /usr/local/samba/sbin/samba [0x80f60a1]
Is the crash deterministic reproducible? It's possible for you to either run the samba daemon under valgrind and provide a logfile? Or to recompile all with "./configure.developer" and run it under gdb (when the crash happens type "bt" or "bt full" (better) and provide us the output)?
tridge, would be nice if you could help us with this.
No there was no reason for the crash, it occurred (I believe) while someone was attempting to use Offline Files Synchronization, but I can't be sure. If it's any help, this particular Offline Files Synchronization contained warnings about certain file types not being able to be made offline.
James, is your samba binary update? We fixed a similar crash not so long ago (see bug #7053). So if you're s4 deployment is a bit older please update first and retry that what could have caused the crash.
I installed it about 4-5 days ago, from the GIT repository (I presume installing from GIT gets the most up-to-date version). Also, is there a way to maintain all of the settings during an upgrade? If I have to upgrade, I don't want to lose all of the settings/users/file permissions.
Okay - that release seems to be recent enough. First run a "make uninstall install" after the build. If the directory (AD) structure changed (new schema, new system objects...) or new configuration files were added you don't need to run a full provision. Do simply use the the "upgradeprovision" script instead. It is located under "scripting/bin" in the s4 source tree. It's suggested to use the "--full" option if possible (this does more checks and updates - without it only the most essential changes are applied).
Just to note that upgradeprovision isn't normally required, but if it won't work after the upgrade, that's where to start looking. Grabbing the backtrace from a developer build would be the most helpful thing at this point. I need to know the calling functions in more detail.
Problem is, even if I did rebuild it as a developer build, I wouldn't even know how to start reproducing the bug - I wasn't there when it occurred and I didn't find out until the next day.
Additional question: when exactly did you check out this failing samba release? Do you have the GIT revision number somewhere? Was it before Feb 13th?
Let us make it like this: since it's very likely that this problem has been fixed already (I discussed this with my team colleaugue tridge) I mark this as "FIXED". If you face this problem again, please REOPEN this bug report.