"TLS exhausted"; need help interpreting output from DUMP-THREAD

Robert Dodier <[email protected]> Thu, 13 Mar 2025 14:23:55 -0700
Newsgroups gmane.lisp.steel-bank.general
Message-ID <CAAsY_sT_s6oG-ZLxQeGJDHb3vZr-sMpwkqAd7pLtcN5hTvmcpQ@mail.gmail.com>
Hi, I am debugging a problem which manifests as "Thread local storage
exhausted." I'm trying to figure out what led to that.

I am working with SBCL 2.5.2 on Linux. I'm investigating a bug report:
https://sourceforge.net/p/maxima/bugs/4517/

The bug is triggered by trying a certain operation (namely
`run_testsuite(tests = rtest_rules)`) repeatedly. It was suggested by
someone to try SB-THREAD::DUMP-THREAD to dump out some info between
calls to run_testsuite. The resulting output is shown in this message,
which I'll omit in the interest of brevity:
https://sourceforge.net/p/maxima/mailman/message/59159587/

I'm looking at the DUMP-THREAD output and trying to see what might
indicate a problem. Comparing the successive dumps, it looks like
various addresses change from one dump to the next, and also I see
that SLOW-PATH-ALLOCS seems to increase.

tmp-thread-dump-1:  46 SLOW-PATH-ALLOCS  : #x111
tmp-thread-dump-2:  46 SLOW-PATH-ALLOCS  : #x40CE
tmp-thread-dump-3:  46 SLOW-PATH-ALLOCS  : #x5363
tmp-thread-dump-4:  46 SLOW-PATH-ALLOCS  : #x6600
tmp-thread-dump-5:  46 SLOW-PATH-ALLOCS  : #x789E

I wonder if SLOW-PATH-ALLOCS measures some identifiable allocation
which I could possibly modify in the program so as not to tickle the
error.

Is there some way to know what has failed when "TLS exhausted" is reported?

For the record, I dumped out the special variables in the :maxima
package via SB-CLTL2:VARIABLE-INFORMATION and the special variables
don't change from one  cycle to the next.

While investigating this problem, I grepped through the SBCL source
code and searched the web but wasn't able to find anything so far as I
can tell.

Thanks for any light you can shed on this.

Robert