Is there some Java "behind the scenes" in the Max program itself ?
Hello,
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: com.apple.main-thread
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
Heap
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: com.apple.main-thread
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 com.apple.AppKit 0x99d6d61e -[NSView _drawRect:clip:] + 3510
14 com.apple.AppKit 0x99d6c2bc -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1600
15 com.apple.AppKit 0x99d6c5f1 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2421
16 com.apple.AppKit 0x99d6a7db -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 711
17 com.apple.AppKit 0x99d6a34f -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 265
18 com.apple.AppKit 0x99d66c96 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 3309
19 com.apple.AppKit 0x99cc784b -[NSView displayIfNeeded] + 818
20 com.apple.AppKit 0x99c90b64 -[NSWindow displayIfNeeded] + 204
21 com.apple.AppKit 0x99cc207e _handleWindowNeedsDisplay + 696
22 com.apple.CoreFoundation 0x980f5dd2 __CFRunLoopDoObservers + 1186
23 com.apple.CoreFoundation 0x980b1ced __CFRunLoopRun + 557
24 com.apple.CoreFoundation 0x980b13c4 CFRunLoopRunSpecific + 452
25 com.apple.CoreFoundation 0x980b11f1 CFRunLoopRunInMode + 97
26 com.apple.HIToolbox 0x9008ad60 RunCurrentEventLoopInMode + 392
27 com.apple.HIToolbox 0x9008aa53 ReceiveNextEventCommon + 158
28 com.apple.HIToolbox 0x9008a99c BlockUntilNextEventMatchingListInMode + 81
29 com.apple.AppKit 0x99c98595 _DPSNextEvent + 847
30 com.apple.AppKit 0x99c97dd6 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
31 com.apple.AppKit 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 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.
…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 ?
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.
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.
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.
-Joshua
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).
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 :)
Interesting. What kind of event/data coud cause corruption in the memory ?
Anything which touches memory. That’s why we ask for so much information and examples in crash reports.