Ticket History #254: krb524d -m dumps core on solaris 2.4

From ppomes@Qualcomm.com Tue Nov 26 17:23:41 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id RAA18722 for <bugs@RT-11.MIT.EDU>; Tue, 26 Nov 1996 17:23:40 -0500
Received: from zelkova.qualcomm.com by MIT.EDU with SMTP
id AA02648; Tue, 26 Nov 96 17:23:39 EST
Received: from localhost (localhost [127.0.0.1]) by zelkova.qualcomm.com (8.7.6/8.7.3) with ESMTP id OAA25876 for <krb5-bugs@mit.edu>; Tue, 26 Nov 1996 14:23:36 -0800 (PST)
Message-Id: <25874.849047016@zelkova.qualcomm.com>
Date: Tue, 26 Nov 1996 14:23:36 -0800
From: Paul Pomes <ppomes@Qualcomm.com>
Sender: ppomes@Qualcomm.com
To: krb5-bugs@MIT.EDU
Subject: krb524d -m dumps core on solaris 2.4

I haven't been able to trace this one all the way through, but here's the
stack dump:

199# dbx krb524d
Reading symbolic information for krb524d
Reading symbolic information for rtld /usr/lib/ld.so.1
Reading symbolic information for /usr/local/apps/krb5/lib/libkadm5srv.so.1.0
Reading symbolic information for /usr/local/apps/krb5/lib/libgssrpc.so.1.0
Reading symbolic information for /usr/local/apps/krb5/lib/libgssapi_krb5.so.0.1
Reading symbolic information for /usr/local/apps/krb5/lib/libkdb5.so.0.1
Reading symbolic information for /usr/local/apps/krb5/lib/libkrb4.so.0.1
Reading symbolic information for /usr/local/apps/krb5/lib/libdes425.so.0.1
Reading symbolic information for /usr/local/apps/krb5/lib/libkrb5.so.0.1
Reading symbolic information for /usr/local/apps/krb5/lib/libcrypto.so.0.1
Reading symbolic information for /usr/local/apps/krb5/lib/libdyn.so.1.0
Reading symbolic information for /usr/local/apps/krb5/lib/libcom_err.so.0.1
Reading symbolic information for /usr/lib/libsocket.so.1
Reading symbolic information for /usr/lib/libnsl.so.1
Reading symbolic information for /usr/lib/libc.so.1
Reading symbolic information for /usr/lib/libdl.so.1
Reading symbolic information for /usr/lib/libintl.so.1
Reading symbolic information for /usr/lib/libw.so.1
(dbx) run -m
Running: krb524d -m
(process id 6628)
Reading symbolic information for /usr/lib/nss_files.so.1
Reading symbolic information for /usr/lib/nss_nisplus.so.1
signal BUS (invalid address alignment) in xdr_u_int32 at line 532 in file "/usr/local/src/security/kerberos/krb5-b7/src/lib/rpc/xdr.c"
532 *up = ul;
(dbx) where
=>[1] xdr_u_int32(xdrs = 0xefffe16c, up = 0x5), line 532 in "/usr/local/src/security/kerberos/krb5-b7/src/lib/rpc/xdr.c"
[2] xdr_reference(xdrs = 0xefffe16c, pp = 0xefff9908, size = 4, proc = &xdr_u_int32(XDR *xdrs, rpc_u_int32 *up) at 0x6ff19680), line 84 in "/usr/local/src/security/kerberos/krb5-b7/src/lib/rpc/xdr_reference.c"
[3] xdr_rmtcallres(xdrs = 0xefffe16c, crp = 0xefffe05c), line 154 in "/usr/local/src/security/kerberos/krb5-b7/src/lib/rpc/pmap_rmt.c"
[4] xdr_accepted_reply(xdrs = 0xefffe16c, ar = 0xefffe090), line 99 in "/usr/local/src/security/kerberos/krb5-b7/src/lib/rpc/rpc_prot.c"
[5] xdr_union(xdrs = 0xefffe16c, dscmp = 0xefffe08c, unp = 0xefffe090 "", choices = 0x6ff2f4f8, dfault = (nil)), line 575 in "/usr/local/src/security/kerberos/krb5-b7/src/lib/rpc/xdr.c"
[6] xdr_replymsg(xdrs = 0xefffe16c, rmsg = 0xefffe084), line 152 in "/usr/local/src/security/kerberos/krb5-b7/src/lib/rpc/rpc_prot.c"
[7] __nis_cast_proc(0x2bec0, 0x2bec4, 0x2, 0x0, 0x2becc, 0x2bec4), at 0x6fc8e68c
[8] __nis_cast(0x293a0, 0x2, 0xefffe31c, 0xefffe27c, 0x5, 0x0), at 0x6fc8e830
[9] __nis_select_replica(0x293a0, 0x2, 0xefffe3a0, 0xefffe31c, 0x1, 0x0), at 0x6fc8bd98
[10] __bind_rpc(0x0, 0xfffffffe, 0x0, 0x10003, 0x0, 0x1), at 0x6fc8c90c
[11] __nis_get_server(0xefffe938, 0x10003, 0x0, 0x0, 0x293a0, 0x2), at 0x6fc8d1c4
[12] __nis_core_lookup(0x1, 0xffffffef, 0x1, 0x0, 0x0, 0x0), at 0x6fc8b54c
[13] nis_list(0xefffeec8, 0x10003, 0x0, 0x0, 0x0, 0x2b8b0), at 0x6fc82728
[14] _nss_nisplus_lookup(0x2b8b0, 0xeffff390, 0x6fb246d8, 0x13b5c, 0x0, 0x1), at 0x6fb217c0
[15] _nss_search(0x30, 0x2b8b0, 0x4, 0xeffff390, 0x1, 0x1), at 0x6fbca538
[16] _switch_getservbyname_r(0x13b5c, 0x13b64, 0x25cbc, 0x25ccc, 0x400, 0x0), at 0x6fc5c3b8
[17] _get_hostserv_inetnetdir_byname(0x278c0, 0xeffff504, 0xeffff4fc, 0x27d10, 0xffffffff, 0x0), at 0x6fc5ba64
[18] getservbyname_r(0x13b5c, 0x13b64, 0x25cbc, 0x25ccc, 0x400, 0x278c0), at 0x6fcf4598
[19] main(argc = 0, argv = 0xeffff69c), line 130 in "krb524d.c"


