Help needed on trace() to locate user var reference and contents

Tue 2020.04.21

In three parts as each too large for one forum post.

Thank you @Gordon for the identification of References and Locks. After looking up several web pages, I thought I'd surprise myself, with a solution on successful traversing the trace object with code. Well it did indeed become a surprise, but also a big disappointment.

This code file is an attempt to generate the errors under my control and is not the code file that has issues. It reproduces close enough, that I am able to create working functions that I hope are small enough to paste into the other module to locate it's issues.

'"\xFFcod" is the name of the attribute of a function that contains a function's code'

I would expect that each name be different, should the attribute be specific to a function. In the attached trace, there is #110 #74 #437 #358 #328 etc. which so far point to both strings and flat strings, so as I see it, isn't specific as in one to one with a particular function, specific to Strings or to FlatStrings or an object type.

While I understand the gist of your response indicated to use the information gathered and then peruse the source code file to see the original source. I get that, but what is needed is to inspect the block as referenced by the block number, such as #531 while in memory. I'm attempting to build small functions to perform that task inside the WebIDE during run time, and not by human visual means.

re: Q1: Why does the refrence value change and what is that value exactly?
A: It's because Espruino uses fixed-size blocks - it's the block number

I understood that, what I should have clarified is how do I get to #531 when I am able to locate in the trace block #348 using text: '\xFFcod' which I have now identified isn't a good technique either as there are many instances of '\xFFcod'

   #348[r1,l2] Name String [1 blocks] "\xFFcod"        #531

But that only works on completion of first upload, as performing a subsequent trace on that block by name results in a unique new block number.

Such as:

>trace("history")
  #949[r0,l1] String [1 blocks] "history"
=undefined
>trace("#949")
  #1272[r0,l1] String [1 blocks] "#949"
=undefined
> 

My guess is that the act of typing in the command is assigned a new block as it is uploaded such that Espruino is then knows what to do, e.g. modify the linked list after parsing and deciding if in fact it is a valid block.

Still searching for a better example, but couldn't find one in the haste to post this.