[OpenAFS-devel] Re: Weird interaction between libnss-afs and aklog

[Jakub Witkowski]

Dnia 2009-11-24, o godz. 09:08:15
Andrew Deason <adeason@sinenomine.net> napisa=C5=82(a):

> On Tue, 24 Nov 2009 14:19:43 +0100
> Jakub Witkowski <jpw@wszib.edu.pl> wrote:
>=20
> > After some hunting, I narrowed the problem down to this line in
> > aklog_main.c:
> >=20
> >  if ((pwd =3D getpwuid(getuid())) !=3D NULL)
>=20
> This specific line is where the crash occurred? Do you still have the
> core, and can you give the backtrace?
>=20
> > My question is, is this a sign of some bug lurking in libnss-afs?=20
> > If not, can this code be made optional or reworked to something a
> > little more robust?
>=20
> If getpwuid() were segfaulting, my guess is you would see a lot more
> segfaults/aborts than in just aklog. We're not testing pwd->pw_dir for
> NULL in aklog, but I'm not sure if it's possible for it to be.
>=20
> You may want to continue this in a bug report (by sending something to
> openafs-bugs@openafs.org), though it may not be a bug in aklog.
>=20

The backtrace follows:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fd9c68ac700 (LWP 22199)]
0x000000000042713f in rxi_Start (event=3D0x0, arg0=3D0x1380e00, arg1=3D0x0,
istack=3D0) at rx.c:5287 5287	    struct rx_peer *peer =3D
call->conn->peer; (gdb) backtrace
#0  0x000000000042713f in rxi_Start (event=3D0x0, arg0=3D0x1380e00,
arg1=3D0x0, istack=3D0) at rx.c:5287 #1  0x00007fd9c4bff4f0 in rxi_ReadProc
() from /lib/libnss_afs.so.2 #2  0x00007fd9c4bffa70 in rx_ReadProc32 ()
from /lib/libnss_afs.so.2 #3  0x00007fd9c4c01296 in xdrrx_getint32 ()
from /lib/libnss_afs.so.2 #4  0x00007fd9c4c00943 in afs_xdr_u_int ()
from /lib/libnss_afs.so.2 #5  0x00007fd9c4c010b1 in afs_xdr_array ()
from /lib/libnss_afs.so.2 #6  0x00007fd9c4be2f15 in xdr_namelist ()
from /lib/libnss_afs.so.2 #7  0x00007fd9c4be2149 in PR_IDToName ()
from /lib/libnss_afs.so.2 #8  0x00007fd9c4bd6e3e in ubik_Call ()
from /lib/libnss_afs.so.2 #9  0x00007fd9c4bd561d in ptsid2name
(uid=3D1281, buffer=3D0x7fff466043f8, buflen=3D0x7fff466043f0) at
nss_afs.c:133 #10 0x00007fd9c4bd62d0 in _nss_afs_getpwuid_r (uid=3D1281,
result_buf=3D0x7fd9c5dc18a0, buffer=3D0x1344ab0 "=EF=BF=BD\021=EF=BF=BD=EF=
=BF=BD=EF=BF=BD\177",
buflen=3D1024, errnop=3D0x7fd9c68ac698) at nss_afs.c:447 #11
0x00007fd9c5b0f102 in getpwuid_r () from /lib/libc.so.6 #12
0x00007fd9c5b0e9cf in getpwuid () from /lib/libc.so.6 #13
0x0000000000408254 in aklog (argc=3D1, argv=3D0x7fff466099d8) at
aklog_main.c:1441 #14 0x0000000000405b47 in main (argc=3D1,
argv=3D0x7fff466099d8) at aklog.c:14

For me, it's intriguing that this /only/ happens for aklog. I have
tested various other tools, including a short test program to directly
test of getuid and getpwuid, everything works like it should.


Jakub Witkowski