Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
EnTerr
Roku Guru

RSG bug: observer infinite loopiness (YAWRR)

Continuing our long-running, award-seeking series of Yet Another Way to Reboot Roku, today we have an entry from xmlology land (bug current as of rOS 7.2.4100):
<interface>
 <field id="ping" type="assocarray" onChange="ping"/>
 <field id="pong" type="assocarray" onChange="pong"/>
</interface>
<script type = "text/brightscript" ><![CDATA[
 sub ping()
   print "ping" : m.top.pong = {}
 end sub
 sub pong()
   print "pong" : m.top.pong = {}
 end sub
]]></script>

Put this into e.g. the scene <component/> and issue `scene.ping = {}` from somewhere (main thread console in my case). Observe the player crashing pronto, while the render thread console shows:
ping
pong
pong
pong
pong
[... lines deleted for brevity here]
pong
pong
pong
Connection closed by foreign host.
$

TFM assures me this cannot happen:
"Node Field Observers" wrote:
... There is also loop breaking logic to make sure that you cannot get into an infinite loop of observer callbacks.  ...

And to its credit, RSG makes some feeble attempt to avoid infinite loops - for example if you tried assigning `scene.pong` and not `scene.ping`, it wouldn't crash.

PS. Amusingly, this case reminds me a popular job interview question about detecting a loop in a singly-linked list. In those terms, RSG loop detection seems to fail when the loop does not include the head. Good thing RSG does not have to apply for jobs.

PPS. The point of above PS was not to gloat but draw attention to the fact there are "cheap" ways to detect loops, e.g. time complexity O(N) and memory requirement O(1).
0 Kudos