[E8] Concecuences of the JSC parse issue while runnning coco8 applications
The [E8] JavascriptCore parse issue emerges in cases where methods with multiple nested-block expressions are injected in the system (or present in image loaded at startup).
Each level of nested block definition increase the risk of emergence of the bug when the javascript code is parsed by the JSC VM.
Any (block and) defined javascript nested function increase the risk of emergence of the bug.
The S8 Compiler emit code patters using functions for
most expressions using block closures
method returns
exceptions
So.. the use of deep nested expressions with this shapes increases severely the risk of bug emergence.
The S8 Compiler trigger the bug condition because there are multiple methods written with nested blocks (see e.g. SmalltalkParser>>#methodParserParts and others), so the sole inclusion of Compiler in the image put the system in risk.
The dynamic loading of methods with nested blocks increases the risk of bug emergence (long time -minutes- after loading).
There is no way to prevent the bug, because it is caused by an issue during parsing javascript code (a bug in the JSC's javascript parser).
The construction of javascript functions instantiates the bug. The execution of functions is NOT affected by the bug.
The bug appears in all platforms using JSC (we checked using jscocoa/coco8, native script, react native, with and w/o s8 environment)
Symptoms of the bug emergence
The parsing of nested functions in JSC consumes a lot of memory (and time) and leaving the object memory corrupted. The evaluation of nested functions runs OK.
If the device has enough memory to compile the script (containing nested functions) execution continues without any indication that the bug has been instantiated.
There are times where there are crashes later in the execution of the system when the garbage collector run when memory are near to fill memory of the device. This evidence is shown by xcode, but it is not reproducible, because the crash happens in different points of execution later in time, and depending on the memory use pattern of the application.
If a garbage collection is forced to happen by JSC API, the garbage collection finishes without crash (the corruption is removed by GC?). As we canīt predict the emergence of the bug, we canīt force a garbage collection to prevent the crash during GC.
When the bug has been instantiated, the crash can happen minutes later, depending on the policy in the VM activating the (incremental) GC.
When the object space is full (there are memory to reclaim by the GC) the parsing of nested functions cause a crash. NO crash report has been found in the device in this cases and XCode debugger use to report a text saying "Memory issue has happened" without any other information about the crash.
We infer, from our observations, that the parser use object memory and do not enter the GC procedure in this cases; causing the system to crash.
Using xcode + the Safari's javascript debugger makes easy to crash the application running on the device. In our opinion, the (js) debugger activate the parser and cause multiple instantiations of the bug. The javascript debugger fast exit in most cases, or become freezed. XCode debugger freeze or report the application ended with no debug information in most cases. When xcode debugger show execution state it shown it is inside GC.
Conclusions
the bug emerges parsing nested javascript functions.
each level of nesting consumes much more memory
if memory becomes full during parsing, a crash will happen ("memory issue has happened")
if memory is not full, the execution continues, but with corrupted object space
a crash happen when collecting garbage of a corrupted object space (at any point in time during the execution of the system, e.g. during assignment to a local variable, just entering a method, etc)
evaluating nested functions works OK
Preventive calls to force GC prevent crashes but it is not possible to know when we need to GC