Hi Chris,
I’m using MWorks 0.6 and testing with a workspace file (open /Applications/MWClient.app --args workspace.json).
When I start with a workspace file, I get very strange event timing in the stream that goes to Matlab.
Some event codes have timestamps before the previous code in the stream (as measured in the event structure that gets passed to Matlab). Previously the sequence was always monotonically non-decreasing.
And the codes and values jump around a bit - the codes I see in the workspace-startup stream appear to be out of order.
(The problems seem to occur near variable changes that call into the Labjack driver we use, but not always - not sure if this is related.)
Can you look into this? Let me know if you need more info.
Thanks,
Mark
Example sequence from a normal startup (clicking icons in dock).
Note some codes omitted for brevity.
Fields: event time (us); diff from prev code (us); code #; code name (from codec)
5407349751 0 197 sync
5407349753 2 201 trialStart
5407349755 2 191 juice
5407349758 3 199 leverResult
5407349760 2 189 laserTriggerFIO
…
5407349960 2 242 tDidLeverPressTasks
5407370342 20382 236 debugUs
5407380510 10168 237 tempMs
5407380539 29 247 tSvStimNumber
5407380541 2 244 tTempStimOdds
5407380550 9 244 tTempStimOdds
5407380557 7 244 tTempStimOdds
Example from a workspace startup:
963541879 0 197 sync
963541882 3 201 trialStart
963541883 1 191 juice
963541886 3 199 leverResult
963541888 2 189 laserTriggerFIO
…
963542063 2 242 tDidLeverPressTasks
963539465 -2598 190 strobedDigitalWord
963539937 472 190 strobedDigitalWord
963540419 482 190 strobedDigitalWord
963540948 529 190 strobedDigitalWord
963541389 441 190 strobedDigitalWord
963541879 490 197 sync
963541882 3 201 trialStart
963541883 1 191 juice
More examples.
Standard:
5408396033 2 269 tTotalRewardUl
5408396035 2 198 pumpAmountUl
5408396041 6 200 stimulusOn
5408396043 2 190 strobedDigitalWord
Workspace:
963572505 3 269 tTotalRewardUl
963572507 2 198 pumpAmountUl
963572513 6 200 stimulusOn
963571522 -991 237 tempMs
One thing that might be unclear:
This behavior happens for every trial of a MWorks session, depending on how the Client is started. So starting with a workspace gives these negative-time-difference events on every trial, until MWorks is quit.
Mark
Hi Mark,
open /Applications/MWClient.app --args workspace.json
I’m surprised that works at all. Is the client already running when you issue this command, or are you trying to start the client and load the workspace in one shot? When I attempt the latter, the client crashes on me. You may be seeing memory corruption instead. I’ll try to figure out what’s going wrong.
In the meantime, if you want to launch the client and load a workspace from the command line or a shell script, I recommend doing it like this:
open /Applications/MWClient.app
sleep 3 # Give the client a moment to start up
open -a /Applications/MWClient.app workspace.json
Also, what happens when you open the workspace via “File->Open Workspace”? Do you still see the timestamp issue?
Chris
Hi Chris,
Yes, sounds it could be a memory corruption issue.
Your workaround works.
We definitely would like to start the client and load the workspace in
one command, or at least immediately afterwards, so if you could look
into making that possible, it would be great.
thanks,
Mark
Hi Chris,
I’m not sure where we left this - have you been able to see whether it’s possible to pass the workspace file to MWClient at startup in a way that doesn’t require a fixed delay? We’ve found we need to use 4s to avoid problems.
Thanks,
Mark
Hi Mark,
I fixed the bug that was causing MWClient to crash when I tried to launch the app and load a workspace in one shot. I don’t know if that will resolve the timestamp issue you’re seeing, but I hope it will.
The fix is in the current nightly build. Please try it when you have a chance.
Thanks,
Chris
Hi Chris,
I tested this. The experiment seems to load fine in a first simple test.
Thanks.
However two things I observed:
- If the experiment xml has an error, starting using workspace just leaves
the experiment unloaded. I didn’t see the typical red error message.
- I’m seeing the below crash from time to time. I believe it happens on
exit if I Cmd-Q the server before Cmd-Q on the client. I’ve seen it
happen in thread 8,9, and 11 below:
Crashed Thread: 8
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
Performing @selector(terminate:) from sender NSMenuItem 0x6100000bba80
terminating with uncaught exception of type
mworks_boost::exception_detail::clone_impl<mworks_boost::exception_detail::error_info_injector<mworks_boost::lock_error>
: boost: mutex lock failed in pthread_mutex_lock: Invalid argument
abort() called
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fffad52719e poll + 10
1 MWorksCore 0x000000010736056e
zmq::signaler_t::wait(int) + 58 (signaler.cpp:218)
2 MWorksCore 0x000000010734f6e9
zmq::mailbox_t::recv(zmq::command_t*, int) + 169 (mailbox.cpp:81)
3 MWorksCore 0x0000000107346f3b
zmq::ctx_t::terminate() + 485 (ctx.cpp:166)
4 MWorksCore 0x0000000107373e51 zmq_ctx_term + 35
(zmq.cpp:167)
5 MWorksCore 0x000000010731cb92
std::__1::unique_ptr<void, mw::(anonymous
namespace)::ContextDeleter>::~unique_ptr() + 30
6 libsystem_c.dylib 0x00007fffad48c178 __cxa_finalize_ranges
- 332
7 libsystem_c.dylib 0x00007fffad48c4b2 exit + 55
8 com.apple.AppKit 0x00007fff95978882 -[NSApplication
terminate:] + 1851
9 libsystem_trace.dylib 0x00007fffad6293a7
_os_activity_initiate_impl + 53
Hi Mark,
If the experiment xml has an error, starting using workspace just leaves the experiment unloaded. I didn’t see the typical red error message.
I’m not able to reproduce this. When I load an experiment with an error, I do see the error message in the server console. Can you send me an example experiment that demonstrates the problem?
I’m seeing the below crash from time to time. I believe it happens on exit if I Cmd-Q the server before Cmd-Q on the client. I’ve seen it happen in thread 8,9, and 11 below:
OK, let me investigate.
Chris
I’m seeing the below crash from time to time. I believe it happens on exit if I Cmd-Q the server before Cmd-Q on the client.
The fix for this should be in tonight’s nightly build.
Chris
I’m seeing the below crash from time to time. I believe it happens on exit if I Cmd-Q the server before Cmd-Q on the client.
The fix for this should be in tonight’s nightly build.
Sorry, I didn’t get it in yesterday. It will be in tonight’s nightly build.
Chris