MWServer crash

Support
1

Hi Chris,

Thank you for your help with locating these! I found the crash reports (I’d forgotten to mention, it actually failed 2 times within a few minutes - both running RF finder) from earlier this week and have attached them below. I’m not sure what to look for within the reports, but do these give you any insights into why the crashes are occurring?

Thanks again,

Jack

2

Hi Jack & Yasmine,

Thanks for sending the crash reports. Along with your experiment code, I think they do reveal what’s happening.

I believe there are two issues. First, in your experiment, you use the following pattern to unload and reload the parametric shape stimulus:

dequeue_stimulus(shapes_para_stimulus)
unload_stimulus(shapes_para_stimulus)
load_stimulus(shapes_para_stimulus)

The problem with this is that dequeue_stimulus doesn’t immediately remove the stimulus from the set of displayed stimuli. Instead, as noted in the docs, it marks the stimulus for removal upon completion of the next update_display action. On the other hand, unload_stimulus acts immediately, as the whole point of the load/unload actions is to perform loading/unloading outside of the normal display rendering loop. The upshot of this is that the shape stimulus might be drawn after being unloaded. Based on the crash reports, it looks like this is indeed happening.

Although this is an error in your experiment code, the result should be error messages about your stimulus not being loaded, not an MWServer crash. The crash is occurring because of the second issue. While MWorks actively tries to avoid drawing unloaded stimuli, your crash reports revealed a scenario that we weren’t catching. Attempting to draw the unloaded stimulus led to a hard crash somewhere in the graphics driver.

So, there are two action items here. First, you should use the following pattern to unload and reload a stimulus:

dequeue_stimulus(shapes_para_stimulus)
update_display ()  // This is new
unload_stimulus(shapes_para_stimulus)
load_stimulus(shapes_para_stimulus)

Second, I need to fix the bug. That should be very simple: I just need to add another check that the stimulus is loaded and refuse to draw if it isn’t. I will get that in to the nightly build soon.

Cheers,
Chris

3

Hi Chris,

This explains a lot! I’ll add the line to update_display(), and
hopefully this works to solve the crashing problem. My way of preventing
the stimulus from being drawn before it had been loaded was to add a
variable “processor_check” that would prevent the queue_stimulus actions
from occurring before load_stimulus, but it makes sense that this didn’t
fully prevent the errors.

Thanks for your help!

Jack

4

Hi Jack,

Second, I need to fix the bug. That should be very simple: I just need to add another check that the stimulus is loaded and refuse to draw if it isn’t.

This fix is now in the nightly build.

Cheers,
Chris

5

Hi Chris,

Thanks for making these changes and letting me know! Just to check, have
the modifications to the parametric shape stimulus (vertex_range) also been
included in this build?

Best,

Jack

6

Just to check, have the modifications to the parametric shape stimulus (vertex_range) also been included in this build?

No, I’m still working on that. I’ll be in touch about it later today.

Chris

7

Okay, no worries! Thanks for keeping us updated.

-Jack