Crash in MWClient, latest nightly, on launching python client script

Support
1

Hi Chris,

I’m using a nightly from a week or two ago. Sometimes when launching a python script in the client bridge, MWClient crashes with this error.
Does this make any sense to you? Some sort of UI locking error? Crashes are sporadic.

One other very low-priority request: do you think you can display the date of the nightly in MWClient and Server’s About dialog?
I have one Python server bridge crash that I will forward to you once I can create a somewhat reduced testcase.

Best,
Mark

2

Hi Mark,

I’m using a nightly from a week or two ago. Sometimes when launching a python script in the client bridge, MWClient crashes with this error. Does this make any sense to you? Some sort of UI locking error? Crashes are sporadic.

It looks like the crash is occurring in the variables window, although the cause may lie elsewhere. I’ll poke around a little and try to get a better idea of what may be happening.

One other very low-priority request: do you think you can display the date of the nightly in MWClient and Server’s About dialog?

Sure, that shouldn’t be a problem.

Cheers,
Chris

3

Hi Mark,

One other very low-priority request: do you think you can display the date of the nightly in MWClient and Server’s About dialog?

This is done. Starting tonight, the nightly builds of MWClient, MWServer, and MWEditor will include a date suffix in their version number. For example, in tonight’s nightly, the version number will be “0.5.dev-20121019”, rather than just “0.5.dev”.

Sometimes when launching a python script in the client bridge, MWClient crashes with this error.

I haven’t been able to reproduce this crash. Can you give me any more details about when it happens, e.g.

  • Are you launching the Python script before or after loading the experiment?
  • Are other client plugins (e.g. the MATLAB window) running when you load the script?
  • Do you register callbacks for all variables or just a subset?
  • Are you sending any data back to the server (with conduit.send_data)?

Thanks,
Chris

4

The crash typically occurs when the experiment has been loaded and the
Matlab window is open- but that’s just the order that I tend to do things-
haven’t tried the other way around. Mark will know more about whether
we’re registering callbacks or sending data to the server.

Lindsey.

5

This is done. Starting tonight, the nightly builds of MWClient, MWServer, and MWEditor will include a date suffix in their version number. For example, in tonight’s nightly, the version number will be “0.5.dev-20121019”, rather than just “0.5.dev”.

Excellent, thanks. This is better than relying on the timestamp of /Applications/MWServer.app etc.

Sometimes when launching a python script in the client bridge, MWClient crashes with this error.

I haven’t been able to reproduce this crash. Can you give me any more details about when it happens, e.g.

  • Are you launching the Python script before or after loading the experiment?

After loading the experiment (codec is not correct before and I reg all callbacks on Python script startup).
Doesn’t seem to matter if you start Python script before or after loading variables.

  • Are other client plugins (e.g. the MATLAB window) running when you load the script?
    MATLAB window - yes, as lindsey says. Doesn’t seem to matter if the matlab engine is running yet or not, or if any trials have been run before launching Python script
  • Do you register callbacks for all variables or just a subset?

95% of variables including #announceStimulus but no other system ‘#xxx’ variables.

  • Are you sending any data back to the server (with conduit.send_data)?

No.

We also sometimes see an error in the server log “Timeout on conduit” or something similar and we have to restart in that case.

Sorry I can’t be more help - I can’t reproduce this reliably either. It may be related to old copies of the bridge processes still running - there are rare cases where they are still left and I have to kill them by hand.

Mark

6

Well, after many attempts, I still haven’t been able to reproduce this crash.

From the crash log, it appears that some code in the variables window is attempting to access a freed or corrupted object. However, after spending a good amount of time digging through the source, I haven’t found any likely cause of such an error. I did improve a few bits of awkward/silly code (changes will be in tonight’s nightly), but I doubt that will fix the problem.

Without any additional information, I don’t think there’s much more I can do about this issue. But do keep sending me the crash reports and any other relevant info, and hopefully the cause of the problem will become apparent eventually.

Thanks,
Chris

7

Thanks, Chris.
I’ll continue working with it; when crashes happen I’ll see if I can
exactly reproduce what I did and replicate it.
Mark