> On Nov 13, 2024, at 8:02 PM, Jeffrey Altman <jalt...@auristor.com> wrote: > > >> On Nov 13, 2024, at 7:19 PM, Ben Huntsman <b...@huntsmans.net> wrote: >> >> Any idea how to track it down? This is made more difficult by the >> limited debugger output. >> > > git bisect from a known working version to a known broken version.
Git bisect is going to be the best option because there was five years of significant development between when the 1.6 series was cut from master and when the 1.8 series was cut from master. I think the first question to answer is whether or not the failure case was present at the point where the openafs-stable-1_8_x branch forked from master. commit e739eaa650ee30dcce54d05908b062839eafbf73 (tag: BP-openafs-stable-1_8_x) If it was working there, then bisect along the openafs-stable_1_8_x branch to find the commit where things break for the first time. If it was not working there, then bisect the master branch from the point where the openafs-stable-1_6_x branch forked. commit c89bc695707f62e64f64b3abb15470b291f613a1 (tag: BP-openafs-stable-1_6_x) LWP is hard to debug because it is a custom cooperative threading model which is not going to be understood by debuggers. In OpenAFS 1.8.x the commonly used command line tools although built for both LWP and pthreads are going to be distributed as the pthreads version. There is no pthreads build of klog. It’s quite possible the breakage is to all LWP clients and not specific to kauth. One thought that comes to mind is whether the difference is in how OpenAFS is being built. For example, was the 1.6.13 build that succeeded 32-bit vs the 1.8 build being 64-bit?
smime.p7s
Description: S/MIME cryptographic signature
