in 3.0 beta 3 (--with-pam, SuSE 2.4 kernel), wbinfo -u (or -g) show users
(groups) (wbinfo -p does not work), net ads users(groups) work fine, but getent
passwd end like this:
[2003/07/17 09:12:16, 0] lib/fault.c:fault_report(37)
INTERNAL ERROR: Signal 11 in pid 1603 (3.0.0beta3)
Please read the appendix Bugs of the Samba HOWTO collection
[2003/07/17 09:12:16, 0] lib/fault.c:fault_report(39)
[2003/07/17 09:12:16, 0] lib/util.c:smb_panic(1462)
PANIC: internal error
[2003/07/17 09:12:16, 0] lib/util.c:smb_panic(1469)
BACKTRACE: 17 stack frames:
#0 /usr/local/samba/sbin/winbindd(smb_panic+0x16c) [0x80b26dc]
#1 /usr/local/samba/sbin/winbindd(dbgtext+0x193) [0x80a1e73]
#2 /usr/local/samba/sbin/winbindd(dbgtext+0x1f2) [0x80a1ed2]
#3 /lib/libc.so.6(__libc_sigaction+0x138) [0x402467f8]
#4 /lib/libc.so.6(malloc+0xe4) [0x4028bf64]
#5 /usr/local/samba/sbin/winbindd(cli_initialise+0x10a) [0x80c54ba]
#6 /usr/local/samba/sbin/winbindd(cli_full_connection+0x36) [0x80c8206]
#7 /usr/local/samba/sbin/winbindd(winbindd_priv_pipe_dir+0x421) [0x8078901]
#8 /usr/local/samba/sbin/winbindd(winbindd_priv_pipe_dir+0x80a) [0x8078cea]
#9 /usr/local/samba/sbin/winbindd(cm_get_netlogon_cli+0x113) [0x80793d3]
#10 /usr/local/samba/sbin/winbindd(winbindd_pam_auth_crap+0x576) [0x8076e96]
#11 /usr/local/samba/sbin/winbindd(unbecome_root+0x5ed) [0x806c4ad]
#12 /usr/local/samba/sbin/winbindd(winbind_process_packet+0x20) [0x806c770]
#13 /usr/local/samba/sbin/winbindd(winbind_client_read+0x842) [0x806cfe2]
#14 /usr/local/samba/sbin/winbindd(main+0x49a) [0x806d54a]
#15 /lib/libc.so.6(__libc_start_main+0xbe) [0x402357ee]
#16 /usr/local/samba/sbin/winbindd(_start+0x21) [0x806bdd1]
Jiri, do you have any non-ASCII (international) characters in any of your
usernames? Given your country code I suspect the answer is yes. (-:
Gerald, I started with running winbindd under valgrind and doing a 'getent
passwd'. It didn't pass due to some uninitialised memory in strchr_w():
==23233== Conditional jump or move depends on uninitialised value(s)
==23233== at 0x80BAF58: strchr_w (lib/util_unistr.c:399)
==23233== by 0x80B7D16: strchr_m (lib/util_str.c:1096)
==23233== by 0x80C6F5A: alloc_sub_basic (lib/substitute.c:487)
==23233== by 0x809EA87: lp_string (param/loadparm.c:1548)
I've tracked it down to some dodginess in the alloc_sub_basic() function in
lib/substitute.c. When the string to be substituted is a UTF8 string with
actual high-bit ascii characters in it (i.e two byte characters), the p++ at the
end of the for loop in alloc_sub_basic() "unaligns" the string, i.e we are now
pointing in the middle of a two-character UTF8 character. When we next go
around the loop there is perhaps some uninitialised memory returned by the iconv
function which trips up valgrind. I think it's another one of these bugs caused
by ignoring the error return from character set conversion. )-:
- Changing the p++ in alloc_sub_basic() to p += 2 makes valgrind happy. Now
how dodgy is that? The p++ is wrong anyway as it looks like it advances the
pointer past the % delimiter but at this point we have already replaced %U by
the smb_user name so we end up being one character ahead in to the substitution.
You may have to step this function through gdb as it is quite complicated. We
should really do p += strlen(<whatever we substituted>) instead.
- Setting the 'unix character set' to something like iso-8859-1 makes valgrind
happy as well, presumably because we no longer convert strings to UTF8 and avoid
the whole unaligned character beartrap in the first place.
- This could be totally unrelated to the reporter's problem, but I though we
should definitely be able to pass a simple valgrind of getent password. The
posted stack trace suggests some weirdness going on anyway as cli_initialise()
shouldn't really fail on a simple malloc for any obvious reason that I can think of.
- I had a user called ÄäÖö (that's Adiaeresis, adiaeresis, Odiaeresis,
odiaeresis in case bugzilla mucks it up) which triggers the valgrind error in
Let me know what you think. (-: I'm going to do something else for a while -
my head hurts.
looks like another extended character issue
jra, any ideas ion this one?
reseting target milestone. 3.0.1 has been frozen. WIll have to
marking as fixed based on the recent mb string work by jra.
originally reported against 3.0.0beta3. CLeaning out
non-production release versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.