a minor but annoying bug, basically smbclient is crashing during tab completion when part of a word is typed in and then tab is hit twice. This bug is present in the latest SAMBA_4_0 branch. This bug should be able to repro when inside the smbclient interface typing a invalid partial word such as 'foo' then hitting tab twice. Here is the output from GDB: *** glibc detected *** /home/andrew/smb_dev/samba4_latest/source/bin/smbclient: double free or corruption (!prev): 0x0000000000aaeb10 *** ======= Backtrace: ========= /lib/libc.so.6[0x2b9d0f437a7d] /lib/libc.so.6(__libc_free+0x76)[0x2b9d0f4390a6] /home/andrew/smb_dev/samba4_latest/source/bin/smbclient[0x465455] /lib/libreadline.so.5[0x2b9d0f04a811] /lib/libreadline.so.5(rl_complete_internal+0xc8)[0x2b9d0f04b9f8] /lib/libreadline.so.5(_rl_dispatch_subseq+0xcf)[0x2b9d0f04436f] /lib/libreadline.so.5(readline_internal_char+0xa4)[0x2b9d0f044a94] /lib/libreadline.so.5(readline+0x55)[0x2b9d0f044ed5] /home/andrew/smb_dev/samba4_latest/source/bin/smbclient(smb_readline+0x68)[0x8477fe] /home/andrew/smb_dev/samba4_latest/source/bin/smbclient[0x46560c] /home/andrew/smb_dev/samba4_latest/source/bin/smbclient(main+0x75d)[0x466026] /lib/libc.so.6(__libc_start_main+0xf4)[0x2b9d0f3ea374] /home/andrew/smb_dev/samba4_latest/source/bin/smbclient[0x45e489] ======= Memory map: ======== 00400000-00951000 r-xp 00000000 fb:00 31626903 /home/andrew/smb_dev/samba4_latest/source/bin/smbclient 00a51000-00a6e000 rw-p 00551000 fb:00 31626903 /home/andrew/smb_dev/samba4_latest/source/bin/smbclient 00a6e000-00ab2000 rw-p 00a6e000 00:00 0 [heap] 2b9d0e823000-2b9d0e83e000 r-xp 00000000 fb:00 3473752 /lib/ld-2.5.so 2b9d0e83e000-2b9d0e83f000 rw-p 2b9d0e83e000 00:00 0 2b9d0e877000-2b9d0e878000 rw-p 2b9d0e877000 00:00 0 2b9d0e93e000-2b9d0e93f000 r--p 0001b000 fb:00 3473752 /lib/ld-2.5.so 2b9d0e93f000-2b9d0e940000 rw-p 0001c000 fb:00 3473752 /lib/ld-2.5.so 2b9d0e940000-2b9d0e947000 r-xp 00000000 fb:00 12886076 /usr/lib/libpopt.so.0.0.0 2b9d0e947000-2b9d0ea47000 ---p 00007000 fb:00 12886076 /usr/lib/libpopt.so.0.0.0 2b9d0ea47000-2b9d0ea48000 rw-p 00007000 fb:00 12886076 /usr/lib/libpopt.so.0.0.0 2b9d0ea48000-2b9d0ea52000 r-xp 00000000 fb:00 3473853 /lib/libpam.so.0.81.6 2b9d0ea52000-2b9d0eb51000 ---p 0000a000 fb:00 3473853 /lib/libpam.so.0.81.6 2b9d0eb51000-2b9d0eb52000 rw-p 00009000 fb:00 3473853 /lib/libpam.so.0.81.6 2b9d0eb52000-2b9d0eb57000 r-xp 00000000 fb:00 3473794 /lib/libcrypt-2.5.so 2b9d0eb57000-2b9d0ec56000 ---p 00005000 fb:00 3473794 /lib/libcrypt-2.5.so 2b9d0ec56000-2b9d0ec57000 r--p 00004000 fb:00 3473794 /lib/libcrypt-2.5.so 2b9d0ec57000-2b9d0ec58000 rw-p 00005000 fb:00 3473794 /lib/libcrypt-2.5.so 2b9d0ec58000-2b9d0ec87000 rw-p 2b9d0ec58000 00:00 0 2b9d0ec87000-2b9d0ec9f000 r-xp 00000000 fb:00 12886274 /usr/lib/libsasl2.so.2.0.22 2b9d0ec9f000-2b9d0ed9f000 ---p 00018000 fb:00 12886274 /usr/lib/libsasl2.so.2.0.22 2b9d0ed9f000-2b9d0eda0000 rw-p 00018000 fb:00 12886274 /usr/lib/libsasl2.so.2.0.22 2b9d0eda0000-2b9d0edb0000 r-xp 00000000 fb:00 3473885 /lib/libresolv-2.5.so 2b9d0edb0000-2b9d0eeaf000 ---p 00010000 fb:00 3473885 /lib/libresolv-2.5.so 2b9d0eeaf000-2b9d0eeb0000 r--p 0000f000 fb:00 3473885 /lib/libresolv-2.5.so 2b9d0eeb0000-2b9d0eeb1000 rw-p 00010000 fb:00 3473885 /lib/libresolv-2.5.so 2b9d0eeb1000-2b9d0eeb3000 rw-p 2b9d0eeb1000 00:00 0 2b9d0eeb3000-2b9d0ef25000 r-xp 00000000 fb:00 12884631 /usr/lib/libgnutls.so.13.2.2 2b9d0ef25000-2b9d0f024000 ---p 00072000 fb:00 12884631 /usr/lib/libgnutls.so.13.2.2 2b9d0f024000-2b9d0f02f000 rw-p 00071000 fb:00 12884631 /usr/lib/libgnutls.so.13.2.2 2b9d0f02f000-2b9d0f030000 rw-p 2b9d0f02f000 00:00 0 2b9d0f030000-2b9d0f065000 r-xp 00000000 fb:00 6686145 /lib/libreadline.so.5.2 2b9d0f065000-2b9d0f164000 ---p 00035000 fb:00 6686145 /lib/libreadline.so.5.2 2b9d0f164000-2b9d0f16c000 rw-p 00034000 fb:00 6686145 /lib/libreadline.so.5.2 2b9d0f16c000-2b9d0f16d000 rw-p 2b9d0f16c000 00:00 0 2b9d0f16d000-2b9d0f1ba000 r-xp 00000000 fb:00 3473831 /lib/libncurses.so.5.6 Program received signal SIGABRT, Aborted. 0x00002b9d0f3fc8d5 in raise () from /lib/libc.so.6
This is perhaps a little clearer: (gdb) bt #0 0x00002b75a7179055 in free () from /lib/libc.so.6 #1 0x0000000000465455 in completion_fn (text=0xaa2060 "foo", start=0, end=3) at client/client.c:2891 #2 0x00002b75a6d8a811 in ?? () from /lib/libreadline.so.5 #3 0x00002b75a6d8b9f8 in rl_complete_internal () from /lib/libreadline.so.5 #4 0x00002b75a6d8436f in _rl_dispatch_subseq () from /lib/libreadline.so.5 #5 0x00002b75a6d84a94 in readline_internal_char () from /lib/libreadline.so.5 #6 0x00002b75a6d84ed5 in readline () from /lib/libreadline.so.5 #7 0x00000000008477e6 in smb_readline (prompt=0xa766c0 "smb: \\> ", callback=0x46547a <readline_callback>, completion_fn=0x465054 <completion_fn>) at lib/smbreadline/smbreadline.c:134 #8 0x000000000046560c in process_stdin (ctx=0xa701c0) at client/client.c:2952 #9 0x0000000000466026 in main (argc=3, argv=0x7fff04542f18) at client/client.c:3193
Is this bug reproducible anymore? I didn't find it.
Created attachment 2889 [details] Patch to correct the segfault I was not able to reproduce this issue, but I believe I have found the cause using the stack trace provided. The reported issue was in completion_fn(), and I also found a similar case in remote_completion(). There are failure cases (which is probably why I could not reproduce) in both functions that leave counters (info.count or i) in states that do not correspond to the memory that has been successfully allocated. There are multiple ways that things can get out of sync and the errors only occur in failure cases, therefore I opted to simply check each time before calling free(). This is the least obtrusive way I can see to handle the error, as I cannot reproduce the case and therefore had to rely on test-by-inspection.
That doesn't fix it - and given that free(NULL) is usually well-behaved I didn't really expect it to. Perhaps some more gdb info might help: (gdb) run Starting program: /home/data/samba/samba4/SAMBA_4_0/source/bin/smbclient //local dc1/tmp -Uadministrator%localdcpass dos charset 'CP850' unavailable - using ASCII smb: \> foo Program received signal SIGSEGV, Segmentation fault. 0x0000003e6bc73acb in free () from /lib64/libc.so.6 (gdb) bt full #0 0x0000003e6bc73acb in free () from /lib64/libc.so.6 No symbol table info available. #1 0x000000000046374d in completion_fn (text=0xa125b0 "foo", start=<value optimized out>, end=3) at client/client.c:2928 matches = (char **) 0xa1bc00 i = 0 samelen = 0 count = 1 #2 0x0000003e6e81a231 in ?? () from /usr/lib64/libreadline.so.5 No symbol table info available. #3 0x0000003e6e81b528 in rl_complete_internal () from /usr/lib64/libreadline.so.5 No symbol table info available. #4 0x0000003e6e81442f in _rl_dispatch_subseq () from /usr/lib64/libreadline.so.5 No symbol table info available. #5 0x0000003e6e814b44 in readline_internal_char () from /usr/lib64/libreadline.so.5 No symbol table info available. #6 0x0000003e6e814f85 in readline () from /usr/lib64/libreadline.so.5 No symbol table info available. #7 0x00000000006e615f in smb_readline (prompt=0x9f7c20 "smb: \\> ", callback=0x463af0 <readline_callback>, ---Type <return> to continue, or q <return> to quit--- completion_fn=0x4635c0 <completion_fn>) at lib/smbreadline/smbreadline.c:133 ret = <value optimized out>
Created attachment 2891 [details] Updated patch OK. Got it this time. Not sure what happened earlier when I couldn't reproduce the issue. Had no problems this time seeing the issue and confirming my patch fixes it. Found almost identical code in lib/registry/tools/regshell.c that indexs the cleanup code using count instead of i. This patch changes the cleanup logic to follow that code.
Fixed in -r 24698, thanks!