- 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
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;
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.
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.
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.