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. )-: Some notes: - 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 getent passwd. 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 re-evaluate these.
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.
database cleanup