Random crashes on Droid back-end - possibly connected to var.store warning?

Knante

I've been experiencing some random crashes during a priming experiment on my Asus Tablet. Somewhere between 80%-90% of the trials the experiment just quits. No error messages, no additional information in the debug file, OpenSesame just quits.

After trying out numerous alternatives to the design (e.g. removing breaks, varying the presentation times, varying the timeouts and changing the stimulus file sizes), i resorted to using fewer trials so that the experiment finishes before the 80% mark.

This seemed to work for a few mock experiment runs, indicating that it was merely a performance/memory issue specific to the tablets. Unfortunately, today the same issue occured with a reduced amount of trials. Then i noticed a UserWarning when i ran the experiment on my regular laptop:

C:\Program Files (x86)\OpenSesame\lib\site-packages\libopensesame\var_store.py:236: UserWarning: var                        name is stored as attribute of item experiment
  % (var, self.__item__.name))

Could this have something to do with the random crashes? The error itself does not seem very informative to me; i do not specifally use a variable called name. But looking at some other posts on the forum the error tends to occur rather random?

I'm running out of ideas for a solution here, does somebody else have pointers and/or suggestions?

Cheers,
Laurent

sebastiaan

Hi Laurent,

This warning is probably unrelated to the crash. The warning is triggered when something in the experiment still uses the old way of storing variables as properties of the object, instead of the new var_store mechanism. It's sloppy, but harmless.

After trying out numerous alternatives to the design (e.g. removing breaks, varying the presentation times, varying the timeouts and changing the stimulus file sizes), i resorted to using fewer trials so that the experiment finishes before the 80% mark. This seemed to work for a few mock experiment runs, indicating that it was merely a performance/memory issue specific to the tablets

That's probably correct: The tablet runs out of memory, and ends up being killed by the Android out-of-memory (OOM) killer >:) I'm guessing that you have a lot of different images? @Josh you had this problem as well for your Sinterklaas-experiment, right?

Unfortunately, today the same issue occured with a reduced amount of trials.

This may have been bad luck. If the tablet had slightly less memory available than usual, then even the reduced number of trials may have been too much.

What you could do:

• First, try to see if it's really a memory issue. Run a few trials, switch to some Android system app that shows you available memory; run a few trials more, check memory again, etc. If you see that memory is filling up (as I suspect), then you can be pretty sure that this is the issue.
• Then try to figure out why this happens. It could be a memory leak in the pygame subset for Android, in which case there's not much that we can do about it. Or it may be something to do with your experiment. If you upload it here, I can take a look to see if I spot anything unusual.

Cheers,
Sebastiaan

Knante

Hi Sebastiaan,

Thanks for the prompt and elaborate reply!

The warning is triggered when something in the experiment still uses the old way of storing variables as properties of the object, instead of the new var_store mechanism. It's sloppy, but harmless.

Good to know that i can savely ignore these warnings. I was just thinking that the Runtime for Android responds differently to this type of Warning, thus aborting the experiment without a direct explanation?

That's probably correct: The tablet runs out of memory, and ends up being killed by the Android out-of-memory (OOM) killer >:) I'm guessing that you have a lot of different images?

I'm using 36 images in total so that is probably the case!

First, try to see if it's really a memory issue. Run a few trials, switch to some Android system app that shows you available memory; run a few trials more, check memory again, etc. If you see that memory is filling up (as I suspect), then you can be pretty sure that this is the issue.

Great idea, i'll test that with an external or system app.

Well, on a positive note, i guess we have found the edges of what is possible with terms of task demand and memory constrains for Android devices. That is, for a run-of-the-mill tablet device