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

Mar 17, 2013 at 10:37am

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
#67135
Mar 17, 2013 at 6:18pm

Hi,

?

http://cycling74.com/forums/topic.php?id=25897

EDIT : I have no idea what is AWT-AppKit but it comes often in crash reports :

http://cycling74.com/search-results/?q=AWT-AppKit !

#241566
Mar 17, 2013 at 7:53pm

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.

#241567
Mar 17, 2013 at 8:24pm

…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 ?

#241568
Mar 17, 2013 at 8:53pm

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.

#241569
Mar 20, 2013 at 8:50am

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.

#241570
Mar 20, 2013 at 4:26pm

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

#241571
Mar 20, 2013 at 4:31pm

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).

#241572
Mar 20, 2013 at 4:33pm

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 :)

#241573
Mar 20, 2013 at 4:50pm

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

#241574
Mar 21, 2013 at 3:56pm

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

#241575

You must be logged in to reply to this topic.