The MWServer seems to crash every time I try to quit. I must use Force Quit.
That isn’t much for me to go on. Can you provide more details? Specifically:
Are you trying to quit MWServer before or after you unload the experiment?
Does this happen if you open MWServer and then immediately quit it, without loading any experiment?
Does this happen for every experiment, or just specific experiments? If only some experiments, do these make use of any of your lab’s custom plugins (e.g. the BlochSound plugin)?
Also, can you send me a crash report associated with force-quitting MWServer? To do this: On the machine running MWServer, open the Console application (/Applications/Utilities/Console.app ). In the sidebar, select Crash Reports. In the list that appears, find one with MWServer in the name. You should be able to drag and drop it in to an email message.
When I reload an experiment, previous errors are not listed under “Details”
OK, but I don’t know why you’d expect them to be.
Honestly, that window isn’t very useful. If you want to see error messages, I would just use the Server Console window (or, equivalently, the Console window available via MWClient’s magnifying glass button). If you want to filter out non-error messages, you can deselect the “message bubble” and warning triangle buttons at the bottom left of the console window. Note that you have to do this before the messages are generated, since it doesn’t filter already-visible messages (although it really should).
Are you trying to quit MWServer before or after you unload the experiment?
I was trying to quit it without unloading the experiment, after quitting the MWClient. If I try to close the experiment while the application is open, but not running, I get a “quit unexpectedly” error from Apple. I have attached the error report as a .docx.
Does this happen if you open MWServer and then immediately quit it, without loading any experiment?
No.
Does this happen for every experiment, or just specific experiments? If only some experiments, do these make use of any of your lab’s custom plugins (e.g. the BlochSound plugin)?
This happens whether or not we use the BlochSound plugin.
Thanks for the tips about viewing error messages. I think it should be fine to view them in the Server Console window, as you suggest.
According to the crash report, there’s a failed assertion during destruction of the LabJackU6Device – specifically, the first assertion in detachPhysicalDevice. Based on my understanding of the code, that assertion should never fail if the experiment loaded successfully. Therefore, I suspect the failure results from some kind of memory corruption.
The most likely cause of such corruption is a mismatch between the version of MWorks that the LabJack plugin was compiled against and the version of MWorks you’re running. If you’re running MWorks 0.12, then you must compile all of your custom plugins (LabJack, BlochSound, etc.) against MWorks 0.12, too. If you don’t, the result is going to be random crashes like this.
If you’re sure that the plugin was compiled against the appropriate MWorks version, and you still see this issue, please let me know, and we’ll explore other possibilities.
Crash with MWServer: @Nina Friedman can you make sure the plugins are all compiled on the same machine you’re running MWorks, with the same version of MWorks you’re running? (ps Chris I removed the need for our old BlochSound plugin so that is no longer being loaded.)
Re: the red X in the Client window: specifically, our use case is this: we launch Client and Server using a Workspace file. When this happens we don’t have the ability to deselect the warning and info messages, but we’d like to see the error messages without having to scroll through all of those. But when we start the client with a workspace that loads an experiment, the error messages don’t make it into the red X window. If you wanted to remove the red X window, that would also be ok with us.
Is that all the issues in this thread? Thanks! Mark
When this happens we don’t have the ability to deselect the warning and info messages, but we’d like to see the error messages without having to scroll through all of those.
I see. I think that’s an argument for making the filter buttons apply to already-printed messages, too. That seems like a good and sensible change to me.
But when we start the client with a workspace that loads an experiment, the error messages don’t make it into the red X window.
Based on some quick testing, it looks like that’s true only if the client isn’t connected to the server when you load the workspace (and therefore the connection is made as part of loading the workspace – which, to be clear, is absolutely something workspaces are meant to do). Let me try to figure out why that’s happening.
If you wanted to remove the red X window, that would also be ok with us.
I suppose it is convenient for quickly seeing error messages (though I generally forget that it exists at all). Let me see how hard it is to get working correctly in your workspace-loading scenario.
Crash with MWServer: @Nina Friedman can you make sure the plugins are all compiled on the same machine you’re running MWorks, with the same version of MWorks you’re running? (ps Chris I removed the need for our old BlochSound plugin so that is no longer being loaded.)
I compiled all the plugins with the same version of MWorks, so there may be another issue.
Having the filter buttons apply to old messages would be great!! It would help in other ways too.
If you do that there is no need for the big red button and we’d be happy to have it removed. Mark
Having the filter buttons apply to old messages would be great!! It would help in other ways too. If you do that there is no need for the big red button and we’d be happy to have it removed.
After building and installing the LabJack plugin, I can load an experiment with a LabJack device, run it, re-run it, unload it, re-load it, run it again, and quit MWServer without any issue.
One comment: You said you’re running MWorks 0.12, but in another discussion, the actual version you were running is “0.12.dev (2023.03.01)”. In case it wasn’t clear, that date stamp at the end matters. If you compile a plugin against “0.12.dev (2023.03.01)”, you can’t run it against, say “0.12.dev (2023.04.16)”. The version must be exactly the same. You’re probably already aware of this, but I just want to make sure.
I’ve attached my build of the plugin, in case you want to try it. As I said, it’s compiled against the release version of MWorks 0.12.2, so you can only use it with that.
Thank you so much, I don’t mind the clarification this is helpful- I am running 0.12.dev (2023.03.01), which is the version I compiled against. I reinstalled the LackJack bundle smoothly using your attachment, compiled against 0.12.dev (2023.03.01), and I am still seeing the MWServer crash. At this point I am not sure where the difference lies. I believe Mark sees the same issue.
I reinstalled the LabJack bundle smoothly using your attachment, compiled against 0.12.dev (2023.03.01), and I am still seeing the MWServer crash.
I don’t understand: You installed my plugin bundle, then immediately replaced it with one you compiled yourself?
As I said previously, the plugin bundle I sent you is built against MWorks 0.12.2, so you can only use it with that. My idea was for you to do the following:
I used your version of MWorks 0.12.2 and your version of the LabJack Plugin. I uninstalled the previous version of MWorks, installed your version, and compiled the plugin against MWorks. The bundle is in the correct location as specified. I’m using an Intel chip. The crash report from today is attached.
Thanks for all the clarifications, they are helpful.