> Those don't say much - just that it died soon after doing something
> strange with ldap.
Eliminating the LDAP and hopefully quite a bit of noise from the
equation isn't an issue.
> What would be more interesting is a stack backtrace and
> general machine environment at time of crash.
Let's see if I can get that done for you all a little faster than
the previous reports.
> If you built with "-g", you may also be able to look more easily at
> additional program state information.
I don't think I did, but rebuilding is not a biggie.
> At a shear guess, it looks like you're loading /lib/libcom_err.so.2.
> Where does this come from?
# rpm -qf /lib/libcom_err.so.2
e2fsprogs-libs-1.38-12
However,
# ldd kauth/klog
linux-vdso32.so.1 => (0x00100000)
libc.so.6 => /lib/libc.so.6 (0x0f570000)
/lib/ld.so.1 (0x0ffc0000)
# ldd /lib/security/pam_afs.so
linux-vdso32.so.1 => (0x00100000)
libc.so.6 => /lib/libc.so.6 (0x6fddb000)
/lib/ld.so.1 (0x20000000)
> That could cause interesting behavior, especially on 64-bit machines.
This is a first-generation Xserve G4, definitely not 64-bit.
--
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