Responsible-Changed-From-To: gnats-admin->krb5-unassigned
Responsible-Changed-By: hartmans
Responsible-Changed-When: Sat Nov 30 12:36:58 1996
Responsible-Changed-Why:
file bug

Responsible-Changed-From-To: krb5-unassigned->krb5-unassigned
Responsible-Changed-By: tlyu
Responsible-Changed-When: Sat Nov 30 18:10:18 1996
Responsible-Changed-Why:

Changed to krb5-kdc, which is the more correct category.


From: Tom Yu <tlyu@MIT.EDU>
To: hartmans@MIT.EDU, krbdev@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-misc/254: krb524d -m dumps core on solaris 2.4
Date: Sat, 30 Nov 1996 18:09:45 -0500

Is there any reason this is assigned a low priority? I haven't had
time to verify the failure myself, but it seems that it may be the
result of using configuring nsswitch to use NIS for getservbyname.

---Tom

State-Changed-From-To: open-analyzed
State-Changed-By: tlyu
State-Changed-When: Sun Mar 16 02:11:30 1997
State-Changed-Why:

This needs more looking at, still. The xdr components of the stack
trace worry me a lot.


From: Tom Yu <tlyu@MIT.EDU>
To: ppomes@Qualcomm.com
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/254: krb524d -m dumps core on solaris 2.4
Date: Sun, 16 Mar 1997 02:13:12 -0500

Hi. You sent us a bug report about krb524d... are you still seeing
this failure mode under krb5-1.0? If so, could you please let us
know? I suspect that there may be a poor interaction between gssrpc
and the rpc library provided with Solaris/NIS.

---Tom

From: Paul Pomes <ppomes@Qualcomm.com>
To: Tom Yu <tlyu@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/254: krb524d -m dumps core on solaris 2.4
Date: Mon, 24 Mar 1997 08:13:08 -0800

The problem with krb524d has gone away after the upgrade to Solaris 2.5.1.

/pbp

State-Changed-From-To: analyzed-closed
State-Changed-By: tlyu
State-Changed-When: Thu Feb 19 18:19:32 1998
State-Changed-Why:

This is rather stale, and in addition, recent changes to gssrpc should
fix some of this.