Java related crash
powerbook pro, OS 10.6.5, m/m/j 5.1.7
I am suddenly having regular crashes with a relatively big patch – report below. Happens when closing the patch and during use. I am nor using mxj. I notice an earlier thread that had a java crash related to a pattr object registered with two pattrstorage objects, but I am using autopattr rather than pattr: http://cycling74.com/forums/topic.php?id=26368
Does anyone have a specific knowledge here? Otherwise I will look for any pattr related issues and report back.
Lars
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000fffff3d8
Crashed Thread: 0 Java: AWT-AppKit Dispatch queue: com.apple.main-thread
Application Specific Information:
Java information:
Exception type: Bus Error (0xa) at pc=0000000016d01a89
Java VM: Java HotSpot(TM) Client VM (17.1-b03-307 mixed mode macosx-x86)
Current thread (0000000034801400): JavaThread "AWT-AppKit" [_thread_in_native, id=-1608661696, stack(00000000bf800000,00000000c0000000)]
Stack: [00000000bf800000,00000000c0000000]
Java Threads: ( => current thread )
000000004c0a6400 JavaThread "Thread-6" [_thread_in_native, id=-1317711872, stack(00000000b1655000,00000000b1755000)]
000000004c0a3400 JavaThread "AWT-Shutdown" [_thread_blocked, id=-1331822592, stack(00000000b08e0000,00000000b09e0000)]
00000000348b7000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=-1319825408, stack(00000000b1451000,00000000b1551000)]
00000000348b6000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=-1320882176, stack(00000000b134f000,00000000b144f000)]
00000000348b5000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=-1321938944, stack(00000000b124d000,00000000b134d000)]
00000000348b4000 JavaThread "Surrogate Locker Thread (CMS)" daemon [_thread_blocked, id=-1322995712, stack(00000000b114b000,00000000b124b000)]
000000004c008800 JavaThread "Finalizer" daemon [_thread_blocked, id=-1325268992, stack(00000000b0f20000,00000000b1020000)]
000000004c007800 JavaThread "Reference Handler" daemon [_thread_blocked, id=-1326325760, stack(00000000b0e1e000,00000000b0f1e000)]
=>0000000034801400 JavaThread "AWT-AppKit" [_thread_in_native, id=-1608661696, stack(00000000bf800000,00000000c0000000)]
Other Threads:
000000004c006000 VMThread [stack: 00000000b0d1c000,00000000b0e1c000] [id=-1327382528]
00000000348c0400 WatcherThread [stack: 00000000b1553000,00000000b1653000] [id=-1318768640]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
par new generation total 14784K, used 4072K [0000000037010000, 0000000038010000, 0000000039010000)
eden space 13184K, 30% used [0000000037010000, 000000003740a3d8, 0000000037cf0000)
from space 1600K, 0% used [0000000037cf0000, 0000000037cf0000, 0000000037e80000)
to space 1600K, 0% used [0000000037e80000, 0000000037e80000, 0000000038010000)
concurrent mark-sweep generation total 49152K, used 0K [0000000039010000, 000000003c010000, 0000000047010000)
concurrent-mark-sweep perm gen total 12288K, used 4302K [0000000047010000, 0000000047c10000, 000000004b010000)
Virtual Machine Arguments:
JVM Args: -Xincgc -Xms64m -Xmx256m
Java Command:
Launcher Type: generic
Physical Memory: Page Size = 4k, Total = 3840M, Free = 1782M
Thread 0 Crashed: Java: AWT-AppKit Dispatch queue: com.apple.main-thread
0 com.cycling74.sqlite 0x16d01a89 pcache1Fetch + 673
1 com.cycling74.sqlite 0x16cdad63 sqlite3PcacheFetch + 156
2 com.cycling74.sqlite 0x16cef559 sqlite3PagerAcquire + 1200
3 com.cycling74.sqlite 0x16cef783 sqlite3BtreeGetPage + 36
4 com.cycling74.sqlite 0x16cf342a checkTreePage + 166
5 com.cycling74.sqlite 0x16cf36a1 checkTreePage + 797
6 com.cycling74.sqlite 0x16cf36a1 checkTreePage + 797
7 com.cycling74.sqlite 0x16d2ffa9 sqlite3Step + 25375
8 com.cycling74.sqlite 0x16d31e30 sqlite3_step + 87
9 com.cycling74.sqlite 0x16d20d6c sqlite3_exec + 235
10 com.cycling74.sqlite 0x16cd79ae maxsqlite_db_execstring + 95
11 com.cycling74.sqlite 0x16cd67b5 maxsqlite_create_backup + 76
12 com.cycling74.MaxMSP 0x000bb49b object_method + 901
13 com.cycling74.MaxMSP 0x000d62ce pathcache_free + 206
14 com.cycling74.MaxMSP 0x00012d4c max_shutdown + 16
15 com.cycling74.MaxMSP 0x002db002 juce::JUCEApplication::shutdownAppAndClearUp(bool) + 60
16 com.cycling74.MaxMSP 0x002db2ee juce::JUCEApplication::main(juce::String&, juce::JUCEApplication*) + 690
17 com.cycling74.MaxMSP 0x002db373 juce::JUCEApplication::main(int, char**, juce::JUCEApplication*) + 125
18 com.cycling74.MaxMSP 0x001e4b00 main + 76
19 com.cycling74.MaxMSP 0x0000647a _start + 216
20 com.cycling74.MaxMSP 0x000063a1 start + 41
…no-one has ahd trouble with java in max?
I just upgraded to the current version and got the same error. I’m kind of concerned. I actually googled "AWT-AppKit crash" and this came up.
The first google result says that it’s arising from java being in thread zero. I did, somewhere in my code, go to high priority but I didn’t think I was doing anything special.
I think I was reading from a bufferedimage in high priority.
I tracked my crashes down to a handful of pattrfied flonums and a preset object in a bpatcher file, but I wasn’t able to identify what exactly was causing the crashes. At least I could isolate the problem, but it still has me worrying.
A) Is the crash report still the same?
B) Are you sure it’s the flonums and not whatever function they set off when they are changed? (perhaps an MXJ something or other?)
I actually just got the same crash again… Hrm?!?!?!
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000e0000390
Crashed Thread: 0 Java: AWT-AppKit Dispatch queue: com.apple.main-thread
Application Specific Information:
Java information:
Exception type: Bus Error (0xa) at pc=000000001a21e126
Java VM: Java HotSpot(TM) Client VM (17.1-b03-307 mixed mode macosx-x86)
Current thread (000000001c800000): JavaThread "AWT-AppKit" [_thread_in_native, id=-1606339264, stack(00000000bf800000,00000000c0000000)]
Stack: [00000000bf800000,00000000c0000000]
Java Threads: ( => current thread )
000000001c92c400 JavaThread "Thread-2" [_thread_in_native, id=-1340583936, stack(00000000b0105000,00000000b0185000)]
000000001c8e6800 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=-1316294656, stack(00000000b17af000,00000000b18af000)]
000000001c8bf400 JavaThread "OSCReceiver" daemon [_thread_in_native, id=-1317351424, stack(00000000b16ad000,00000000b17ad000)]
000000001c8cb400 JavaThread "AWT-Shutdown" [_thread_blocked, id=-1318408192, stack(00000000b15ab000,00000000b16ab000)]
000000001c021800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=-1320816640, stack(00000000b135f000,00000000b145f000)]
000000001c018000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=-1323880448, stack(00000000b1073000,00000000b1173000)]
000000001c017000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=-1324937216, stack(00000000b0f71000,00000000b1071000)]
000000001c016000 JavaThread "Surrogate Locker Thread (CMS)" daemon [_thread_blocked, id=-1326395392, stack(00000000b0e0d000,00000000b0f0d000)]
000000001c8a7c00 JavaThread "Finalizer" daemon [_thread_blocked, id=-1328291840, stack(00000000b0c3e000,00000000b0d3e000)]
000000001c009400 JavaThread "Reference Handler" daemon [_thread_blocked, id=-1329348608, stack(00000000b0b3c000,00000000b0c3c000)]
=>000000001c800000 JavaThread "AWT-AppKit" [_thread_in_native, id=-1606339264, stack(00000000bf800000,00000000c0000000)]
Other Threads:
000000001c007800 VMThread [stack: 00000000b093c000,00000000b0a3c000] [id=-1331445760]
000000001c022800 WatcherThread [stack: 00000000b1461000,00000000b1561000] [id=-1319759872]A) Is the crash report still the same?
B) Are you sure it's the flonums and not whatever function they set off when they are changed? (perhaps an MXJ something or other?A) yes, and B) flonums were disconnected the function parameters. There is no [mxj] in the entire patch.
I contained the crashes by erasing a [preset] connected to the flonums in the abstraction. I used this for making global presets, while having control locally through pattr. I’m using this techniques in several places w. no issues. I guess the problem comes down to the corrupted abstraction file – there’s a related discussion here: http://cycling74.com/forums/topic.php?id=30241&replies=13#post-153584 along with random object connections produced at loadtime.