Ableton Forum

This is a complete crash of the MAX system when enabling Java debug options while developing a M4L component that includes a java mxj component.

Java options set in max.java.ci=onfig.txt file were
max.jvm.option -Xdebug
max.jvm.option -Xnoagent
max.jvm.option -Djava.compiler=NONE
max.jvm.option -Xrunjdwp:transport=dt_socket\,address=5006\,server=y\,suspend=n
; max.jvm.option -XX:-UseSharedSpaces ;

Note: I also tried the settings with this line commented or uncommented
; max.jvm.option -XX:-UseSharedSpaces ;

This is a MacPRO 8-core running Snow Leopard 10.6.1 and Java 6 Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)

Reproduction :This crash happened quite a few times, even after restarting Live and closing MAX. However sometimes I've been lucky and it will launch with debug settings.
1. Create an M4L component with an mxj object in it.
2. Edit the max.java.config.txt file to point to where your mxj class files are.
3. Try to edit the M4L component using the edit button on the component in Live.

Workaround: disable debug java options

The core dump is quite large so I emailed it separately, but here is the first section

Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x920fd912 __kill + 10
1 libSystem.B.dylib 0x920fd904 kill$UNIX2003 + 32
2 libSystem.B.dylib 0x92190b99 raise + 26
3 libSystem.B.dylib 0x921a6c50 abort + 93
4 libclient.dylib 0x1c1fd6d7 JVM_RaiseSignal + 391079
5 libclient.dylib 0x1c15f51c pss + 394412
6 libjdwp.jnilib 0x1c36f910 Agent_OnLoad + 8164
7 libjdwp.jnilib 0x1c370743 Agent_OnUnload + 3239
8 libjdwp.jnilib 0x1c36fd87 Agent_OnUnload + 747
9 libclient.dylib 0x1bf95b8f JVM_IsPrimitiveClass + 8527
10 libclient.dylib 0x1beca428 JNI_CreateJavaVM_Impl + 7256
11 libclient.dylib 0x1bec8845 JNI_CreateJavaVM_Impl + 117
12 com.cycling74.mxj 0x1bba44cc jvm_new + 386
13 com.cycling74.mxj 0x1bba79d5 maxjava_new + 305
14 com.cycling74.MaxMSP 0x0001c341 typedmess_fun + 1973
15 com.cycling74.MaxMSP 0x000b99ff object_new_typed_flags + 637
16 com.cycling74.MaxMSP 0x000b9a3e object_new_typed + 46
17 com.cycling74.MaxMSP 0x00011209 newload_internal + 93
18 com.cycling74.MaxMSP 0x00011556 newload + 40
19 com.cycling74.MaxMSP 0x0001c341 typedmess_fun + 1973
20 com.cycling74.MaxMSP 0x0001c3cb typedmess + 83
21 com.cycling74.MaxMSP 0x0001ca37 aeval + 893
22 com.cycling74.MaxMSP 0x00008204 atombuf_eval + 152
23 com.cycling74.MaxMSP 0x0015edf7 jnewobj_new + 2283
24 com.cycling74.MaxMSP 0x0001c341 typedmess_fun + 1973
25 com.cycling74.MaxMSP 0x000b99c4 object_new_typed_flags + 578
26 com.cycling74.MaxMSP 0x000b9a3e object_new_typed + 46
27 com.cycling74.MaxMSP 0x0016c464 jpatcher_newobject + 346
28 com.cycling74.MaxMSP 0x0016c97b jpatcher_pastefromdictionary + 403
29 com.cycling74.MaxMSP 0x0017b1d4 jpatcher_fromdictionary + 1692
30 com.cycling74.MaxMSP 0x0017b56a jpatcher_new + 900
31 com.cycling74.MaxMSP 0x0001c341 typedmess_fun + 1973
32 com.cycling74.MaxMSP 0x000b99ff object_new_typed_flags + 637
33 com.cycling74.MaxMSP 0x000b9a3e object_new_typed + 46
34 com.cycling74.MaxMSP 0x00010783 jpatcher_load_fromdictionary(char*, short, object*, short, atom*) + 437
35 com.cycling74.MaxMSP 0x00010902 jpatcher_load_frombuffer(char*, short, char const*, long, short, atom*) + 310
36 com.cycling74.MaxMSP 0x000109b2 lowload_jpatcher_frombuffer + 76
37 com.cycling74.MaxAPI 0x04ee8e13 lowload_jpatcher_frombuffer_withobexprototype + 45
38 com.cycling74.MaxAudioAPI 0x05e813e6 pluginterface_createjpatcher + 891
39 com.cycling74.MaxAudioAPI 0x05e871e7 liveowner_new + 775
40 com.cycling74.MaxMSP 0x0001c341 typedmess_fun + 1973
41 com.cycling74.MaxMSP 0x000b99ff object_new_typed_flags + 637
42 com.cycling74.MaxMSP 0x000b9a3e object_new_typed + 46
43 com.cycling74.MaxMSP 0x0020aa12 maxservercontext_object_new_typed(_maxservercontext*, symbol*, long, atom*, atom*) + 150
44 com.cycling74.MaxMSP 0x000b59f7 object_method_typed + 127
45 com.cycling74.MaxMSP 0x0020a5aa maxservercontext_processconnection(_maxservercontext*) + 66
46 com.cycling74.MaxMSP 0x0020a64c maxserver_serviceconnections + 80
47 com.cycling74.MaxMSP 0x00029cb5 sched_dequeue + 119
48 com.cycling74.MaxMSP 0x0001217f max_tick + 77
49 com.cycling74.MaxMSP 0x001dcc1e maxapplication_eventtimerproc(__EventLoopTimer*, void*) + 22
50 com.apple.CoreFoundation 0x975f2eee __CFRunLoopRun + 6846
51 com.apple.CoreFoundation 0x975f0d34 CFRunLoopRunSpecific + 452
52 com.apple.CoreFoundation 0x975f0b61 CFRunLoopRunInMode + 97
53 com.apple.HIToolbox 0x91620fec RunCurrentEventLoopInMode + 392
54 com.apple.HIToolbox 0x91620cdf ReceiveNextEventCommon + 158
55 com.apple.HIToolbox 0x917a8d91 ReceiveNextEvent + 83
56 com.cycling74.MaxMSP 0x002c972e juce::juce_dispatchNextMessageOnSystemQueue(bool, bool) + 554
57 com.cycling74.MaxMSP 0x002d3213 juce::MessageManager::dispatchNextMessage(bool, bool*, bool) + 79
58 com.cycling74.MaxMSP 0x002d32d2 juce::MessageManager::runDispatchLoop() + 42
59 com.cycling74.MaxMSP 0x002d1c2d juce::JUCEApplication::main(juce::String&, juce::JUCEApplication*) + 605
60 com.cycling74.MaxMSP 0x002d1d07 juce::JUCEApplication::main(int, char**, juce::JUCEApplication*) + 125
61 com.cycling74.MaxMSP 0x001dd05a main + 76
62 com.cycling74.MaxMSP 0x00005826 _start + 216
63 com.cycling74.MaxMSP 0x0000574d start + 41

