Originally Posted by Ian
...
I don't know where diagnostics log is on iPad but on iPhone iOS5 it's in settings/general/about/diagnostics and usage/diagnostics and usage data.
...
I just changed a typo in the above. I missed out general so have corrected it. Anyone that is experiencing a large number of 'crashes', do Meridian a favour and make sure that 'automatically send' is enabled.

Im no export in these things, but from the crash logs posted, my interpretation is that there seem to be two issues.

First, the Sooloos app, CoreControl, is big on memory usage. In all three of the memory usage logs, it was the largest app running on the iPad and thus, the one most likely to cause iOS to have to perform tasks relating to memory allocation. I don't have an iPad so don't have this app, but on my iPhone, it is no surprise that my largest app Safari is also my most unstable.

Second, one of the logs there does appear to be an Sooloos application crash but, not directly in Soolooos code but quite a bit further down in the back trace/call stack within the iOS user interface library. These can be very difficult to track down and hopefully Meridian will get enough diagnostics to allow them to track down this type of crash.

The fact that 3 of the 4 logs posted seem to indicate low memory issues would add weight to the argument that the disappearance of the app is not a crash but a result of iOS jettisoning apps to free up memory.

Like larger modern OS's, iOS also implements virtual memory, but it is much more basic. Unlike 'proper' virtual memory implementations where any of the virtual memory can be transparently swapped by the OS between RAM and disc, not all of the contents of the iOS virtual RAM can be. Whilst iOS can automatically remove read-only content, such as program code, from RAM when free RAM gets below a certain threshold, for read-write sections, such as data, iOS asks the application to free up memory and if it fails to free up sufficient RAM, iOS terminates/jettisons the app. If the jettisoned app is not currently active, then this process is largely transparent to the user, however, if that app is the current running app, it simply disappears from screen. It is this I believe that we are seeing in the majority of 'crashes'.

Whilst low memory situations may be as a result of memory leaks, I do not believe that this is happening to any major extent here (if at all). So assuming that the issue is a direct result of the limitations of iOS virtual memory management, made worse by iOS devices having limited RAM in the first place meaning that the amount of data that it can hold is very limited.

A possible scenario that we seeing is that the Sooloos CoreControl app is using a large amount of RAM to hold data (possible cover art). So it is up to the Sooloos app to free as much of this up as it can when iOS tells it to free up RAM. As other applications can be running in the background, just see from nclp's first crash log to see the list of other runnable processes on the iPhone, this trigger can occur at random times when one of the processes periodically wakes up to do its stuff and then goes back to sleep. The issue then becomes how much RAM can Sooloos freeup and is it sufficient to prevent iOS from terminating it. Only Meridian can know the answer to that.


Meridian owner since 1992
Prime & PSU, Focal Elear headphones, Roon (ROCK 8Gi5 NUC), Explorer 1 & 2, F80. 200/203, various Sonos (via Roon).