Problem with klogind/kshd

[Marcus Watts]

"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