Exception Type: what went wrong. In this case, EXC_BAD_ACCESS (SIGBUS, or SIGSEGV) means it's accessing an invalid address. SIGBUS happens for ZEROPAGE stuff, SIGSEGV for non-ZEROPAGE faults (I think?)
Exception Codes: has the address above: in this case, 0x80 -- that's inside the ZEROPAGE (in 32bit mode, ZEROPAGE is 4k, or anything less than 0x1000 -- in 64bit, it's 4GB, or anything less than 0x100000000). ZEROPAGE violations typically mean you're dereferencing a NULL/nil pointer (0x0), or an offset into a NULL pointer (like in this case, 0x80 bytes after 0).
Crashed Thread: has the thread (and thus the most likely interesting backtrace.
We glean 2 things from this: First, it's happening in Javascript execution (com.apple.JavaScriptCore), and that it's happening around memory allocation stuff (words like "heapAllocate", "collect", etc indicate memory allocation/management).
Putting it all together:
The program crashes because an allocation returns 0x0 (NULL) instead of a real address. Program then doesn't check to see if the allocation failed, and instead tries to use it, and subsequently crashes.
Why would allocate return 0x0 instead of a real address? This only happens when the process is Out Of Memory (OOM) (a 32bit app has exhausted all 2GB of addressable space allocated to it, or a 64bit app has exhausted all zillion petabytes of addressable space to it -- 64bit apps will usually OOM on ulimit limits before they actually exhaust all memory).
Why would the program run out of memory? Either there's a leaky patch (usually custom patches, sometimes built-in ones), or something isn't releasing memory it's allocating (this happens often with javascript, since the QC devs don't run the JS garbage collector frequently enough to reclaim memory in use).
How to fix this: see if it's javascript -- if so, try implementing things differently. If it's not JS, try isolating which patch or patches contribute to the leak, and then file a bug report with the appropriate party.
This is interesting because I have the exact same composition running on another machine, with slightly more processor usage, but it doesn't seem to have the same crashing problem.
The javascript is actually the timing patch that I posted about a few months ago, using System Time to drive the JS patch to switch between two compositions depending on the time.
Out Of Memory crashes are usually very hard to really diagnose -- everything allocates memory, so everything can crash from OOM, but that doesn't necessarily mean it's the problem. The leak can be anywhere (CoreImage, JS, GL driver stuff, etc).
does it always crash in JS? does disabling any particular piece make the crashing go away?
The timing script (not completely fresh in my mind, but I recall the idea) wasn't doing anything particularly unusual, so I'm not too suspicious of it (if you pass images through JS then leaks can pile up, but otherwise it's fairly robust as far as I recall).
Exception Type: what went wrong. In this case, EXC_BAD_ACCESS (SIGBUS, or SIGSEGV) means it's accessing an invalid address. SIGBUS happens for ZEROPAGE stuff, SIGSEGV for non-ZEROPAGE faults (I think?)
Exception Codes: has the address above: in this case, 0x80 -- that's inside the ZEROPAGE (in 32bit mode, ZEROPAGE is 4k, or anything less than 0x1000 -- in 64bit, it's 4GB, or anything less than 0x100000000). ZEROPAGE violations typically mean you're dereferencing a NULL/nil pointer (0x0), or an offset into a NULL pointer (like in this case, 0x80 bytes after 0).
Crashed Thread: has the thread (and thus the most likely interesting backtrace.
We glean 2 things from this: First, it's happening in Javascript execution (com.apple.JavaScriptCore), and that it's happening around memory allocation stuff (words like "heapAllocate", "collect", etc indicate memory allocation/management).
Putting it all together:
The program crashes because an allocation returns 0x0 (NULL) instead of a real address. Program then doesn't check to see if the allocation failed, and instead tries to use it, and subsequently crashes.
Why would allocate return 0x0 instead of a real address? This only happens when the process is Out Of Memory (OOM) (a 32bit app has exhausted all 2GB of addressable space allocated to it, or a 64bit app has exhausted all zillion petabytes of addressable space to it -- 64bit apps will usually OOM on ulimit limits before they actually exhaust all memory).
Why would the program run out of memory? Either there's a leaky patch (usually custom patches, sometimes built-in ones), or something isn't releasing memory it's allocating (this happens often with javascript, since the QC devs don't run the JS garbage collector frequently enough to reclaim memory in use).
How to fix this: see if it's javascript -- if so, try implementing things differently. If it's not JS, try isolating which patch or patches contribute to the leak, and then file a bug report with the appropriate party.
This is interesting because I have the exact same composition running on another machine, with slightly more processor usage, but it doesn't seem to have the same crashing problem.
The javascript is actually the timing patch that I posted about a few months ago, using System Time to drive the JS patch to switch between two compositions depending on the time.
Out Of Memory crashes are usually very hard to really diagnose -- everything allocates memory, so everything can crash from OOM, but that doesn't necessarily mean it's the problem. The leak can be anywhere (CoreImage, JS, GL driver stuff, etc).
does it always crash in JS? does disabling any particular piece make the crashing go away?
The timing script (not completely fresh in my mind, but I recall the idea) wasn't doing anything particularly unusual, so I'm not too suspicious of it (if you pass images through JS then leaks can pile up, but otherwise it's fairly robust as far as I recall).