A few of my hud scripts lock up, possible reasons?

One of my huds is experiencing intermittant 'script lockups' of prims used to display text lists (a radar display, the sensors exist in other scripts and appear to function fine).

The script in question (there are several prims with it, they all appear to go down at the same time):
1. recieves link messages
2. contains touch_start events, which are not being processed at the time of lockup
3. adds/removes listeners during touch_start/dialog also not active at time of lockup
4. calls llSetText frequently
5. occasionally moves the child prim around using llSetPos, though should not be at the time of lockup.

Other scripts appear to be functioning within the hud parent prim, and at least one other child prim, but these child-prim scripts appear to become unresponsive after an indeterminate amount of time. I see no reason the script should run out of memory or go into any sort of unresponsive behavior.

No script errors pop up, the scripts do respond to a "reset all in selection" and function again for a while.

Is anybody aware of a jira issue that could cause this behavior? I've poked around but see nothing obvious.

I had that happen yesterday. I was using a pose maker and the mannequin control just turned all black, wouldn't resond. It worked later that day, had to relog, but it has never happened before. Maybe there's some oddity with worn scripts surfacing?

The simplest explanation would be that you have an infinite loop somewhere in your script, of course. Have you looked carefully for any such issues? Maybe try putting debug output (llOwnerSay()) at the beginning and end (and wherever you have return statements) of all your event handlers, and make sure you are always returning control back out to the system.

Also, are you getting any script errors? Try bringing up the script warning/error dialog after you notice them lock up, and see if you see anything there.

Granted a coding error that leads to a loop would be the most likely, but I don't see anything like that. The code is really basic

link message -> set text (continuous, every few seconds or second depending how I set up)
or
link message -> move (occasional)

The most complex bit of code (in fact pretty much the only other code in the script) is the touch handler to generate sane menus, and thats not coming into play as no menu interaction is needed to cause a failure.

no script errors/warnings at all, I've monitored that closely.

Its not the source of the link messages,as that wouldn't explain the sudden failure to respond to a touch event.