OOM stands for Out Of Memory and is considered “business as usual” for Windows Mobile devices. Depending on the application and your platform, clicking on a close button will most likely not terminate your current application, just minimize it. Most apps will only exit when asked - otherwise, they simply hang around waiting to be reactivated. When you first boot your device there will be plenty of memory but over time as you launch new apps, this memory gets used and at some point you will reach OOM and some apps will need to be shut down.

 

This discussion applies to Hopper in that its Hopper’s job to continually launch new apps so you reach this state very quickly. Hopper effectively lives in a constant OOM state and knowing that being out of memory is not necessarily a problem. When investigating stability bugs, stay focused on the problem you are trying to solve, not why the device is out of memory (it should be).

 

Let me explain with an example: during my Hopper runs, I have an application Foo.exe that will sometimes log an error saying: “Cannot allocate a new node, exiting…” and Foo.exe exits with this error.

 

Instead of focusing on why you are out of memory, shift your focus to the logic surrounding the allocate that generated the above error:

  1. Do you really want to exit the application because this allocation failed?
  2. Do you notify the user in an appropriate way that the application cannot perform the requested action and is shutting down?
  3. Is it entirely necessary to do the memory allocate? Could you reuse existing memory?
  4. Could you be more clever in the way the application manages memory – like doing a large allocate during Init and managing or reusing the memory yourself?

Stay focused on the problem you are trying to solve and do not be daunted by the fact that Hopper has created this OOM condition on your device – use it as an opportunity to understand how to make your system more stable.