ldbedit (actually all ldb* command-line tools) abort() with a "Bad talloc magic value - unknown value" error. Initially found error when running with the --help option, but also found error occurs when actually editing. The comments below reference gdb debugging output which I will attach after opening this bug. Note that I added the talloc_enable_leak_report_full() call shown in the debugging output to help my debugging efforts. From the debuging output: - Once the tevent_context has been setup in ldb_init(): - ev_ctx == (struct tevent_context *) 0x110e370 - ev_ctx->pipe_fde == (struct tevent_fd *) 0x110e430 - ev_ctx->debug_ops.debug == 0x469588 <ldb_tevent_debug> After these values are set, I call talloc_report_full() to verify the current talloc stack looks good. Continuing the execution to the exit() call [line 106 in the debugging output] shows the help text displays correctly. I then use the value of the ev_ctx pointer from above to verify the values of pipe_fde and debug_ops.debug, which are still correct. Continuing the execution from there results in the abort() call. The talloc error message can be seen in frame #2 of the backtrace. Looking at backtrace frames #4, #5, #6 shows we are trying to free the ev_ctx->debug_ops.debug pointer (function pointer passed to tevent_set_debug() in line 18 of the debugging output). However backtrace frame #7 indicates the talloc_free() was called on line 150 of ../lib/tevent/tevent.c, which is talloc_free(ev->pipe_fde). This indicates some sort of corruption in the cleanup process, as the values of pipe_fde and debug_ops.debug were verified before the cleanup started as part of the exit() call. Note that in all my attempts to debug the error, the talloc_free() call always aborts while attempting to free the address of the ldb_tevent_debug function, which is passed to tevent_set_debug().
Created attachment 4010 [details] Debugging output referenced in initial bug report.
The original reported issue is not confined to the ldb* command-line tools - it also happens within the samba4 daemon. When running without the '-M single' arguments, there are numerous abort() calls. I will attach the samba.log from one of these runs. When running with '-M single', there is only one single abort() after stopping with SIGTERM. I will attach a gdb backtrace from this run.
Created attachment 4011 [details] samba.log when running without '-M single'
Created attachment 4012 [details] gdb backtrace when running with '-M single'
I can't reproduce it now, so I mark it as "FIXED". If it isn't, please reopen!
I had just reproduced this again over the weekend (4.0.0alpha8-GIT-a1d8315). I'm running 64-bit Fedora 9 w/ all updates. If there has been something committed since what I am working with that is expected to fix the issue I have reported, please let me know. I am changing severity of this bug to blocker. I understand that there may be issues reproducing the bug under different installations/configurations, however I believe what I have observed should be corrected before the next alpha is cut. If there are any problems reproducing this issue, please post through this bug, as I cannot currently commit to my schedule of availability. I will respond to posts on this bug and am willing to work with someone with better gdb-foo to track down the issue.
Okay, I finally got some time to look into this again. Got quite a surprise too... I have shell scripts to do all my builds (including clean builds), installs, provisions, etc., and I just found out my clean build script (which uses "git clean -dfx") was not completely cleaning my build environment. As it turns out, git clean (even with the "-dfx" arguments) only cleans from the current directory down, and my clean build script was being run in the source4 directory. Therefore, none of the common directories that have been moved for the merged build (including tevent) were being cleaned. Once I realized what was happening and ran the git clean from the top-level samba directory, all works fine. No bug here, so closing as INVALID.