reading a crash report

sinsynplus's picture


i've got a question concerning crash reports.. is it possible to see what patches or plugins are causing the problem? i've got a composition which runs for about an hour and then freezes.. according to activity monitor it takes about 170mb of ram.. same thing happens with the application compiled by quartz builder..

i attached the crash report..

hope somebody can give me a hint..



Quartz Composer_2013-01-04-200531_mbook03.txt287.53 KB

Comment viewing options

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

smokris's picture
Re: reading a crash report

What you attached is a "spindump", not a crash report. This indicates that Quartz Composer didn't technically "crash", it just stopped responding to user interface events.

Line 17 shows that this spindump includes 23 samples — the system snapshotted what QC was doing 23 times over the course of 2.3 seconds.

Starting on line 30 is the "user stack" — this shows the series of function/method calls that the app was doing when you generated the spindump.

  • The first 15 lines are generic Mac app stuff and aren't interesting to us.
  • The next 66 lines are generic Quartz Composer stuff and aren't interesting to us.
  • The next line says 23 ??? (in VideoTools) [0x9e202f0] — so, for all 23 samples, we're in the VideoTools plugin.
  • The next few lines indicate that VideoTools is using libdispatch (aka Grand Central Dispatch) to do some parallel processing; 22 of the 23 samples were spent in waiting for a semaphore — that's suspicious.

It's not clear whether this indicates VideoTools was deadlocked, or was just waiting on the system to give it more data, or whether your machine was slowing down because it was swapping memory (possibly due to a memory leak).

Can you either attach or email your composition and data files, so we can try to reproduce this to see if it's a problem with VideoTools?

cwright's picture
Re: reading a crash report

What's the condition of the machine at the time of the hang? In Activity Monitor, is there any appreciable CPU usage? Is there a significant amount of swap? Network or disk IO?

as smokris noted, it looks like a deadlock, but there are enough other things going on that it could just be a bogged down system (something is still process video and network stuff, from some of the other thread stacks).