Winbind using 100% CPU

[Andreas Schneider]

On Thursday 11 April 2013 15:06:45 Dylan Klomparens wrote:
> Here are two valgrind reports, one with leak-check=summary (the default),
> and the other with leak-check=full (very verbose).

Hi Dylan,

Thanks for the logs, I don't see anything really problematic just

 ==1646== Syscall param writev(vector[...]) points to uninitialised byte(s)

which is probably from dcerpc_add_auth_footer() but this is not the codepath 
from the backtrace. Did you run into the 100% problem with running under 
valgrind?

> The exact command line
> is at the top of each file. The Samba executable I am running is from a
> Fedora package so debug symbols are not included in the executable. Thus, I
> couldn't run the desired gdb commands.

Please install the debuginfo package so we get the symbols. You can do this 
with:

debuginfo-install samba

> Is this the first time this bug has been encountered?

More or less. Did winbind hit the 100% problem while running with valgrind?

> I can try and download/compile the source and attempt to
> re-capture the problem with more information if that is necessary.

debuginfo-install samba

Then please get us a full backtrace and the talloc report. After that please 
run again with valgrind.


Thanks,


	-- andreas



> -- Dylan
> 
> On Thu, Apr 11, 2013 at 10:31 AM, Andreas Schneider <asn at samba.org> wrote:
> > On Thursday 11 April 2013 16:17:51 Andreas Schneider wrote:
> > > On Thursday 11 April 2013 09:58:33 Dylan Klomparens wrote:
> > > > (Re-posting on this email list per Jeremy Allison's request.)
> > > > 
> > > > I am trying to figure out why winbind is using 100% CPU on my file
> > 
> > server.
> > 
> > > > I am using Samba version 4.0.4. Everything is fine for a few minutes
> > 
> > when
> > 
> > > > I
> > > > start winbind, however after a while it begins using 100% CPU. I
> > 
> > haven't
> > 
> > > > been able to narrow down what triggers this CPU usage spike, but I did
> > > > attach the GNU debugger to find out what's going on in the process.
> > > > The
> > > > backtrace revealed this information:
> > > > 
> > > > #0  0x000000000041cf30 in _talloc_free at plt ()
> > > > #1  0x0000000000452320 in winbindd_reinit_after_fork ()
> > > > #2  0x00000000004524e6 in fork_domain_child ()
> > > > #3  0x0000000000453585 in wb_child_request_trigger ()
> > > > #4  0x000000381d2048e2 in tevent_common_loop_immediate () from
> > > > /lib64/libtevent.so.0
> > > > #5  0x00007fbed6b98e17 in run_events_poll () from
> > 
> > /lib64/libsmbconf.so.0
> > 
> > > > #6  0x00007fbed6b9922e in s3_event_loop_once () from
> > > > /lib64/libsmbconf.so.0
> > > > #7  0x000000381d204060 in _tevent_loop_once () from
> > 
> > /lib64/libtevent.so.0
> > 
> > > > #8  0x000000000042049a in main ()
> > > 
> > > If you get to this backtrace again, please call
> > > 
> > > bt full
> > > 
> > > and also do:
> > > 
> > > p talloc_report_full(NULL, fopen("/tmp/talloc_report.log","w"))
> > > 
> > > attach the log.
> > 
> > Oh, are you able to run it with valgrind?
> > 
> > valgrind --tool=memcheck -v --num-callers=20 --trace-children=yes
> > /path/to/winbindd
> > 
> > 
> > --
> > Andreas Schneider                   GPG-ID: F33E3FC6
> > Samba Team                             asn at samba.org
> > www.samba.org
-- 
Andreas Schneider                   GPG-ID: F33E3FC6
Samba Team                             asn at samba.org
www.samba.org