Forums > MaxMSP

Is there some Java "behind the scenes" in the Max program itself ?

March 17, 2013 | 10:37 am


I got Max crashing today and looking at the crashlog I read that it was linked to Java stuff. This sounds strange to me because I got rid of every possible Java external I have been using. So where does this Java come from ? Is JUCE using Java in any way ? I hope it doesn’t.

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread:  0  Java: AWT-AppKit  Dispatch queue:

Application Specific Information:

Java information:
 Exception type: Bus Error (0xa) at pc=00000000ffff1090

 Java VM: Java HotSpot(TM) Client VM (20.12-b01-434 mixed mode macosx-x86)

Current thread (000000003c801c00):  JavaThread "AWT-AppKit" [_thread_in_native, id=-1604528832, stack(00000000bf800000,00000000c0000000)]
Stack: [00000000bf800000,00000000c0000000]

Java Threads: ( => current thread )
  000000003fa16000 JavaThread "AWT-Shutdown" [_thread_blocked, id=-1309048832, stack(00000000b1e98000,00000000b1f98000)]
  000000003f9d6800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=-1311162368, stack(00000000b1c94000,00000000b1d94000)]
  0000000055801000 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=-1312219136, stack(00000000b1b92000,00000000b1c92000)]
  0000000055800000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=-1313275904, stack(00000000b1a90000,00000000b1b90000)]
  0000000055004400 JavaThread "Surrogate Locker Thread (Concurrent GC)" daemon [_thread_blocked, id=-1314332672, stack(00000000b198e000,00000000b1a8e000)]
  000000003f9ce800 JavaThread "Finalizer" daemon [_thread_blocked, id=-1315389440, stack(00000000b188c000,00000000b198c000)]
  000000003f9cd800 JavaThread "Reference Handler" daemon [_thread_blocked, id=-1316446208, stack(00000000b178a000,00000000b188a000)]
=>000000003c801c00 JavaThread "AWT-AppKit" [_thread_in_native, id=-1604528832, stack(00000000bf800000,00000000c0000000)]
Other Threads:
  000000003f9cac00 VMThread [stack: 00000000b1688000,00000000b1788000] [id=-1317502976]
  000000003f9e0000 WatcherThread [stack: 00000000b1d96000,00000000b1e96000] [id=-1310105600]

VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None

 par new generation   total 14784K, used 2394K [0000000040000000, 0000000041000000, 0000000042000000)
  eden space 13184K,  18% used [0000000040000000, 0000000040256930, 0000000040ce0000)
  from space 1600K,   0% used [0000000040ce0000, 0000000040ce0000, 0000000040e70000)
  to   space 1600K,   0% used [0000000040e70000, 0000000040e70000, 0000000041000000)
 concurrent mark-sweep generation total 49152K, used 0K [0000000042000000, 0000000045000000, 0000000050000000)
 concurrent-mark-sweep perm gen total 12288K, used 4278K [0000000050000000, 0000000050c00000, 0000000054000000)

Code Cache  [000000003d001000, 000000003d08a000, 000000003f001000)
 total_blobs=183 nmethods=49 adapters=78 free_code_cache=33000576 largest_free_block=0

Virtual Machine Arguments:
JVM Args: -Xincgc -Xms64m -Xmx256m
Java Command: 
Launcher Type: generic
Physical Memory: Page Size = 4k, Total = 8192M, Free = 17592186042580M

