• Part 3

    Just noticed this, that wasn't apparent as I typed the posts. Traversing backwards, I see the large code chunk is part of a known function named 'dl()' In the history, which I believe is what is uploaded before parsing as block #440 and then again as the string identifier in memory at block #428 that points to the function configured in memory as block #438, made of other linked blocks, it's ID of #437 and the function as a FlatString object at #637

         #440[r1,l0] String [200 blocks] "function dl() {\n\n  console.log( \"    \" );
    
    
      #428[r1,l2] Name String [1 blocks] "dl"    #438[r1,l0] Function {
          #437[r1,l2] Name String [1 blocks] "\xFFcod"        #637[r1,l0] FlatString [150 blocks] "console.log( \"    \" );
    

    What I would like to do is be able to traverse the trace results and get at block #637 but not knowing the actual function by name. Maybe a traverse the results and list the blocks containing more than 'x' (?ten?) blocks might be a good start.

    As typeof trace() returns ="undefined" I'm starting to wonder if it is in fact just a function that prints to the console, values that are extracted under some rules, as I expected "object" to be returned.


    'If you paste the whole trace up I could show you'

    So, yes please, a small sample to get going would be appreciated.

    Incidentally, I'm initially guessing there is a parsing issue when using both embedded individual commented lines and block commented lines within a function whose length spans a large amount forcing a newline char to get inserted which then affects code content parsing during runtime. Just a guess, but ran into a similar situation back in 2017 I just can't reproduce that manually, yet.

    What happens in the suspect code file, is an attempt to execute a function roughly 20 JsVars in size when 400 JsVars are available and I get an immediate error/lockup and unable to access the console. Using the above idea, will attempt subsequent test passes inserting/moving this trace read function each time to see what is going on immediately before lockup. This code file pseudo representation is extremely stable until attempting to write a large block knowing there isn't enough memory. Thus, a close approximation to what occurs in the other file.


    Also, found this unproven snippet: global["\xFF"].history = []; that was a suggestion to reduce memory, but felt that performing intentional destruction without allowing Espruino to clean up the linked tables, that it is in fact an inproper suggestion.

About

Avatar for Robin @Robin started