When subclassing MaxObject and using the NO_INLETS helper definition, this can cause a hard crash in max , in my specific case this caused a crash when entering patching mode from presentation mode
in the constructor for a MaxObject subclass we can use the helper function like this to describe an object with no inlets:
public MyMaxObjectSubClass () {
super();
declareInlets(NO_INLETS);
}
When switching to patching mode it seems that the method getInletAssist(int inletIdx) in MaxObject is called from native code without checking first if there are no inlets and thus throws an index out of bounds error in the java system and bringing down the Max process.
This is evident in OSX but not reproduced in Windows as of the writing of this issue
A work around is to declare at least one inlet even if it is not used.
The native crash report (OSX) can look like this as an indication, and this is also an indicator of where the getInletAssist is being called from the native code.
Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff205e2462 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff20610610 pthread_kill + 263
2 libsystem_c.dylib 0x00007fff20563720 abort + 120
3 libjvm.dylib 0x000000012df89aa1 os::abort(bool) + 25
4 libjvm.dylib 0x000000012e0b1e9e VMError::report_and_die() + 2306
5 libjvm.dylib 0x000000012df8b6e6 JVM_handle_bsd_signal + 1131
6 libjvm.dylib 0x000000012df8792b signalHandler(int, __siginfo*, void*) + 47
7 libsystem_platform.dylib 0x00007fff20654d7d _sigtramp + 29
8 ??? 0x00000001405e6d18 0 + 5374897432
9 com.acme.${PRODUCT_NAME:rfc1034identifier} 0x000000012dac04fe maxjava_assist + 222
10 com.cycling74.Max 0x0000000109aff67c assist_getstring + 476
11 com.cycling74.Max 0x000000010986fa29 BoxComponent::paintFrame(t_jgraphics*, _jboxdrawparams*) + 1513
12 com.cycling74.Max 0x000000010986eda8 BoxComponent::paintOverChildren(juce::Graphics&, juce::AffineTransform const&) + 1784
When subclassing MaxObject and using the NO_INLETS helper definition, this can cause a hard crash in max , in my specific case this caused a crash when entering patching mode from presentation mode
in the constructor for a MaxObject subclass we can use the helper function like this to describe an object with no inlets:
public MyMaxObjectSubClass () {
super();
declareInlets(NO_INLETS);
}
When switching to patching mode it seems that the method getInletAssist(int inletIdx) in MaxObject is called from native code without checking first if there are no inlets and thus throws an index out of bounds error in the java system and bringing down the Max process.
This is evident in OSX but not reproduced in Windows as of the writing of this issue
A work around is to declare at least one inlet even if it is not used.
The native crash report (OSX) can look like this as an indication, and this is also an indicator of where the getInletAssist is being called from the native code.
Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff205e2462 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff20610610 pthread_kill + 263
2 libsystem_c.dylib 0x00007fff20563720 abort + 120
3 libjvm.dylib 0x000000012df89aa1 os::abort(bool) + 25
4 libjvm.dylib 0x000000012e0b1e9e VMError::report_and_die() + 2306
5 libjvm.dylib 0x000000012df8b6e6 JVM_handle_bsd_signal + 1131
6 libjvm.dylib 0x000000012df8792b signalHandler(int, __siginfo*, void*) + 47
7 libsystem_platform.dylib 0x00007fff20654d7d _sigtramp + 29
8 ??? 0x00000001405e6d18 0 + 5374897432
9 com.acme.${PRODUCT_NAME:rfc1034identifier} 0x000000012dac04fe maxjava_assist + 222
10 com.cycling74.Max 0x0000000109aff67c assist_getstring + 476
11 com.cycling74.Max 0x000000010986fa29 BoxComponent::paintFrame(t_jgraphics*, _jboxdrawparams*) + 1513
12 com.cycling74.Max 0x000000010986eda8 BoxComponent::paintOverChildren(juce::Graphics&, juce::AffineTransform const&) + 1784