Hi Chris,
In the Client, if you have the Variables window open and “All variables” is expanded, if you terminate and reload a Python script (in the client bridge), MWClient will crash.
This is with MWClient 0.5 (73eb095).
Mark
Hi Chris,
In the Client, if you have the Variables window open and “All variables” is expanded, if you terminate and reload a Python script (in the client bridge), MWClient will crash.
This is with MWClient 0.5 (73eb095).
Mark
Hi Mark,
I haven’t been able to reproduce this crash. Do you have an example experiment and Python script that consistently causes the crash for you?
Thanks,
Chris
Hi Chris
I couldn’t reproduce on my laptop either, but I could on a live rig
computer.
It’s a deadlock, I think. I’m attaching the stack trace.
I’m using Matlab r2012b on Mac OS 10.8 and MWorks Version 0.5 (73eb095).
I’ll see if I can reproduce this with a simple experiment/python script.
Mark
Attachment: MWClient-trace.txt (369 KB)
This test experiment (.xml, matlab and python) reliably deadlocks if you
load the experiment and python script into the client bridge, run many
trials (set up to do 10000 on each start) and then terminate and reload the
script.
It seems to only crash the client if events are pending in the matlab
window when the Python script is reloaded.
I’m not 100% sure this is the same crash/deadlock we see, but a single
trial can take 2-3s for our matlab scripts to process, so it could be. I
didn’t find any dependence on having the variables tree revealed, but I
didn’t look hard.
Also, the testcase shows another issue - once everything is loaded, if you
alternate running trials, alternately loading and reloading the python
script, and reselecting the .m file (by clicking the “Select .m file”
button and choosing the test.m script), the server will eventually start
printing “Send on outgoing queue failed” and may or may not crash. We
sometimes see that message from the server and have to restart all the
MWorks programs. It usually only happens at the beginning of a session,
and I’ve never been able to figure out how to cause it reliably. Again
this error may not be the exact same error we see.
Thanks,
Mark
Attachment: testcase-histed-130728.zip (2.85 KB)
Hi Mark,
Thanks a lot for the test experiment. I can reliably reproduce the deadlock (and sometimes get MWClient to crash). I’m still working on a fix for the problem, but I’ll let you know as soon as I have one.
Chris
Great - keep me posted! Mark
Hi Mark,
I think I’ve eliminated the deadlock. I can now reliably reload your Python script with events pending in the MATLAB window, without the client freezing. The fix should be in tonight’s nightly build.
the server will eventually start printing “Send on outgoing queue failed” and may or may not crash
Yeah, I see that error sometimes, too. I believe the issue is that, after it’s been used once, the Python bridge keeps trying to send events to the Python script, regardless of whether it’s still running. Once the outgoing event queue fills up, further attempts to send produce that error. It seems like we should destroy the event conduit when the Python script terminates. I’ll look in to that.
Chris
I think I’ve eliminated the deadlock. I can now reliably reload your Python script with events pending in the MATLAB window, without the client freezing. The fix should be in tonight’s nightly build.
Great!
Once the outgoing event queue fills up, further attempts to send produce that error. It seems like we should destroy the event conduit when the Python script terminates. I’ll look in to that.
Please do - we still see this about 10% of the time we don’t do a completely clean startup (which task files will make easier).
thanks,
M
Hi Mark,
the server will eventually start printing “Send on outgoing queue failed” and may or may not crash
This should be resolved now, too. The fix will be in tonight’s nightly build.
Cheers,
Chris