Ticket History #29: randkey_principal tests failing on alpha

From bjaspan@MIT.EDU Thu Sep 26 13:18:17 1996
Received: from dragons-lair.MIT.EDU (DRAGONS-LAIR.MIT.EDU [18.177.1.200]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id NAA01734 for <bugs@rt-11.mit.edu>; Thu, 26 Sep 1996 13:18:17 -0400
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by dragons-lair.MIT.EDU (8.6.13/8.6.9) with SMTP id NAA19030 for <krb5-bugs@dragons-lair.mit.edu>; Thu, 26 Sep 1996 13:18:16 -0400
Received: from DUN-DUN-NOODLES.MIT.EDU by MIT.EDU with SMTP
id AA10640; Thu, 26 Sep 96 13:18:15 EDT
Received: by DUN-DUN-NOODLES.MIT.EDU (5.x/4.7) id AA09225; Thu, 26 Sep 1996 13:18:11 -0400
Message-Id: <9609261718.AA09225@DUN-DUN-NOODLES.MIT.EDU>
Date: Thu, 26 Sep 1996 13:18:11 -0400
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: randkey_principal tests failing on alpha
X-Send-Pr-Version: 3.99

mit

System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc



A few failures... All dealing with random keys...

FAIL: randkey-principal 1: bad failure
FAIL: randkey-principal 3: bad failure
FAIL: randkey-principal 15: bad failure
FAIL: randkey-principal 28.25: bad failure
FAIL: randkey-principal 32: bad failure


Looking in dbg.log - all the errors are of the form; (12 is ENOMEM).

**** CODE 12 ***
ERROR UNKNOWN {Not enough space}

I suspect this is caused by an uninitialized variable call to malloc -
or where a long is not filled in... Should be traceable...

ezra




From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: gnats@rt-11.MIT.EDU
Cc: Subject: Re: krb5-admin/29: randkey_principal tests failing on alpha
Date: Thu, 26 Sep 1996 15:42:02 -0400

Ezra,

You may have said this and I missed it... did the randkey_principal
errors during sapi tests, capi tests, or both?

Barry


From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: gnats@rt-11.MIT.EDU
Cc: Subject: Re: krb5-admin/29: randkey_principal tests failing on alpha
Date: Thu, 26 Sep 1996 15:51:34 -0400

Ezra,

I tried using kadmin to perform by hand the randkey_principal
functions that failed in the tests you listed; they all succeeded.
Thus, to debug the problem, I'll need actually to run the unit tests
so I can see the error occur. I can't do that unless I can write to
/krb5, which presently I can't. So, can you make whatever /krb5
points to world-writeable?

Alternatively, if you point me to the dbg.log file with the errors (it
does not seem to be in /mit/krb5/build/build), I might be able to
figure it out that way.

Barry

From: Ezra Peisach <epeisach@MIT.EDU>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/29: randkey_principal tests failing on alpha
Date: Sat, 28 Sep 1996 07:21:52 EDT

I have been tracking down this "ENOMEM" bug.
One of them also crops up in the sapi.2 tests...
Results so far.... malloc(0) is a bad thing to do on some platforms....
I believe the Alpha is one such platform where this is not the most
predictable..

For instance, kadm5/srv/svr_principal.c: kadm5_get_principal...
If KADM5_KEY_DATA mask is set, but there are no keys, a malloc of zero
is performed. Someone, somewhere is using this pointer...... (don't know
who yet). My current solution is to check if there are no keys and if
not, set to value to NULL, otherwise malloc. This fixes the sapi.2
test...

I suspect the capi.2 test failures will be similar problems...

Question: Does the spec indicate what should be returned if there are no
keys?

Ezra



From: Ezra Peisach <epeisach@MIT.EDU>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/29: randkey_principal tests failing on alpha
Date: Sat, 28 Sep 1996 08:10:39 EDT

Tracked down the problem.... I will let you decide if the fix is
appropriate..

I think my fix is wrong in that we should never call malloc if the
#keys=0. If the #keys do = 0, then shoud *key be NULL? Or a pointer to 1
keyblock?

I will continue to work on the server side fixes... I have alot of
debugging info in my file - but when I clean it up, I will send it in.

ezra

Index: client_principal.c
===================================================================
RCS file: /mit/krb5/.cvsroot/src/lib/kadm5/clnt/client_principal.c,v
retrieving revision 1.1
diff -c -r1.1 client_principal.c
*** client_principal.c 1996/07/24 22:22:43 1.1
--- client_principal.c 1996/09/28 12:01:42
***************
*** 279,285 ****
*n_keys = r->n_keys;
if (key) {
*key = (krb5_keyblock *) malloc(r->n_keys*sizeof(krb5_keyblock));
! if (*key == NULL)
return ENOMEM;
for (i = 0; i < r->n_keys; i++) {
ret = krb5_copy_keyblock_contents(handle->context,
--- 279,285 ----
*n_keys = r->n_keys;
if (key) {
*key = (krb5_keyblock *) malloc(r->n_keys*sizeof(krb5_keyblock));
! if (*key == NULL && r->n_keys)
return ENOMEM;
for (i = 0; i < r->n_keys; i++) {
ret = krb5_copy_keyblock_contents(handle->context,

From: Ezra Peisach <epeisach@MIT.EDU>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/29: randkey_principal tests failing on alpha
Date: Tue, 01 Oct 1996 10:44:26 EDT

Okay - this solves the ENOMEM problems...
The problem is tat malloc(0) returns NULL on the Alpha. In my opinion,
if the number of keys is zero, don't malloc anything as some platforms
are known to have bogus return values for this case...

Can you please look it over.

Ezra

Index: clnt/client_principal.c
===================================================================
RCS file: /mit/krb5/.cvsroot/src/lib/kadm5/clnt/client_principal.c,v
retrieving revision 1.1
diff -c -r1.1 client_principal.c
*** client_principal.c 1996/07/24 22:22:43 1.1
--- client_principal.c 1996/10/01 02:17:31
***************
*** 278,298 ****
if (n_keys)
*n_keys = r->n_keys;
if (key) {
! *key = (krb5_keyblock *) malloc(r->n_keys*sizeof(krb5_keyblock));
! if (*key == NULL)
! return ENOMEM;
! for (i = 0; i < r->n_keys; i++) {
! ret = krb5_copy_keyblock_contents(handle->context,
! &r->keys[i],
! &(*key)[i]);
! if (ret) {
! free(*key);
! return ENOMEM;
! }
! }
! }
}
!
return r->code;
}

--- 278,301 ----
if (n_keys)
*n_keys = r->n_keys;
if (key) {
! if(r->n_keys) {
! *key = (krb5_keyblock *)
! malloc(r->n_keys*sizeof(krb5_keyblock));
! if (*key == NULL)
! return ENOMEM;
! for (i = 0; i < r->n_keys; i++) {
! ret = krb5_copy_keyblock_contents(handle->context,
! &r->keys[i],
! &(*key)[i]);
! if (ret) {
! free(*key);
! return ENOMEM;
! }
! }
! } else *key = NULL;
! }
}
!
return r->code;
}

Index: srv/svr_principal.c
===================================================================
RCS file: /mit/krb5/.cvsroot/src/lib/kadm5/srv/svr_principal.c,v
retrieving revision 1.3
diff -c -r1.3 svr_principal.c
*** svr_principal.c 1996/08/02 18:10:14 1.3
--- svr_principal.c 1996/10/01 02:12:25
***************
*** 738,749 ****
}
if (mask & KADM5_KEY_DATA) {
entry->n_key_data = kdb.n_key_data;
! entry->key_data = (krb5_key_data *)
! malloc(entry->n_key_data*sizeof(krb5_key_data));
! if (entry->key_data == NULL) {
! ret = ENOMEM;
! goto done;
! }
for (i = 0; i < entry->n_key_data; i++)
if (ret = krb5_copy_key_data_contents(handle->context,
&kdb.key_data[i],
--- 738,753 ----
}
if (mask & KADM5_KEY_DATA) {
entry->n_key_data = kdb.n_key_data;
! if(entry->n_key_data) {
! entry->key_data = (krb5_key_data *)
! malloc(entry->n_key_data*sizeof(krb5_key_data));
! if (entry->key_data == NULL) {
! ret = ENOMEM;
! goto done;
! }
! } else
! entry->key_data = NULL;
!
for (i = 0; i < entry->n_key_data; i++)
if (ret = krb5_copy_key_data_contents(handle->context,
&kdb.key_data[i],

From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: bjaspan@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/29: randkey_principal tests failing on alpha
Date: Wed, 2 Oct 1996 12:10:24 -0400

Ezra,

This patch looks fine to me. Interestingly, I think it also fixes a
"memory leak" because the zero-byte block allocated when there are no
keys was never being freed. I assume this consumes some memory in the
malloc pool, though the block is zero bytes long.

It took some poking to figure out why this problem was occuring at
all.. after all, there should pretty much never be a principal with no
keys (although it is theoretically possible, the unit tests should
never create such a situation). The answer is that when the server
returns an error for randkey, it fills in n_keys with zero. The
client tries to copy all of the keys returned without regard to
whether an error occured; in the case of an error, of course, there
aren't any keys returned, so this is fine, except that it led to this
malloc(0) bug. So again your patch seems correct.

Barry

State-Changed-From-To: open-closed
State-Changed-By: epeisach
State-Changed-When: Fri Oct 4 08:58:39 1996
State-Changed-Why:
I have checked in the changes.