MWorks: Error with long variable names

Support
1

Hi Chris,

I have an experiment with some variables whose names are as many as 33 characters long. The python server bridge appears to dislike them. The client bridge works fine. I’m attaching a simple testcase experiment and python file that produces a crash when using the server bridge but works for the client bridge.

Thanks,
Mark

2

Attachments:

3

Hi Mark,

Thanks for the bug report. I’m seeing crashes with both the client and server conduits, with the following output:

Assertion failed: (! detail::singleton_wrapper< T >::m_is_destroyed), function get_instance, file /Library/Application Support/MWorks/Developer/include/boost/serialization/singleton.hpp, line 131.

Is that what you see, too?

Chris

4

That is a second error, which I also see sometimes but not always. (Often after launching a Python conduit, terminating it, and launching a second.). I saw it with both conduits.

The error I was seeing was from the conduit: “Timeout while waiting for codec”. That was only with the server conduit.

Mark

5

Hi Mark,

I haven’t seen the “Timeout while waiting for codec” error. Can you give me some more details about the steps you use to reproduce it? Do I need to have a MATLAB script running, too?

Thanks,
Chris

6

Interesting. I see it on one machine but not another. I will look into it further and keep you posted. Thanks, Mark

7

I figured out what is going on.

Using the longVars.xml/py I just sent you, uncommenting the ‘server_conduit’ line in the python script and running both when MWClient and Server have just been restarted causes the timeout error (attached).

However, this is because the experiment is missing the server conduit IODevice. It works if you add this to the XML:

Second issue: There also appears to be an interaction involved in reloading experiements. If you load an experiment with the server_conduit IO device, close it, and load the testcase without the IODevice, it sometimes works.

Third issue: I sporadically see the assertion error you just sent.

Apologies for confusion; the timeout appears to be due to the missing IODevice, not long variable names. Perhaps you can modify the error message to say something about the IODevice?

Mark

8

Attachment: Screen_Shot_2014-05-19_at_4.51.44_PM.png (34.1 KB)

9

Hi Mark,

Thanks for the additional info and explanation.

Second issue: There also appears to be an interaction involved in reloading experiments. If you load an experiment with the server_conduit IO device, close it, and load the testcase without the IODevice, it sometimes works.

The problem here is that the server conduit wasn’t shutting down properly when the experiment closed. This is now fixed.

Third issue: I sporadically see the assertion error you just sent.

The issue here seems to be that the Python process is exiting before the conduit’s worker thread has shut down cleanly. It appears that you can avoid the problem by ensuring that the conduit’s finalize method is called before the process terminates. There are various ways to accomplish this, but one option is to use the atexit module:

client.initialize()
import atexit
atexit.register(client.finalize)

Apologies for confusion; the timeout appears to be due to the missing IODevice, not long variable names. Perhaps you can modify the error message to say something about the IODevice?

Well, it’s hard to know exactly what the problem is from the other end of the conduit, but I’ll see if there’s a way to be a bit more helpful.

Chris

10

Thanks for this, Chris - great.
Mark