Thread 0 Crashed:  Java: AWT-AppKit  Dispatch queue:
0   libSystem.B.dylib             	0xffff1090 __memset_pattern + 144
1   com.cycling74.Max             	0x003c1f75 void juce::SoftwareRendererClasses::ClipRegionBase::renderSolidFill(juce::SoftwareRendererClasses::ClipRegion_RectangleList::SubRectangleIterator&, juce::Image::BitmapData const&, juce::PixelARGB const&, bool, juce::PixelRGB*) + 186
2   com.cycling74.Max             	0x003ba9e8 juce::SoftwareRendererClasses::ClipRegion_RectangleList::fillRectWithColour(juce::Image::BitmapData&, juce::Rectangle const&, juce::PixelARGB const&, bool) const + 138
3   com.cycling74.Max             	0x003c35c8 juce::LowLevelGraphicsSoftwareRenderer::SavedState::fillRect(juce::Rectangle const&, bool) + 196
4   com.cycling74.Max             	0x003a1ee1 juce::LowLevelGraphicsSoftwareRenderer::fillRect(juce::Rectangle const&, bool) + 35
5   com.cycling74.Max             	0x003a10b5 juce::Graphics::fillAll(juce::Colour const&) const + 127
6   com.cycling74.Max             	0x00198fb1 MaxTopLevelWindow::paint(juce::Graphics&) + 155
7   com.cycling74.Max             	0x0032eaf6 juce::Component::paintComponent(juce::Graphics&) + 348
8   com.cycling74.Max             	0x0032ebbe juce::Component::paintComponentAndChildren(juce::Graphics&) + 140
9   com.cycling74.Max             	0x0032ef2a juce::Component::paintEntireComponent(juce::Graphics&, bool) + 312
10  com.cycling74.Max             	0x003960e6 juce::ComponentPeer::handlePaint(juce::LowLevelGraphicsContext&) + 92
11  com.cycling74.Max             	0x00435610 juce::NSViewComponentPeer::drawRect(_NSRect) + 1190
12  com.cycling74.Max             	0x0042b99d -[JuceNSView_1_52_105_3 drawRect:] + 51
13              	0x99d6d61e -[NSView _drawRect:clip:] + 3510
14              	0x99d6c2bc -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1600
15              	0x99d6c5f1 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2421
16              	0x99d6a7db -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 711
17              	0x99d6a34f -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 265
18              	0x99d66c96 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 3309
19              	0x99cc784b -[NSView displayIfNeeded] + 818
20              	0x99c90b64 -[NSWindow displayIfNeeded] + 204
21              	0x99cc207e _handleWindowNeedsDisplay + 696
22      	0x980f5dd2 __CFRunLoopDoObservers + 1186
23      	0x980b1ced __CFRunLoopRun + 557
24      	0x980b13c4 CFRunLoopRunSpecific + 452
25      	0x980b11f1 CFRunLoopRunInMode + 97
26           	0x9008ad60 RunCurrentEventLoopInMode + 392
27           	0x9008aa53 ReceiveNextEventCommon + 158
28           	0x9008a99c BlockUntilNextEventMatchingListInMode + 81
29              	0x99c98595 _DPSNextEvent + 847
30              	0x99c97dd6 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
31              	0x99c5a1f3 -[NSApplication run] + 821
32  com.cycling74.Max             	0x0043270f juce::MessageManager::runDispatchLoop() + 731
33  com.cycling74.Max             	0x002c1f02 juce::JUCEApplication::main(juce::StringArray const&) + 68
34  com.cycling74.Max             	0x002c2025 juce::JUCEApplication::main(int, char const**) + 73
35  com.cycling74.Max             	0x0000db8b _start + 209
36  com.cycling74.Max             	0x0000dab9 start + 41

March 17, 2013 | 7:53 pm

Hello Nicolas, thank you for the insight.

In between I have discovered that it was my mistake: there was a shy, innocent-looking, tiny mxj bufOp object left in a subpatcher. It wasn’t used at all. But alone it made the CPU going from 29% to more than 50% and probably caused crashes for months. So it got wiped out, disintegrated, nuked. How could such a crap make its way into Max ?

Bonne soirée.

March 17, 2013 | 8:24 pm

…not so easy !!!!! I still got crashes related to Java. Grmbl.

I am using the 2C Aether VST reverb plug-in. Is it possible that it includes some Java code ?

March 17, 2013 | 8:53 pm

Using sampling in the activity monitor I discovered the Maxlua framework was appearing just before some Java stuff. I read this topic therefore I was not afraid to remove the Maxlua framework from the application package. Now Max seems to be really clean from Java.

March 20, 2013 | 8:50 am

Removing the MaxLua framework made the use of gen~ impossible. Therefore I went back to the normal Max version.

However I’d be happy to have an official C74 comment about absence/presence of Java stuff in Max when no mxj objet is open.

March 20, 2013 | 4:26 pm

Hi Roald,

MaxLua has zero Java dependencies. Max in general will not instantiate a JavaVM unless an instance of mxj or mxj~has been loaded. Jitter links to the Java frameworks, but will not create a JVM and will not launch any Java threads.

So the only possibilities I can imagine from what you are describing is that there is still some mxj object being used by your patches, or there is some other third party external or system extension or something else on your machine which is causing you these issues.

I would suggest a fresh install of Max with nothing additional in the search path, and then bit by bit test out your patches to see what the culprit may be. You can easily remove mxj and mxj~ from your search path to get rid of any Java loading, which also might give you a clue as to errors in the max window when something is trying to load mxj.

Note that once a single mxj object is loaded, java will be running until you quit Max.

Otherwise, I’d suggest you follow up with support.


March 20, 2013 | 4:31 pm

Hi Joshua,

Thanks, this is crystal clear. I had removed mxj from my search patch yet but did not even remember there was mxj~(I have almost never used it).

March 20, 2013 | 4:33 pm

Oh and by the way, your crashlog above simply suggests something has corrupted memory in the main thread (while trying to paint the background of a max patcher). It’s really doubtful that Java is the culprit here, unless you’re running out of memory (Java has a serious memory footprint, something like 400MB or so).

The fact that there is Java information here doesn’t mean that the crash is related to Java. Apple’s crash log system simply tries to also provide Java relevant information if Java has been loaded. The main thread isn’t a Java initiated thread, it is simply the thread on which the Java AWT has been run or associated. So it really seems to be a red herring here.

However if you don’t have any need to use Java in your patches, you might as well avoid using mxj and incurring the memory cost :)

March 20, 2013 | 4:50 pm

Interesting. What kind of event/data coud cause corruption in the memory ?

March 21, 2013 | 3:56 pm

Anything which touches memory. That’s why we ask for so much information and examples in crash reports.

Viewing 10 posts - 1 through 10 (of 10 total)