@ Christo: thanks.
@ olldbg
Sorry to keep you dancing like this but... 8>}
Would you reupdate to rev 13397.
While tracing the crash, I found other code that could cause re-entry into ClassBrowserBuildThread while it was busy.
This time, it's not a guess; I actually caught it and coded a fix that avoids the double entry.
Remember to copy Clangd_client dll from devel32_64 to output32_64 in case I'm full of (you know what); so that we can get line numbers on crashes.
TLDR:
Every time an editor is activated (happens every time the mouse moves into the text), it calls UpdateClassBrowser(). I should have known this, but my brain is old and rusting. And every 4th time a parser finishes a translation unit it invokes UpdateClassBrowserView(). Those two can happen at the same time. So I've moved busy checks just inside those functions to catch thread "busy" as soon as possible so one doesn't mod the TokenTree while the other is doing its business.
Clangd_client uses TryLocks(250 mil). If the lock fails, it was requeuing an idle time callback for the ClassBrowser update . I've remove these (for the time being) in case they were exacerbating the situation. Code now just skips the update.
I think I'll leave it that way until after the coming release.
There seems to be enough editor activating and background parsing to drive the update.
I haven't found any disadvantage so far.
Thanks !!