Bug 3082 - Winbindd internal error doing group lookup on x86_64
Summary: Winbindd internal error doing group lookup on x86_64
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: winbind (show other bugs)
Version: 3.0.20
Hardware: Other Linux
: P3 major
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2005-09-09 12:25 UTC by Robin Hill
Modified: 2005-09-11 04:08 UTC (History)
0 users

See Also:

smb.conf file (938 bytes, text/plain)
2005-09-10 03:13 UTC, Robin Hill
no flags Details
Winbindd debug output (winbindd -d 10 -i) (112.03 KB, text/plain)
2005-09-10 03:15 UTC, Robin Hill
no flags Details
Winbinndd debug output (winbindd -d 10 -S -F) (4.84 KB, text/plain)
2005-09-10 03:16 UTC, Robin Hill
no flags Details
Backtrace output (16.78 KB, text/plain)
2005-09-10 13:36 UTC, Robin Hill
no flags Details
Valgrind output (38.96 KB, text/plain)
2005-09-10 16:57 UTC, Robin Hill
no flags Details
proposed patch (419 bytes, patch)
2005-09-11 01:16 UTC, Volker Lendecke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Hill 2005-09-09 12:25:41 UTC
Calling 'wbinfo -r username' causes an internal error on x86_64 platform:

*** glibc detected *** free(): invalid next size (fast): 0x000000000077fd50 ***
INTERNAL ERROR: Signal 6 in pid 9230 (3.0.20-3-devel-SUSE)
Please read the appendix Bugs of the Samba HOWTO collection
smb_panic: clobber_region() last called from [sprintf_append(2206)]
PANIC: internal error
BACKTRACE: 15 stack frames:
 #0 winbindd(smb_panic2+0x108) [0x495438]
 #1 winbindd [0x4831b6]
 #2 /lib64/tls/libc.so.6 [0x2aaaab95ff00]
 #3 /lib64/tls/libc.so.6(gsignal+0x39) [0x2aaaab95fe79]
 #4 /lib64/tls/libc.so.6(abort+0x13f) [0x2aaaab96148f]
 #5 /lib64/tls/libc.so.6 [0x2aaaab9945d3]
 #6 /lib64/tls/libc.so.6 [0x2aaaab999153]
 #7 /lib64/tls/libc.so.6(__libc_free+0x77) [0x2aaaab99a8a7]
 #8 winbindd [0x44db5d]
 #9 winbindd(async_request+0x9a) [0x44e1fa]
 #10 winbindd(init_child_connection+0x148) [0x43b9f8]
 #11 winbindd(rescan_trusted_domains+0xee) [0x43c18e]
 #12 winbindd(main+0x415) [0x434235]
 #13 /lib64/tls/libc.so.6(__libc_start_main+0xea) [0x2aaaab94e54a]
 #14 winbindd [0x432eaa]
INTERNAL ERROR: Signal 11 in pid 9301 (3.0.20-3-devel-SUSE)
Please read the appendix Bugs of the Samba HOWTO collection
smb_panic: clobber_region() last called from [sprintf_append(2206)]
PANIC: internal error
Comment 1 Volker Lendecke 2005-09-09 15:15:49 UTC
Is this reproducable? If yes, could you please post your smb.conf and full debug
level 10 logs from the start of winbind to that crash?


Comment 2 Robin Hill 2005-09-10 03:13:47 UTC
Created attachment 1429 [details]
smb.conf file
Comment 3 Robin Hill 2005-09-10 03:15:52 UTC
Created attachment 1430 [details]
Winbindd debug output (winbindd -d 10 -i)
Comment 4 Robin Hill 2005-09-10 03:16:12 UTC
Created attachment 1431 [details]
Winbinndd debug output (winbindd -d 10 -S -F)
Comment 5 Robin Hill 2005-09-10 03:19:26 UTC
Yes, it's entirely reproducible - I've uploaded the smb.conf file and 2 
different logs (with different start parameters).  The same winbindd version and 
smb.conf file works perfectly on 32-bit systems.  wbinfo -u, -g and -n all work  
fine on both systems.
Comment 6 Volker Lendecke 2005-09-10 10:47:00 UTC
I'm afraid but even with those logfiles I don't see where the bug might be,
apparently there are no debug symbols activated. Do you use some precompiled
binaries? If you have the chance to compile 3.0.20 yourself, could you please
compile after doing a configure.developer? This enables debugging symbols. If
that's done, a full backtrace would be handy. You can do that with setting
'panic action = /bin/sleep 3600' and run the script "backtrace" from
examples/debugging on the parent process of the sleep command, the one that


Comment 7 Robin Hill 2005-09-10 13:36:13 UTC
Created attachment 1432 [details]
Backtrace output
Comment 8 Volker Lendecke 2005-09-10 15:47:01 UTC
The backtrace you sent in (thanks) does not really reveal anything that shows
where the real problem is, sorry for that.

Next escalation would be running winbind under valgrind, luckily the latest
version does support x86_64. Unter www.valgrind.org you find the software, and
if you run it with 

valgrind -v --num-callers=20 --tool=memcheck --trace-children=yes 

it should show about everything that might lead to a segmentation violation.

Thanks for your patience,

Comment 9 Robin Hill 2005-09-10 16:57:05 UTC
Under Valgrind it works perfectly - no panics and it returns the results 
normally :(  I'll upload the Valgrind output anyway, in case you can spot 
anything in there.
Comment 10 Robin Hill 2005-09-10 16:57:19 UTC
Created attachment 1433 [details]
Valgrind output
Comment 11 Volker Lendecke 2005-09-11 01:16:48 UTC
Created attachment 1434 [details]
proposed patch

A program that segfaults to work under valgrind is quite normal. But meanwhile
it spits out errors. The "invald write" lines give some hints. Could you try
the attached patch?


Comment 12 Robin Hill 2005-09-11 03:58:28 UTC
Yes, that works perfectly now.  Many thanks for your help :)
Comment 13 Volker Lendecke 2005-09-11 04:08:59 UTC
Thanks for your patience. This is checked into svn now, so it will show up in