OK. I gave in and try valgrind. It crashed.

cli_list_new's call of do_list looks suspicious, probably via

../source/client/client.c:539: cli_list(cli, head, attribute, do_list_helper, NULL);


../source/client/client.c:558: if (cli_list(cli, mask, attribute, do_list_helper, NULL) == -1) {

kevin@nereocystis:~$ valgrind --leak-check=yes --show-reachable=yes smbclient '\\redbird\c$' -d 0 -U amanda -E -c 'recurse;du'
==18280== Memcheck, a memory error detector for x86-linux.
==18280== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==18280== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==18280== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==18280== For more details, rerun with: -v
--18280-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--18280-- si_code=1 Fault EIP: 0xB1259264; Faulting address: 0x0

valgrind: the `impossible' happened:
Killed by fatal signal
Basic block ctr is approximately 16950000
==18280== at 0xB003000F: vgPlain_core_panic (vg_mylibc.c:1156)
==18280== by 0xB003000E: panic (vg_mylibc.c:1152)
==18280== by 0xB003002F: vgPlain_core_panic (vg_mylibc.c:1157)
==18280== by 0xB00374E0: vg_sync_signalhandler (vg_signals.c:2191)

sched status:

Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==18280== at 0x1B9059FF: realloc (vg_replace_malloc.c:197)
==18280== by 0x80BB365: Realloc (in /usr/bin/smbclient)
==18280== by 0x8081D5C: cli_list_new (in /usr/bin/smbclient)
==18280== by 0x805F748: do_list (in /usr/bin/smbclient)

Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.

If that doesn't help, please report this bug to: valgrind.kde.org

In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.

Jeremy Allison writes:

> On Thu, Mar 03, 2005 at 01:14:47PM -0800, Kevin Dalley wrote:
>> I'm look at a serious samba bug, which involves the loss of files when
>> taking a directory listing:
>> https://bugzilla.samba.org/show_bug.cgi?id=2271
>> Unfortunately, the suggested patch causes smbclient bloat, using up 1
>> or 2 GB of memory before I give up and kill the process.
>> I removed the backup flag from the patch, and everything works the
>> same. Here is a line which causes problems, from
>> source/libsmb/clilist.c, samba-3.0.10:
>> SSVAL(param,10,/*8+*/4+2); /* continue + resume required + close
>> on end */
>> If I turn on the continue flag (8), files are lost, but smbclient no
>> longer grows to GB size. When I leave the flag off, all the files are
>> found, but the size of the running program for certain commands grows
>> to GB size.
>> What is going on, where can I look for a memory leak?

> Run under valgrind. Now you've reported this problem with it that's what I'm going
> to do before applying the patch :-).
> Thanks,
> Jeremy.

Kevin Dalley