On Fri, 4 Jan 2019 19:24:52 -0500 Greg Hudson <[email protected]> wrote: > krb5_mcc_start_seq_get() is in the traceback, so the memory cache change > is a clear candidate for the bug. I can't find anything wrong with the > code, though. From the stack trace, there appears to be a memory ccache > on the list with an invalid mutex, but I don't see any way of getting > into that state.
I found the bug. krb5_mcc_ptcursor_next() is not increasing the refcount on the caches it yields. The per-type cursor is also subject to badness if what would have been the next cache is destroyed before it is yielded, either by a separate thread or by a single thread doing cache destroy operations in the midst of the iteration. My plan is to backport commit 49bb627fed70c5258c151c5135ac3d95ed1ee55d from the master branch and issue new 1.15.x and 1.16.x releases. Apologies for the release branch regression; in hindsight I should have decided that commit 146dadec8fe7ccc4149eb2e3f577cc320aee6efb was too big to backport.
