Closed benjamin-heasly closed 2 years ago
I reworked mglMetalOpen
to try to avoid this issue.
When we want to reconnect to an existing mglMetal process, instead of passing the screen number nan
, we can set the MGL param, reuseMglMetal
, as in mglSetParam('reuseMglMetal', 1);
. This will tell mglMetalOpen
to reconnect instead of starting a new process.
If we want to hunt for the nan
issue we can, but for now I'll close this in favor of just avoiding the issue in the first place.
I've seen an intermittent Matlab crash scenario, while testing with mglMetal. I haven't gotten a consistent reproduction for this yet, but I think it's worth noting, anyway.
This seems to come up when I connect Matlab to an already-running instance of mglMetal. This is useful when staring mglMetal from Xcode, with the console logger and debugger attached.
The crash log is not clear and I don't see a stack with an mgl mex file in it. I do see something about the heap free list being corrupted. My current best guess is that something is using the
nan
screen number in a way we don't expect, and perhaps calling free on an unexpected address.It's vague at this point, but here's a place to collect info, next time this happens.