Tab crashes after some time

[TabeaW]

Hi all! I have implemented an experiment using the webgazer, but I have the problem that the tab sometimes crashes after about 20 minutes with webgazer running . Does anyone have any idea what could lead to such a behaviour? Thanks in advance!

[xanderkoo]

Thanks for letting us know. How frequently are you clicking/adding new calibration points? We haven't really stress tested this, but given that the data is stored into localForage (browser-side storage) with each click, if you are regularly clicking in the browser tab, you might be running into an issue with localForage running out of space based on your browser/machine configurations.

Are you building from source? You may want to check if you're reaching the max number of calibration points of 700 (the function should be localforage.length()).

[TabeaW]

Thanks for your reply. I tried with different numbers of clicks, at the moment it shouldn't be more than 100. I downloaded the webGazer.js file and stored it locally.

[xanderkoo]

Can you try the demo and see if it runs into the same issue? Also, what browser/OS are you running? I'm on Chrome for Mac and it seems to work fine well beyond 100 clicks.

[TabeaW]

First it seems like it would run, but after some minutes the demo also crashes (without any further clicks besides the calibration). I'm on Firefox for Linux. The experiment was done by some more participants and all of them except one ran into the same issue (Firefox, Chrome, Windows, Mac in different combinations).

[TabeaW]

I have now switched to a version before the facemeshes, this runs without crashes for me.

[xanderkoo]

I see, I wonder what the issue is then--especially given that you and others experiences this issue, but we've never encountered this issue in development. But I will say that the old version that uses CLMTrackr is much less robust wrt face detection, and there is a noticeable increase in accuracy in the Facemesh versions.

Are you able to get console output of what happens when WebGazer crashes for you? I'd like to try and help you suss out what is crashing the program. If Facemesh is the underlying issue here, are you able to run MediaPipe's official demo? You may want to disable iris detection if you are on an older machine.

[TabeaW]

Unfortunately console output is not possible, the crash clears it completely. The MediaPipe's official demo runs fine, but they are doing only 5 fps, I think webgazer uses more if I'm not wrong.

[daisydorothy]

Just to add to this in case it's helpful wrt troubleshooting the issue: i've been running experiments using Webgazer, using Facemesh more recently, but prior to that CLMTrackr.

Participants have reported more performance problems with the Facemesh version: I haven't had many reports of crashes, but a number have reported extremely slow performance. The problem seems worse on some browsers than others: when I use Chrome on my machine (a ~2018 MacBook pro), I have no problems completing the study, though I can tell that Facemesh is pretty resource intensive. Using Safari is almost impossible from the outset - it runs extremely slowly - and I ask participants not to complete the study with Safari for that reason. Firefox seems to be somewhat better, but not as good as Chrome.

The experiment I'm running is not very long - it takes about 8 minutes to complete, and participants click 113 times (including a calibration phase). That it's fairly short may explain why I haven't experienced crashes of the sort @TabeaW describes - but it seems that the performance issues may be related. Happy to provide more information if useful.

[ffigari]

Hi, I'm having a similar but slightly different issue. The experiment I need to run takes ~15 minutes to complete. I record however 9 screen positions. If some criteria is met then I recalibrate (call clearData from WG) and I record again 9 positions. I have had crashes with at most 3 of those calibrations. I do run a second facemesh model to detect this decalibrations. That component on its own and the facemesh demo up here are running smoothly. Any idea on what could be causing this? Or any tip on how to debug it? This is happening both on Firefox and on Chromium, using Linux. On Firefox I don't get any kind of error reported. On chrome I got Error: Failed to compile fragment shader. tf backend and

[.WebGL-0x1b9000951000] GL_OUT_OF_MEMORY: Internal error: 0x00000505: Unexpected driver error.
57[.WebGL-0x1b9000951000] GL_CONTEXT_LOST_KHR: Context has been lost.
bivaw9yzvv.cognition.run/:1 WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost
bivaw9yzvv.cognition.run/:1 WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost
256WebGL: INVALID_OPERATION: clientWaitSync: object does not belong to this context
tf-backend-webgl.js:3859 WebGL: too many errors, no more errors will be reported to the console for this context.

in different crashes. Before the crashes the performance drastically decreases. Is there any info on how WG evolves over time in terms of memory?

Edit 2 days laters: I did a more succinct demo without the extra facemesh model and with only 2 clicks. The app still crashed on Firefox but it took it ~45 minutes this time

Second edit: In another experiment without extra face mesh model the tab crashed once again after ~12 minutes. In this case I had ~8 recalibrations with 9 points each. Besides, I think the crash time is related to whether or not a face is present in the camera. The tab being in background seems to influence too.

[ffigari]

left a couple of extra details here https://github.com/jspsych/jsPsych/discussions/2490

[jeffhuang]

Thanks for the report. I'm trying to look into this but it's a little hard to reproduce. If you use the Performance profiler in Chrome, and record a session that goes until it crash, do you notice anything suspicious in terms of memory usage continuing to increase even after a few minutes? (there's a Memory checkbox that turns on memory visualizing)

[ffigari]

Hey @jeffhuang my best guess is that the used facemesh model has some underlying issue causing the crash, but I could not found a specific reason

[jeffhuang]

hi all, could you check if you still encounter the issue in the latest WebGazer here in github? I think updating facemesh should have fixed it (thanks @ffigari for identifying and solving the issue)

[ffigari]

great to see the change merged into the main repo @jeffhuang. As a remainder, the way the bounding boxes are computed is not the same as before. Maybe an extra check should be done to ensure the new way work as expected?

[jeffhuang]

you're talking about the green/red box to encourage users to be near the center? it looked fine to me

but I've now tweaked it to account for the eye width/height as well, since I was already looking at that code

[jeffhuang]

closing because I think the issue is resolved in release 3.0.0 but please let me know if you see it again. it's hard to test for situations that last this long