Re: xemacs error with LDAP and Linux 2.4.2
Brian> I just upgraded from Linux 2.4.1 to Linux 2.4.2, and
Brian> everything was going fine. I was using xemacs to read my
Brian> news, etc, when suddenly xemacs disappears. Strange. I have
Brian> never had xemacs crash quite that badly before. Restart
Brian> xemacs. Nothing happens.
Brian> Restart at command prompt:
Brian> [524] [snoopy:bam] ~ >xemacs
Brian> xemacs: options.c:326: ldap_set_option: Assertion `( ( ld
Brian> )->ld_options.ldo_valid == 0x2 )' failed. zsh: segmentation
Brian> fault xemacs
Brian> yuck.
I agree. "options.c" doesn't exist in the xemacs source, so it's
coming from somewhere else (ldap source maybe. don't have it handy).
My first thought was that xemacs is linked with libldap.so.2 and maybe
the libnss_ldap.so module is expecting ldap functions in a different
form?
Brian> I have tried restarting slapd, just in case, but it didn't
Brian> help. Everything else that uses LDAP seems to work fine, and
Brian> I am quick to blame Linux 2.4.2: "ITS ALL YOUR FAULT" <grin>.
Brian> The only thing that works is if I disable LDAP lookups for
Brian> passwd (either in /etc/nsswitch, or by inserting an entry for
Brian> me in /etc/passwd).
Brian> LISP gave the following LIST stack trace (the first time it
Brian> crashed, from $HOME/.gnome-errors):
Brian> [...] Selection retrieval failed Selection retrieval failed
Brian> xemacs: options.c:326: ldap_set_option: Assertion `( ( ld
Brian> )->ld_options.ldo_valid == 0x2 )' failed.
Brian> Fatal error (6). Your files have been auto-saved. Use `M-x
Brian> recover-session' to recover them.
Brian> If you have access to the PROBLEMS file that came with your
Brian> version of XEmacs, please check to see if your crash is
Brian> described there, as there may be a workaround available.
Brian> Otherwise, please report this bug by running the send-pr
Brian> script included with XEmacs, or selecting `Send Bug Report'
Brian> from the help menu. As a last resort send ordinary email to
Brian> `crashes@xemacs.org'. *MAKE SURE* to include the information
Brian> in the command M-x describe-installation.
Brian> If at all possible, *please* try to obtain a C stack
Brian> backtrace; it will help us immensely in determining what went
Brian> wrong. To do this, locate the core file that was produced as
Brian> a result of this crash (it's usually called `core' and is
Brian> located in the directory in which you started the editor, or
Brian> maybe in your home directory), and type
Brian> gdb /usr/bin/xemacs core
Brian> then type `where' when the debugger prompt comes up. (If you
Brian> don't have GDB on your system, you might have DBX, or XDB, or
Brian> SDB. A similar procedure should work for all of these. Ask
Brian> your system administrator if you need more help.)
Brian> Lisp backtrace follows:
Brian> user-real-login-name() url-setup-privacy-info()
This function (user-real-login-name) is:
DEFUN ("user-real-login-name", Fuser_real_login_name, 0, 0, 0, /*
Return the name of the user's real uid, as a string.
This ignores the environment variables LOGNAME and USER, so it differs from
`user-login-name' when running under `su'.
*/
())
{
struct passwd *pw = getpwuid (getuid ());
/* #### - I believe this should return nil instead of "unknown" when pw==0 */
#ifdef MSDOS
/* We let the real user name default to "root" because that's quite
accurate on MSDOG and because it lets Emacs find the init file.
(The DVX libraries override the Djgpp libraries here.) */
Lisp_Object tem = build_string (pw ? pw->pw_name : "root");/* no gettext */
#else
Lisp_Object tem = build_string (pw ? pw->pw_name : "unknown");/* no gettext */
#endif
return tem;
}
So it looks like something in getpwuid is messing up.
Is this xemacs or xemacs-gtk? xemacs-gtk just started compiling with
ldap support. This might be the causing error. And I think I noticed
pam and libnss-ldap updates recently as well (don't quote me on that
though).
Jim
--
@James LewisMoss <dres@debian.org> | Blessed Be!
@ http://jimdres.home.mindspring.com | Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach
Reply to: