#766703 openafs-krb5: sparc build of aklog crashes

Package:
openafs-krb5
Source:
openafs
Description:
AFS distributed filesystem Kerberos 5 integration
Submitter:
JHU ACM Administrators
Date:
2014-10-27 21:21:08 UTC
Severity:
important
#766703#5
Date:
2014-10-25 00:49:03 UTC
From:
To:
As built and packaged, aklog aborts with "longjmp causes uninitialized stack
frame".  (This also applies to the 1.6.9 package.) Curiously, aklog built from
OpenAFS head with a straight "./configure; make aklog" works just fine, so I
have just resorted to paving over /usr/bin/aklog with that result and so far
things are working grand.  I am unsure what additional details would be useful,
but I confess to not having looked into the way that the Debian packages are
built.  Please don't hesitate to ask for anything that might be of utility,
or point me at something.

Thanks,
--nwf;

#766703#10
Date:
2014-10-25 00:58:03 UTC
From:
To:
OpenAFS head has a pthreaded aklog, so the messiness of LWP is not
involved.

Knowing of an older LWP aklog that did work would probably be the most
useful thing at this point.

#766703#15
Date:
2014-10-27 21:10:52 UTC
From:
To:
found 766703 1.6.9-2
tags 766703 moreinfo
thanks

[marking as found in the version in jessie, since "this also applies to
the 1.6.9 package".  I don't see a way to tag it as sparc-only in the
BTS...]

The longjump error is going to be coming from src/lwp/process.o, which is
compiled from either verious assembly files or a C file depending on the
architecture.  I don't have any sparc-linux systems, so I won't be able to
do any direct diagnosis of this issue (which is almost certainly
sparc-linux-specific).  From the build log, it looks like the C version is
being used here; there haven't been any changes to that file in upstream
between 1.6.1 and 1.6.9.  We don't have any Debian-specific patches to
that file, either.  (In fact, we didn't have any Debian patches at all for
1.6.10~pre1.)

I know this is a lot of work to ask for, but I think the only real way
forward is to try and bisect through stock upstream builds to see where
the failure was introduced.  I will note that commit
3262f111028093ed31da3fe9e3ed7efcc0e8b769 (between 1.6.0 and 1.6.1) did
touch process.c, though it's not immediately clear that it could cause
this particular sort of breakage.

#766703#24
Date:
2014-10-27 21:20:07 UTC
From:
To:
Benjamin Kaduk <kaduk@MIT.EDU> writes:

Another possibility is glibc changing something about what it expects.  It
wouldn't be the first time that LWP has been broken by changes to glibc
even when there was no source changes to LWP itself.