IKImageBrowser crash
IKImageBrowser crash
- Subject: IKImageBrowser crash
- From: Graham Cox <email@hidden>
- Date: Mon, 28 May 2012 10:55:19 +1000
Hi all, I'm trying to track down a very bad hard crash when using IKImageBrowserView.
I'm using this pretty much in its standard form - I don't subclass anything, I just have a window with an IKImageBrowserView in it, and supply it through its normal dataSource and delegate protocols.
Previously, the image data type passed back was IKImageBrowserPathRepresentationType, but as we're adding SVG support to the app, we changed this for IKImageBrowserQuickLookPathRepresentationType which uses QuickLook to preview SVG files (as well as all the usual image types). This appears to work fine with no loss of functionality over the previous image type, and of course adds SVG.
// view's datasource:
- (NSString*) imageRepresentationType
{
return IKImageBrowserQuickLookPathRepresentationType;
}
At some point we started to encounter a repeatable crash with a folder full of SVG files. On the assumption it was one particular file, we've been trying to identify which file it was, but could not. After some time we started to realise it wasn't a particular file but the number of files we were trying to preview - it seems as though once some number is exceeded (still trying to narrow down at what point that occurs), IKImageBrowserView crashes very badly indeed:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Application Specific Information:
objc[350]: garbage collection is OFF
abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8ef55ce2 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff8b91d7d2 pthread_kill + 95
2 libsystem_c.dylib 0x00007fff8b90ea7a abort + 143
3 libGLProgrammability.dylib 0x0000000108b944b9 __reloadBuiltInScopes_block_invoke_1 + 179
4 libdispatch.dylib 0x00007fff8542a3f0 dispatch_once_f + 53
5 libGLProgrammability.dylib 0x0000000108b93e81 nameTableGet + 92
6 libGLProgrammability.dylib 0x0000000108b93dfb glpNameTableGetVariableLikeObject + 35
7 libGLProgrammability.dylib 0x0000000108b92bc3 glpSAVariableDeclaration + 283
8 libGLProgrammability.dylib 0x0000000108b8f81a glpSANode + 10534
9 libGLProgrammability.dylib 0x0000000108b8f8a0 glpSANode + 10668
10 libGLProgrammability.dylib 0x0000000108b917da glpSANode + 18662
11 libGLProgrammability.dylib 0x0000000108b7a6be glpCompileShader + 176
12 libGLProgrammability.dylib 0x0000000108b79ca5 ShCompile + 218
13 GLEngine 0x0000000108ab8c07 gleShaderParse + 221
14 GLEngine 0x0000000108a14cf8 glCompileShaderARB_Exec + 230
15 com.apple.imageKit 0x00007fff8654d78d IKLoadShader + 348
16 com.apple.imageKit 0x00007fff865fae6f -[IKGLTextSubpixelShader initWithFragmentCode:] + 130
17 com.apple.imageKit 0x00007fff865fbc4d -[IKGLTextRenderer flush] + 222
18 com.apple.imageKit 0x00007fff86556f1d -[IKImageBrowserView(ImageBrowserDrawing) drawWithCurrentRendererInRect:] + 349
19 com.apple.imageKit 0x00007fff86557c8b -[IKImageBrowserView(ImageBrowserDrawing) drawRect:] + 728
20 com.apple.AppKit 0x000000010043497a -[NSView _drawRect:clip:] + 3758
21 com.apple.AppKit 0x0000000100461b4f -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1583
This is the relevant part - the bottom of the stack trace is just the standard [NSView displayIfNeeded] call to redraw the window.
This is on a dual-GPU MacBook Pro, which might be taking a different pathway than another machine because of the internals of compiling OpenGL code (I think, I'm not much of an expert on this stuff).
The question is, what, if anything, can we do to help ourselves out of this problem? To answer this we need to know what the problem is - is it running out of memory on the GPU? Is it trying to process bad data and getting stuck? The difficulty for us is that because we're not doing anything beyond ImageKit's own classes, there's very few places we can step in to fix things. At a pinch we can limit the number of files displayed per folder, but that seems a bit kludgey.
Any insights?
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden