Problem with klogind/kshd

[Tim Gaastra]

Certainly, and when I get some time in the next few days, if I can, I'm
going to pour over strncpy.S a bit for the port, since it has already
been the subject of some patching I notice by looking at the trees.

Checked on the compiler optimization possibility earlier, but it's not
set differently than it has been before for other packages (and is in
fact not that aggressive.)

Sadly, no core dumps are left. In fact, I don't think its signaling
segfault.

If I can find a way to get it to occur outside of the execle of
klogind/et al, I'll have a better chance to trace and debug it. Believe
me, the problem has already been passed back to the people maintaining
the compiler/port, but given its rather idiosyncratic nature, I'd like
to pin it down a bit more. I do appreciate your suggestions though. The
part that confuses me is that it (login.krb5) runs fine one way (from a
shell) but not another way (execed from klogind).

The actual functioning of Kerberos, with ticket-passing, decryption,
etc. always worked right, even with this bug... So like I said, I'm a
bit stumped, but eventually'll get to the bottom of it. For now though,
the separate strncpy seems to be standing up to testing.

-----Original Message-----
From: Marcus Watts [mailto:mdw at umich.edu] 
Sent: Wednesday, May 01, 2002 6:35 PM
To: Tim Gaastra
Cc: kerberos at mit.edu
Subject: Re: Problem with klogind/kshd 


"Tim Gaastra" <tim at gaastra.net> writes:
> But yes, the problem did, after some more testing turn out to be how 
> strncpy and strncmp functioned in every instance in login.krb5... But 
> here's the kicker: It ONLY happened when execed from kerberized 
> telnetd and klogind. If I ran login.krb5 by itself, or from agetty or 
> the like, it was just fine, but run from the execle in klogind, it 
> would silently die in the middle of every strncpy.
> 
> The solution for now has been to (carefully) reimplement strncpy (I 
> know, I used to mark down people for this when I taught C) as C 
> functions and link it in in lieu of the standard ones. So yes, sounds 
> like a compiler bug, but a very strange one, since plenty of other 
> programs that use strncpy work quite happily with that compiler/copy 
> of strncpy.S. The solutions serves for now though. Fixing the compiler

> is something that will be more difficult, since that compiler is the 
> "approved" one for this IA64 Linux that's been used to produce the 
> rest of the system (not my system).

If it "only" happens in K5, but consistently happens there, then there
is something "funny" about the way that you're building K5, that is
somehow different.  Perhaps you've got the compiler optimization turned
on too aggressively (and it's got bugs), perhaps K5 is somehow larger or
otherwise exercises the system in some new way, -- something is
different.  Until you know what that something is, it's going to lurk
there, and it's going to be waiting to bite you again in some other
project when you least expect it.

It sounds to me like it could be some sort of register use conflict.
Perhaps "strncpy.S" isn't saving some register value, or some such? You
say "it doesn't work"--does it leave a core dump?  Have you tried
tracing the code to identify the exact machine instruction sequence that
comprises the bug?  If you can identify an exact sequence, can you
produce a smaller simpler program that reproduces the same conditions
and bugs?  (One way to do this with a big program is to strip out pieces
of the big program, see if the bug still exists, then re-iterate until
you have just a small program left.)  If you can determine what the
exact problem is, the people who maintain your compiler and library
*ought* to be very interested.  Your small test program should become
part of their next regression test.

As a general rule, after the obvious compiler problems are solved (in a
new port), compiler problems typically show up in:
	large packages, in obscure corners.
	in the optimizer
	in code that deals with cryptography, where any
		compiler error breaks the math.

				-Marcus Watts
				UM ITCS Umich Systems Group