[View]  [Edit]  [Lock]  [References]  [Attachments]  [History]  [Home]  [Changes]  [Search]  [Help] 

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

We want to know the context where the bug is exposed.
In this page we will try to find the causes that preserve/remove the bug emergence.

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.
  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.

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.

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)

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)


Uploaded Image: alert.gifThe 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