> 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
