Thanks Chris,
I'll start by recompiling it. The machine is rebooted every night and
only runs this one app so maybe that will be enough to resolve the
trouble.
Thank you for such a thorough email..
rob
On Jul 20, 2010, at 1:42 PM, Christopher Wright wrote:
So.. does this crash log explain to anyone what's happening?
A little bit:
Process: QCFullscreen [104]
Path:
/Users/ncm/Desktop/borderbeast/QCFullscreen/build/Debug/
QCFullscreen.app/Contents/MacOS/QCFullscreen
Identifier: com.yourcompany.QCFullscreen
Version: ??? (1.0)
Code Type: X86 (Native)
First, this is in 32bit mode. Not bad, just "dated" since you're on
Snow Leopard.
Parent Process: launchd [79]
Date/Time: 2010-07-19 11:20:05.356 -0700
OS Version: Mac OS X 10.6.4 (10F569)
^^ This says you're on Snow Leopard
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
KERN_PROTECTION_FAILURE provides the memory address the program was
trying to access. In this case, 0x0000000 (zero). In other words,
a NULL pointer dereference. Null pointer dereferences typically
happen when someone doesn't set a pointer they ought to, or when the
program runs out of memory (at which point malloc() will return NULL
pointers).
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.apple.GeForceGLDriver 0x8f0629f3 gldAttachDrawable +
2579
1 com.apple.GeForceGLDriver 0x8f124615 gldUpdateDispatch +
15381
2 com.apple.GeForceGLDriver 0x8f12470e gldUpdateDispatch +
15630
3 GLEngine 0x0051ff2a glFlush_Exec + 141
This says it crashed deep in the GPU driver (a GeForce, so Nvidia)
-- glFlush() takes no arguments, so it's impossible for the caller
(discussed next) to have provided a bad pointer. Thus, it's likely
the process ran out of memory while the GPU driver was trying to
allocate a temporary buffer or something, got a NULL, and then
crashed when it tried to use it.
4 ...ickTimeComponents.component 0x93eb884c
PixelBufferVC_CopyImageForTime + 1458
5 ...ple.CoreServices.CarbonCore 0x967a5683
callComponentStorage_4444 + 42
6 ...ple.CoreServices.CarbonCore 0x9679a56c
CallComponentFunctionCommonWithStorage(char**,
ComponentParameters*, long
(*)(), unsigned long) + 54
7 ...ickTimeComponents.component 0x93eb7164
PixelBufferVC_ComponentDispatch + 161
8 ...ple.CoreServices.CarbonCore 0x96792ce5
CallComponentDispatch + 29
9 com.apple.QuickTime 0x9565487a QTVCCopyImageForTime
+ 55
10 com.apple.QuickTime 0x956547dc
QTVisualContextCopyImageForTime + 87
11 ...QuartzComposer.ExtraPatches 0x12b56677 0x12b40000 + 91767
Here's the caller to glFlush() -- looks like quicktime stuff.
12 com.apple.QuartzComposer 0x96d81f32 -[QCPatch(Private)
_renderAtTime:arguments:] + 111
... And in turn, that was driven by a QC patch -- probably the movie
loader.
So there you have it: a memory leak somewhere slowly consumed all
your memory, and the program died -- it could have happened
anywhere, and this time it just happened to be in the GPU driver.
The "optimal" fix is to not have the program leak (that's my job and
problem, not yours), but a cheap workaround would be to compile the
app in 64bit mode -- that will give you ~4billion times as much
address space before allocations will fail (but in the mean time, it
will chew up disk space much more quickly as it's leaking -- 32bit
apps are limited to ~4GB before they die, while 64bit apps aren't
practically limited -- your machine will probably turn into a
doorstop before an allocation will fail).
--
Christopher Wright
christopher_wri...@apple.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
