[E8] Why/When/Who is going to the crash?

Does it depend on "image" size?

1. We will load a very BIG image at startup and run the bug expression to see if execution is affected by image size.
   • Results: Bigger images expose the bug immediately
     • Using standard image crash on iPhone6s after 26 steps
     • Using image of double size crash on iPhone6s after 5 steps
     • Using of 5x and 10x image crash(fast exit) on iPhone6s on first step
     • Using 50x image fast exits the app without exception reported to objectiveC.
   • The app is killed without any information about the issue
2. We start from kernel image and pollute hierarchy instantiating new classes (each class implementing all methods of Objects copied).
   (source code: st js) Then we run the bug expression.
   • Note: we generate the classes and methods from existing methods using javascript (no S8 compiler operation involved)
   • Results: The size of the system make the bug happen easier
     • Standard image + 5 classes added expose bug after 10 steps
     • Standard image + 10 classes added expose bug after 4 steps
     • Standard image + 15 classes added expose bug after 4 steps
     • Standard image + 50 classes added expose bug after 2 steps
     • Standard image + 100 classes added expose bug after 0 steps
     • Standard image + 500 classes added expose bug immediate fast exit (classes created w/o issue)

Does it depend on Object environment size?

1. We start from kernel image and pollute object space with a lot of instances referenced from global pool.
   (source code: st js) Then we run the bug expression.
   • Note: we generate the objects from Random instances and Object method sources
   • Results: The number of instances in the system make the bug happen easier
     • 1 pollution sets added expose bug after 14 steps
     • 10 pollution sets added expose bug after 2 steps
     • 15 pollution sets added expose bug after 1 steps
     • 50 pollution sets added expose bug after 0 steps
     • 100 pollution sets added expose bug after 0 steps
     • 500 pollution sets CRASH in pollute #407 (after noticeable GC in #367) - memory full?
       no exception nor debug chance using Xcode 8.2 beta
     • 300 pollution sets + garbage removed (PollutionPool := nil) expose bug immediate (no garbage collected)

Does it depends on evaluation expresssion?

1. Conditions: we run in iPhone6s, iOS
   (we fix conditions to make reproducible, the bug also emerges in other configurations)
2. We start polluting object space (with argument 300) to fill memory and clearing the garbage (global set to nil); 4(four) times
3. Then we evaluate a simple expression "self print: #hello" multiple times to see how many times it runs (before crash)
   • Results: The bug emerges (crash on the SECOND evaluation) with simple expression, it do NOT depend on expression complexity

Does it depend on nesting of function calls?

1. Our Compiler implements methods with mested blocks (as language productions, see SmalltalkParser>>#methodParserParts) and build methods(javascript functions) dynamically. The memory corruption is detected after parse step and during evaluation of functions (in strange places that varies with object space composition).
2. The memory corruption is observed after parsing javascript source with deep nesting of blocks
3. A test that exposes the bug as a crash in iOS and a sloooow execution speed in Safari (OSX) is included in the s8 tests set under the title test[s8] deep calls (see Executing a complex block)
   • Results: The JavascriptCore parser has issues parsing recursive calls

Conclusion

The JavascriptCore parser has issues parsing recursive calls Ref.: test[s8] deep calls (see Executing a complex block)

Note: In all cases we observed a fast exit

1. The was no chance to debug using Xcode, the app fast exit (killed by O.S.?) without control at ObjectiveC level.
2. The Xcode tools was unusable to debug the issue; also the Safari interface to debug at javascript level did not report exceptions nor any information about the issue.
3. There was no crash reports stored in the device after the tests