Consistent Max4Live Crash in Editor - JsliveAPI and Callbacks
I'm building a patch to work with Push. It uses the LiveAPI objects in javascript to grab controls (like the button matrix or encoders) on a Push 2. I setup the property of the Live Object to "value" and get the updates in my callback. When I test this in the Max editor (opened from Live), I get crashes on continuous updates (like changing an encoder). When I run the patch just inside of live, everything is fine.
Sample code:
Control.prototype.init = function(){
var control = push.api.call("get_control_by_name", this.id); //push.api is -> new LiveAPI("control_surfaces " + i);
log("init: " + this.id);
push.api.call("grab_control", control);
var id = this.id;
this.object = new LiveAPI(function(value){
//anything in this callback will crash randomly. A simple log also crashes
if (value && value[0] == "value" && value[1] != "bang"){
manager.changeControl(id, value[1]);
}
}, control);
this.object.property = "value";
};
----
Anyone run into something similar? I've tried throwing the callback into a Task (or starting a Task) to defer, but no luck. Weird it fails in the Editor, but works fine as a live patch.
Here is the crash dump snippet:
Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread
0 libmozjs185.dylib 0x0000000116a01297 JS_EncodeString + 7
1 jsliveapi 0x000000011722bc2a jsliveapi_restring_jsstring(JSContext*, JSString*, unsigned char*) + 31
2 jsliveapi 0x000000011722a962 jsliveapi_jsvalarray_to_jsstring(_jsliveapi*, JSContext*, long, unsigned long long*, JSString**) + 156
3 jsliveapi 0x000000011722bac9 jsliveapi_callback(_jsliveapi*, JSContext*, char*, char, long, symbol*) + 770
4 jsliveapi 0x0000000117229ef6 jsliveapi_sendmessage(_jsliveapi*, char const*, char*) + 657
5 com.cycling74.Max 0x00000001027c62be object_method_imp + 427
6 com.cycling74.MaxAudioAPI 0x000000010d30c4ad liveowner_api_sendmessage + 352
7 com.cycling74.Max 0x00000001027c919a object_method_typedfun + 87
8 com.cycling74.Max 0x0000000102972894 maxservercontext_object_method_typed + 197
9 com.cycling74.Max 0x00000001027c919a object_method_typedfun + 87
10 com.cycling74.Max 0x00000001029721df maxservercontext_processconnection + 49
11 com.cycling74.Max 0x0000000102972187 maxserver_serviceconnections + 172
12 com.cycling74.Max 0x00000001029706f0 maxremote_readmessage + 185
13 com.cycling74.Max 0x00000001029711c1 remote_object_method_typed_flags + 329
14 com.cycling74.Max 0x0000000102971072 remote_object_method_typed + 29
15 com.cycling74.MaxAudioAPI 0x000000010d30c1b5 liveowner_api_handlemessage + 154
16 com.cycling74.Max 0x00000001027c919a object_method_typedfun + 87
17 jsliveapi 0x000000011722a813 jsliveapi_handlemessage(_jsliveapi*, char const*, char*, unsigned char) + 262
18 jsliveapi 0x0000000117229b44 jsliveapi_free(_jsliveapi*) + 54
19 com.cycling74.Max 0x000000010271314b freeobject + 277
20 libmozjs185.dylib 0x0000000116a5371d JSCompartment::finalizeObjectArenaLists(JSContext*) + 1093
More general, it's an interesting question what is the difference between running in Live or running in Max editor... From my experience these are crirical
inter-device communication [send ---foo]
timing, editor is much slower
console gets sometimes out of order
memory consumption much higher with the editor open
Not sure if one of these is causing your problem... In your code I find the use of a local variable (id) in the callback suspicious. I don't know what js makes out of it, what the value of id is when the callback runs out of the context of the function? But as you say it works in Live, it might not be the problem.
The MFL editor is a separate process which communicates with the MFL runtime over a network connection.
Send and receive, for example do not work from Max to MFL because they are in different memory spaces. Send and receive inside an MFL device is handled by the flow of data between processes.
My guess is that whatever you are doing in your js code is somehow not getting "transmitted"
There might be something we could look at. If you can wrap it all up in an example set and fire it into support we can have a peek at it.
This interapp communication is potentially at the heart of @hollyhook's observations.
-A