[OpenAFS-devel] YDL 5.0.2... it gets weirder

[Marcus Watts]

Atro Tossavainen <atro.tossavainen+openafs@helsinki.fi> writes:
> Date:    Fri, 02 Nov 2007 11:22:50 +0200
> To:      openafs-devel@openafs.org
> From:    Atro Tossavainen <atro.tossavainen+openafs@helsinki.fi>
> Subject: Re: [OpenAFS-devel] YDL 5.0.2... it gets weirder
> 
> I wrote a while ago:
> 
> > > > Now that I look at that file, it makes perfect sense - it's included
> > > > for Alpha, AMD64 and s390x Linuxes already.
> > >
> > > And does life get better?
> >
> > FSVO thereof.  The run-time linker doesn't complain about being unable
> > to load pam_afs.so any more.  It loads and "debug"s nicely, it just
> > doesn't work.  I've tcpdumped the traffic on the problem host and it's
> > not talking to the AFS servers.
> >
> > I attached a strace to the login process and it seems to be going through
> > the motions all right, but it segfaults at the end.  The same also
> > happens with klog, it just segfaults as before.  I need to check that
> > the strace logs don't contain anything that could be used to compromise
> > our systems and then I can post them.
> 
> Here they are, finally.
> 
> http://www.biocenter.helsinki.fi/~atossava/pam_afs.so.txt
> http://www.biocenter.helsinki.fi/~atossava/klog.txt

Those don't say much - just that it died soon after doing something
strange with ldap.

What would be more interesting is a stack backtrace and
general machine environment at time of crash.

2 ways:

via core dump:
	sh
	ulimit -c unlimited
	/usr/src/openafs-1.4.3/ppc_linux26/dest/bin/klog -setpag userid
	...
	gdb klog core

via debugger
	gdb /usr/src/openafs-1.4.3/ppc_linux26/dest/bin/klog
	run -setpag userid

in both cases:
	where
	info r
	x/30i $pc

If you built with "-g", you may also be able to
look more easily at additional program state information.

At a shear guess, it looks like you're loading /lib/libcom_err.so.2.
Where does this come from?
That could cause interesting behavior, especially on 64-bit machines.

				-Marcus Watts