Forums > Java

[bug] MXJ crash

Oct 28 2009 | 11:26 pm

(I have no idea if this is the correct forum for reporting bugs, but I’m happy to hear what that forum is).

I’m developing a set of MXJ objects to allow intercommunication between Max and Field (a code-writing environment for digital art). I have a MXJ loaded class that was working well in 5.0.7 and now repeatedly and instantaneously crashes Max upon creation. Of course, as a software developer repeatable, instant crashes are the best kind…

Steps to reproduce:

Download Field (just to get the classes, you don’t actually have to run it) from here:

Stick the .app in /Applications

Add this to

max.dynamic.class.dir /Applications/
max.dynamic.jar.dir /Applications/
max.jvm.option -Dpython.path=/Applications/
max.jvm.option -Dmaxfield.boot=/Applications/

Open Max, and attempt to create a "mxj field.extras.max.MaxFieldRoot" box.

Watch Max fall over here:

Thread 0 Crashed: Java: AWT-AppKit Dispatch queue:
0 com.cycling74.MaxMSP 0x0002a79b memoryheap_getbytes(_memoryheap*, short) + 115
1 com.cycling74.MaxMSP 0x0002a8fd getbytes + 63
2 com.cycling74.MaxMSP 0x00028c47 sysmem_resizeptr + 33
3 com.cycling74.MaxMSP 0x000ad89d class_addmethod + 235
4 com.cycling74.MaxAPI 0x036cd238 class_addmethod + 163
5 com.cycling74.JitterAPI 0x320278ac jit_class_new + 289
6 com.cycling74.jit.openexr 0x326a87c7 jit_openexr_init + 73
7 com.cycling74.jit.openexr 0x326acb0e main + 20
8 com.cycling74.MaxMSP 0x0000d1eb external_bundleload(char*, char*, char*, short) + 687
9 com.cycling74.MaxMSP 0x0000d34a external_load + 180
10 com.cycling74.MaxMSP 0x000abda8 class_load(symbol*) + 200
11 com.cycling74.MaxMSP 0x0000e60b newload_internal + 127
12 com.cycling74.MaxMSP 0x0000e926 newload + 40
13 com.cycling74.MaxMSP 0x00018f2d typedmess_fun + 1973
14 com.cycling74.MaxMSP 0x00018fb7 typedmess + 83
15 com.cycling74.MaxMSP 0x00028331 newinstance + 41

(full backtrace / crashreport attached, but the backtrace does vary).

This works under 5.0.7 and doesn’t under 5.0.8 (I can swap back and forth between these version to confirm it).

We are putting quite a bit of stuff on the classpath (a complete Jython implementation for example), but other than that we’re definitely not doing anything JNI’ish or otherwise out of the ordinary.

Field is open source, and I’d be happy to direct you to the relevant part of our source tree if you need to see what we’re doing. In the meantime, I’m going to have to recommend that my user-base sticks with 5.0.7.

Viewing 1 post (of 1 total)

Forums > Java