search

open-cogsci / OpenSesame

Graphical experiment builder for the social sciences
http://osdoc.cogsci.nl/
GNU General Public License v3.0
234 stars 111 forks source link

Spurious error: recursion detected! Is variable '....' defined in terms of itself #545

Open alisdt opened 6 years ago

alisdt commented 6 years ago

The above error occurs at random during a presentation experiment with eyetracking. The eyetracker is a recent Tobii one and is not supported by PyGaze yet -- so all of the calibration and data collection is done via inline code items and the Tobii Pro SDK.

This error seems to occur in different items, naming different variables, every time the experiment is run, which was the first clue that it was spurious.

I've tried disabling the error in var_store.py, by changing 'raise osexception' to 'warning.warn' at the relevant place, and no further problems arise with the experiment.

My suspicion that this is a race condition / threading problem, either due to calls to the Tobii SDK or the large amount of output written to CSV via inline code. The experiment is a bit big to upload and I don't have clearance from the experimenters to share it yet; instead I'll work on a minimal example to try to reproduce the problem. I'm adding this issue so others can find it if they encounter the same problem.

The experiment is running using OpenSesame 3.1.6 on Windows 7.

smathot commented 6 years ago

Thanks for reporting this! Indeed, we'll need an example to illustrate the problem, or at least a reproducible way to trigger the problem.

alisdt commented 6 years ago

Further thought: I think it's probably to do with the Tobii SDK. It delivers the eyetracking data via callback.

The callback function I'm using enumerates the current loop variables to log them alongside the eyetracking data. So if this callback is called while any loop value is being set (which I believe is entirely possible) it will cause this exception.

In that case this isn't an OpenSesame bug, but an integration problem with the Tobii SDK. The solution would be to either:

  1. wait on the lock, or
  2. just fail to log that sample -- if the loop variables are being updated at that point, we probably aren't that interested in eyetracking in any case.

I'll try to confirm this as soon as possible.