Ever since v1.84, I’ve been sticking to 1.83.04 since the newer versions were generating all sorts of error messages for even basic scripts that were previously working (see my older threads).
Now with 1.85.01, I was hoping that these were fixed, and so I upgraded, however these previously-running scripts still appear to crash, this time with the error “Fatal Python error: (pygame parachute) Segmentation Fault”.
Previous threads I found that are related this error seem to indicate scenarios different from mine (e.g. components/dependencies that I do not have etc). Also, the fix that Jon suggests here unfortunately does not help in this case.
I progressively deleted components and routines from the script until I was only left with a simple text component that doesn’t even have its text displayed at EveryFrame; the script still crashes even so. I uploaded this minimal version here.
Going back to 1.83.04, the script works well with no such error. Any thoughts? Many thanks!!
Tudor
What happens if you remove the microphone? Most experiments on most systems are not crashing (or this forum would be very noisy!) so we have to wonder what’s different in your study. The fact that you’ve got a mic involved stands out as something less common.
Generally, problems I’ve seen with crashes have revolved around:
too much text updating (but that leads to memory error)
too much printing being done (but that leads to freezing)
problems with the pyo sound lib (which might fit with your issues)
The minimal version (with everything stripped) no longer includes the microphone so I guess that rules it out.
You are right that under these scenarios an error is to be expected. I would only perhaps fit into the third one, though not sure if pyo actually is included in my script. As I said, no more sound components of any kind are left in the minimal version.
My segmentation fault errors also seem related to sound (unlike weird characters or microphone input, etc.).
I read in other threads that pygame is the issue, and googling this error outside of a Psychopy contexts implies that pygame is very unstable and difficult to debug.
I put pyo first in the order of sound library in preferences, and it seems to have cut down on the number of errors, but I am still receiving them, as well as a bus error.
I have seen Jon and others post that sounddevice may be more reliable. I’m just slightly confused on how to get it to work. I have it installed as part of my main python portfolio, but do I need to add it separately to Psychopy’s python directory to actually access it? Right now I just get an error message when I add sounddevice to the sound library in preferences.
Not sure if its useful, but i’ve had a similar issue with sound files on a Dell Latitude E6520 with Windows 7 and PsychoPy 1.85.03b . The following worked fine on 1.83.04 as well.
In a particular builder experiment, I use code to load in some sound files at the very beginning within a code block at the very start in the first routine.
Having this within the “Begin Experiment” area will cause the same segmentation fault error (with no other supporting message to say what caused it).
So sound.Sound(“test.wav”) would give the message every time.
Moving the sound loading code to “Begin Routine” oddly stops the problem from occurring. On more powerful desktop PC’s though, oddly the problem does not occur.
As the laptop is getting on a bit, i’m wondering if there might be a delay fully loading/initializing a particular library in at the stage i’m trying to load the audio now, and hence causing the fault. Moving to “Begin Routine” gives enough time for the library in question to be loaded in, and thus loads the sound files without problem. I’m speculating of course - maybe PYO needs a bit of time to properly initiate on slower machines?
wow @fgasking, your speculation seems to hit the point.
it helped me working around the issue!
I am using the coder:
adding core.wait(.1) between prefs.general[‘audioLib’] = [‘pyo’] and sound.Sound(‘xyz.wav’) was enough to solve the bug in my case
