Bug 11886 - smbclient goes into a tight loop after connecting
smbclient goes into a tight loop after connecting
Status: NEEDINFO
Product: Samba 4.1 and newer
Classification: Unclassified
Component: libsmbclient
4.3.9
x64 FreeBSD
: P5 critical
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-05-01 21:32 UTC by Mikhail T.
Modified: 2016-06-19 16:36 UTC (History)
1 user (show)

See Also:


Attachments
Output of smbclient running with `-d 10' (7.15 KB, text/plain)
2016-05-01 21:32 UTC, Mikhail T.
no flags Details
Last 1000 lines of the kdump trace of smbclient process (50.05 KB, text/plain)
2016-05-01 21:35 UTC, Mikhail T.
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail T. 2016-05-01 21:32:38 UTC
Created attachment 12055 [details]
Output of smbclient running with `-d 10'

For years I've been using Samba-3 client to push FreeBSD backups onto a harddrive inside a set-top box running Samba-server (3.0.30).

After a recent upgrade of the client to 4.3.8 (without any changes to the server), I see the client going into a tight loop upon connecting -- consuming 100% of the CPU, not doing anything, and requiring a SIGKILL to kill.

If I run it interactively, I can see it connecting and giving me the command-prompt -- and THEN becoming unresponsive.
Comment 1 Mikhail T. 2016-05-01 21:35:58 UTC
Created attachment 12056 [details]
Last 1000 lines of the kdump trace of smbclient process

Samba is compiled here with the options set thus:
        ACL_SUPPORT    : on
        ADS            : off
        AD_DC          : off
        AIO_SUPPORT    : on
        AVAHI          : off
        BIND910        : off
        BIND99         : off
        CUPS           : on
        DEBUG          : off
        DEVELOPER      : off
        DNSUPDATE      : off
        DOCS           : off
        EXP_MODULES    : off
        FAM            : on
        LDAP           : off
        MANPAGES       : on
        MDNSRESPONDER  : off
        NSUPDATE       : off
        PAM_SMBPASS    : off
        PTHREADPOOL    : off
        QUOTAS         : off
        SYSLOG         : on
        UTMP           : on
Comment 2 Mikhail T. 2016-05-01 21:54:45 UTC
FWIW, recompiling with AIO_SUPPORT set to "off" didn't help either... Here is the full set of configure-arguments:

--mandir="/opt/man"  --sysconfdir="/opt/etc"  --includedir="/opt/include/samba4"  --datadir="/opt/share/samba43"  --libdir="/opt/lib"  --with-pammodulesdir="/opt/lib"  --with-privatelibdir="/opt/lib/samba"  --with-modulesdir="/opt/lib/shared-modules"  --with-pkgconfigdir="/opt/libdata/pkgconfig"  --localstatedir="/var"  --with-piddir="/var/run/samba4"  --with-sockets-dir="/var/run/samba4"  --with-privileged-socket-dir="/var/run/samba4"  --with-lockdir="/var/db/samba4"  --with-statedir="/var/db/samba4"  --with-cachedir="/var/db/samba4"  --with-privatedir="/var/db/samba4/private"  --with-logfilebase="/var/log/samba4" --with-pam  --with-iconv  --with-winbind  --without-gettext  --with-sendfile-support  --builtin-libraries=smbclient   --with-acl-support --without-ad-dc --without-aio-support --disable-avahi --disable-dnssd --enable-cups --enable-iprint --without-dnsupdate --with-fam --without-pam_smbpass --disable-pthreadpool --without-quotas --with-syslog --with-utmp --without-ads --without-ldap --bundled-libraries="!talloc,!tevent,!tdb,!ldb,com_err" --with-shared-modules="vfs_zfsacl,vfs_zfsacl" --prefix=/opt  -j4
Comment 3 Mikhail T. 2016-05-02 16:03:37 UTC
FreeBSD builds Samba-ports against a separately built port of tevent. That port currently builds tevent-0.9.28, whereas the version bundled with samba-4.3.8 is only 0.9.25.

Thinking, that might be the problem, I rebuilt Samba with the bundled tevent and tried again. Did not help...

I have another machine on another network, which backs up to an identical set-top box -- those backups continued to work properly after the same upgrade. I can not identify anything different between the working and the non-working smbclients. If there is a particular detail you'd like me to check/compare on them, I'm eager to try.

I can also arrange for a Unix login on either or both systems -- they are Internet-accessible. Just post your desired /etc/passwd line and the public ssh-key here. Thanks!
Comment 4 Mikhail T. 2016-05-02 17:37:40 UTC
Upgrading to 4.3.9 did not help either -- same problem. Bumping the "Version" field of this ticket.
Comment 5 Jeremy Allison 2016-05-04 20:44:34 UTC
Can you get a system call log whilst it's looping ? Also, build with -g and then get a full backtrace again whilst smbclient is looping.
Comment 6 Mikhail T. 2016-05-04 22:10:41 UTC
(In reply to Jeremy Allison from comment #5)
> Can you get a system call log whilst it's looping ?

That's exactly, why my second attachment contains already.

> build with -g and then get a full backtrace again whilst smbclient is looping

Will do...
Comment 7 Mikhail T. 2016-05-05 17:18:49 UTC
(In reply to Jeremy Allison from comment #5)
> Also, build with -g and then get a full backtrace again whilst smbclient is looping.

This is proving harder, than we expected. Although the entire samba is compiled with -g, and neither the smbclient nor the just-built shared libraries are stripped, the stack is not readable:

(gdb) where
#0  0x000000080453132a in ?? ()
#1  0x00000008055fb29b in ?? ()
#2  0x00007fffffffda40 in ?? ()
#3  0x00000000572b638d in ?? ()
#4  0x00000000000882ca in ?? ()
#5  0x00000008100c7160 in ?? ()
#6  0x0000000810039320 in ?? ()
#7  0x0000000000000001 in ?? ()
#8  0x00000008100c7160 in ?? ()
#9  0x00000008055fdc07 in ?? ()
#10 0x00007fffffffdab0 in ?? ()
#11 0x00000008055f905e in ?? ()
#12 0x0000000800000000 in ?? ()
#13 0x00000000d6938587 in ?? ()
#14 0x000000000036ee78 in ?? ()
#15 0x000000000003066b in ?? ()
#16 0x0000000000000000 in ?? ()
(gdb) info threads
(gdb)

The already posted syscall trace may have to suffice...
Comment 8 Jeremy Allison 2016-05-05 19:52:51 UTC
OK, poll() returns EINVAL. Is there a setting on your strace that allows dumping of the contents of the parameters to the poll() call ?
Comment 9 Mikhail T. 2016-06-19 16:36:17 UTC
(In reply to Jeremy Allison from comment #8)
I think, it is trying to talk to DBUS -- and failing, because DBUS-daemon is not running...