In continuing to research this, I see there's a lot of interesting code in lwp
that can be enabled by defining DEBUG. So just to give it a whirl, I added a
line to lwp.h:
#define DEBUG 1
And recompiled just lwp and kauth. Now the resulting klog works. Very
bizarre... I'm not sure what to make of it yet.
-Ben
________________________________
From: openafs-devel-ad...@openafs.org <openafs-devel-ad...@openafs.org> on
behalf of Ben Huntsman <b...@huntsmans.net>
Sent: Monday, November 11, 2024 12:26 PM
To: openafs-devel@openafs.org <openafs-devel@openafs.org>
Subject: [OpenAFS-devel] kauth broken - problem with IOMGR in lwp?
Hi everyone-
First of all, please don't laugh, but I do have an older test cell that runs
kauth instead of krb5. This is at home, not for anything production, so don't
worry.
That being said, is kauth currently broken? A colleague of mine tried it on
Linux and gets a segfault when running klog, and I get the same behavior on AIX:
$ dbx /usr/afs/bin/klog core
Type 'help' for help.
[using memory image in core]
reading symbolic information ...
Segmentation fault in unnamed block in IOMGR at line 362 in file "iomgr.c"
362 FD_ZERO(&IOMGR_writefds);
(dbx) where
libdebug assertion "(framep->getGpr(STKP, &addr) == DB_SUCCESS && *nextStkpp ==
addr)" failed at line 1418 in file
../../../../../../../../../../../src/bos/usr/ccs/lib/libdbx/libdebug/modules/stackdebug/POWER/stackdb_FrameProgress.C
unnamed block in IOMGR(dummy = (nil)), line 362 in "iomgr.c"
(dbx)
And here's a blurb from around that line in src/lwp/iomgr.c:
...
/* These are not declared in IOMGR so that they don't use up 6K of stack. */
static fd_set IOMGR_readfds, IOMGR_writefds, IOMGR_exceptfds;
static int IOMGR_nfds = 0;
static void *IOMGR(void *dummy)
{
for (;;) {
int code;
struct TM_Elem *earliest;
struct timeval timeout, junk;
bool woke_someone;
FD_ZERO(&IOMGR_readfds);
FD_ZERO(&IOMGR_writefds);
FD_ZERO(&IOMGR_exceptfds);
IOMGR_nfds = 0;
...
I did the compile with the ./configure --enable-debug and -enable-debug-lwp
options specified. Can someone help explain how this code works, and what
might done to fix it? I'm a little fuzzy on the *IOMGR piece and I don't see
that anyone calls IOMGR() directly in the code...
Thank you!
-Ben
