OpenSesame experiment with Gazepoint suddenly freezing
Hi all,
The attached eye tracking experiment with Gazepoint HD3 (running in OpenSesame 3.2.7 on PC with Windows 10) was working fine for ~50 participants, but now it is having a recurrent issue. I am not at the site, so I am gathering information from the RAs. The issue is occurring during the trials of the experiment, not during calibration. Here is how the RAs describe it.
One instance:
The window froze and then shut down, but no error screen appeared – after it shut down the screen read “experiment is finished” as it normally would. Also, when it shut down there seemed to be another experiment window open. I closed this one and tried again, but the same thing happened. [I have clarified that by "froze" they mean the blue spinning wheel appears.]
Another instance with multiple crashes:
First time: Crash with no pop-up message. The task just exited out to the open sesame window that you usually see before you run the experiment.
Second time: Crash with no pop-up message. Picture of the error is attached to this email.
Third time: Crash with no pop-up message. Picture of the error is attached to this email.
Pic of the debug window after the issue below (there is no reported error).
Thanks for any advice.
Comments
btw issue happens about 1/4 times we run participants
A few more details. The fan pretty consistently speeds up and becomes loud during the experiment. Also, when the issue happened again today, we got this message:
Stopped: The experiment did not finish normally. - The experiment process was killed
(this was again a crash not at calibration but somewhere within a block of trials.)
Thanks for any suggestions.
And if it is helpful, here are comments from IT person:
1. When the students were running the program, at certain points throughout the processor fan will speed up (to the point where you can hear it) indicating the processor is being used close to 100%. I think this is software triggering this, more than a hardware issue.
2. Have you tried saving the data locally to the desktop instead of in Dropbox? [note: we had previously been running the experiment out of a DropBox folder, but we moved it to the desktop and now save data to this location, but still have the issue]
3. The eyetracking PC has an i7 Processor, 16GB RAM, 512GB SSD with over 300GB of free space currently, so not a hard drive running out of space issue
4. Do we need a more powerful graphics card? I think the graphics card currently has 2GB of memory built-in. Is that enough?
5. I ran a Dell hardware self-diagnostic check and everything passed/is working fine – no failing parts
6. I’ve updated the PC BIOS to the newest version
7. I’ve updated Windows OS patches to the newest version
Hi Tom,
I don't have a Gazepoint tracker myself, so it's difficult to say much about it. However, freezing in combination with 100% CPU consumption sounds very much like an infinite loop.
So then the question is where this infinite loop comes from. One option is that it's somewhere in the experiment itself, for example a
while True:loop with faulty logic. But I don't see anything in the experiment that could cause this (based on a quick scan). Another option is that the infinite loop is somewhere in PyGaze.To pinpoint this, it would be important to first know when the freezing occurs. I suspect that it will occur semi-randomly, but always at specific points in the experiment. For example when recording is started, or stopped, or when log messages are written to the eye tracker. Systematic
print()calls might help to track when freezing happens. Once we know that, we can take it from there.Cheers!
Sebastiaan
Check out SigmundAI.eu for our OpenSesame AI assistant!
HI Sebastiaan,
Thanks for reply! I'm looping in @Edwin. I have looked through the data files. For three instances (172, 203, 203a), the issue happens during the 12 s presentation of the image pairs (when eye movement data is being recorded). We are recording at 150 Hz. One time it happens 460 samples in. Another time it happens 1200 samples in.
In another instance (215), it happens right when the recording starts for a new trial (or so it would seem). For that last instance, the line of data in the .tsv file is incomplete; it is missing the last two elements, which includes the user message.
Also, for some of the other files, the message string gets cutoff part way through in the .txt file (the additional log with messages that is created when you use OpenGaze in PyGaze. For example, for 203a, the last complete message string, which contains timestamps and stimulus information, reads:
500374,501061,502095,514121,516146.0,pleasant3.jpg,neutral19.jpg,26
The last message is an incomplete message string:
516530,517224,51
Maybe that's a clue?
One more potential clue. There is a CS column in the .tsv files, which relates to the cursor (it is next to cursor x and cursor y at end of row).Here are details from an outdated version of the Opengaze API:
Parameter ID: CS (not currently implemented)
Parameter type: integer
Parameter description: Mouse cursor state, 0 for steady state, 1 for left button down, 2 for right button down.
On two of the crashes during image presentation (172, 203a), there is mouse activity right before the crash: first a 1, and then ~10 or so samples later, a 3 (not defined in version of API quoted above). In the past, I have noticed that if you click rapidly during an OpenSesame experiment, it can cause it to exit out of the experiment screen or do other odd things. I am wondering if participants are getting bored during the lengthy trials section (40 12-s trials) and fiddling with the mouse, which they later use for ratings. We have moved it away from them and instructed them not to use it.
Thanks for any suggestions or ideas you have! If we should add a print() message somewhere, just let me know.
Best,
Tom
PS I will send you both the data files--the .tsv files are too large to post here.
One more observation: something similar (perhaps?) happened in my lab today. OpenSesame froze up mid-calibration with the Gazepoint. It exited out to GUI window, which was frozen with icons at top greyed out; when RA clicked on OpenSesame icon in task bar, it showed experiment window as active, but wouldn't let her enter it. She had to force quit from task manager.
Hi Tom,
I don't think this is the kind of problem that we'll be able to resolve through the forum. You're saying that the freezing occurs randomly while the tracker is recording, and while the experiment is otherwise doing nothing. Is that correct? If so, this suggest that the freezing occurs in
PyOpenGaze, which is where the logging etc. is handled. Resolving this would require someone who has both the skills to debug this (which I suspect is not trivial), and an actual GazePoint eye tracker to work with.@Edwin implemented this library originally, although it hasn't been updated for over two years now. Edwin, do you have any idea about the origin of this issue?
Cheers,
Sebastiaan
Check out SigmundAI.eu for our OpenSesame AI assistant!
Hi Sebastiaan,
Thanks--that makes sense. The only caveat is that for the collaborating lab, it wasn't happening at calibration, but instead during image presentation, but I guess the experiment isn't doing anything 4 or 8 seconds into a 12-second image presentation.
I think I'll just send the other lab an Eye Tribe--that will take some time pressure of the debugging.
Thanks again for the help,
Tom
@sebastiaan I only update it when OpenGaze is updated and breaks my stuff; otherwise it should continue to work.
Tom and I have been looking into this off the forum, and from what I can debug at a distance, it seems an OpenGaze-specific issue.