I suspect this is because the Max environment in Live starts up a JVM (which opens debug ports), and when a device is opened in Max itself a new JVM is created which tries (and fails) to open the debug ports, and hence aborts.

What we need is some conditional test inside the Max Java config file, or something.

That sounds like a pretty viable explanation. I must admit that I find the mxj lifecycle a bit confusing in M4L. Not having an understanding of who is a actually spawning the JVM, I would be happy if JVMs running in Live did not use debug options and JVMs running in MAX did. Or have a separate section.

I will say though that having mxj capabilities is awesome and I thank the developers for allowing it in M4L. Truly fantastic being able to have a mixed language environment.

Got it. We should be able to nail this down, but not before the next beta.

[ddg]
T#355

Can you tell us exactly which JVM options you would like disabled? Is it just -Xdebug?

Here are the possible options for debugging

max.jvm.option -Xdebug
max.jvm.option -Xnoagent
max.jvm.option -Djava.compiler=NONE
max.jvm.option -Xrunjdwp:transport=dt_socket\,address=8074\,server=y\,suspend=n

My understanding which may not be correct is that there is always one active jvm spawned in Live and 1 in MAX. If this is correct, then the best option would be able to either have separate settings for each environment, or to be able to override options in Live.

For example these entries override the max entries above for the JVM in Live.

m4l.jvm.option -Xdebug
m4l.jvm.option -Xnoagent
m4l.jvm.option -Djava.compiler=NONE
m4l.jvm.option -Xrunjdwp:transport=dt_socket\,address=8076\,server=y\,suspend=n

Or use a separate file that overrides properties like
max.java.config.txt
m4l.java.config.txt

That way, we could choose a different port in Live and the issue would go away.

I believe -Xrunjdwp:transport is the culprit here because it sets the port

barnone wrote:the best option would be able to either have separate settings for each environment, or to be able to override options in Live.
...
That way, we could choose a different port in Live and the issue would go away.

Although this seems ideal, having separate settings for Max and for Live introduces some unwanted complexity.

Stepping back for a moment, let's think about when you actually need debugging features. What if JVM debugging features were always disabled inside Live, but still worked in the Max editor window? So if you want to debug anything, you'd just need to click the edit button and leave the Max editor window open while you debug.

That seems like a good solution to me.
barnone, what do you think?

The problem is that some of the objects especially regarding the LOM only work inside of Live. I find myself actually connecting with the debugger more when the components are running in Live then when they are open in MAX.

The other option is just leave it the way it is, but fix the crash, so if the debugger is already connected the new JVM just doesn't get the connection. This is more the way it would work in other environments and that would be fine.