help with Crash Log

mattgolsen's picture

I've got a composition that is randomly crashing, but I have no idea how to troubleshoot the crash log.

I'll attach the log, but can someone give me any sort of explanation for reading these files?

QCFullscreen_2009-03-20-201501_Display-1.crash29.57 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cwright's picture
Re: help with Crash Log

crash log wrote:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000080
Crashed Thread:  3

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.

crash log, thread 3's backtrace wrote:

Thread 3 Crashed:
0         0x911649c4 KJS::Collector::collect() + 244
1         0x91126055 void* KJS::Collector::heapAllocate<(KJS::Collector::HeapType)0>(unsigned long) + 485
2         0x9112b5ae KJS::jsString(KJS::UString const&) + 46
3         0x91158c5e KJS::stringProtoFuncSplit(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 1726
4         0x91148db6 KJS::FunctionCallDotNode::evaluate(KJS::ExecState*) + 806
5         0x91147f19 KJS::AssignLocalVarNode::evaluate(KJS::ExecState*) + 25

We glean 2 things from this: First, it's happening in Javascript execution (, 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.

mattgolsen's picture
Re: help with Crash Log

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.

cwright's picture
Re: help with Crash Log

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