On Sep 27, 2011, at 2:06 PM, Martin Wierschin wrote: > I have a user reporting a crash whenever they try to first save a file. It is > reproducible for the user (though not be me) and I'm wondering how to best > debug this problem remotely. I've included the crash stack below (all other > threads are waiting/trapped). > > I'm no expert on dyld, but I suspect the crash is triggered when loading up > some bundle code required by OSX's save panel (or perhaps some kind of > installed system enhancer). I've discovered the environment variable > DYLD_PRINT_LIBRARIES_POST_LAUNCH, which I'm hoping will help identify the > relevant library. However, my fear is that this debugging aid logs each > library's path only after each load completes successfully (ie: conceptually > after the crash). If so, that obviously won't help me. > >> OS Version: Mac OS X 10.6.8 (10K540) > ... >> Exception Type: EXC_BAD_ACCESS (SIGBUS) >> Exception Codes: KERN_PROTECTION_FAILURE at 0x000000000000000c >> Crashed Thread: 0 Dispatch queue: com.apple.main-thread >> >> Thread 0 Crashed: Dispatch queue: com.apple.main-thread >> 0 libobjc.A.dylib 0x942ce85b _cache_flush + 78 >> 1 libobjc.A.dylib 0x942d17a5 flush_marked_caches + 242 >> 2 libobjc.A.dylib 0x942cb18d _read_images + 2189 >> 3 libobjc.A.dylib 0x942e0975 map_images_nolock + 1545 >> 4 libobjc.A.dylib 0x942ca189 map_images + 72 >> 5 dyld 0x8fe03f2d >> dyld::notifyBatchPartial(dyld_image_states, bool, char const* >> (*)(dyld_image_states, unsigned int, dyld_image_info const*)) + 795 >> 6 dyld 0x8fe0dec9 >> ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, >> ImageLoader::RPathChain const&) + 251 >> 7 dyld 0x8fe056af dyld::link(ImageLoader*, >> bool, ImageLoader::RPathChain const&) + 137 >> 8 dyld 0x8fe0b240 dlopen + 471 >> 9 libSystem.B.dylib 0x936e02a8 dlopen + 66 >> 10 com.apple.HIToolbox 0x9489d1c2 InitShortcut + 45 >> 11 com.apple.HIToolbox 0x9489d0d1 >> SetupMenuTracking(MenuSelectData&, unsigned char, Point, double, MenuData*, >> unsigned long, unsigned short, Rect const*, Rect const*, unsigned int, Rect >> const*, __CFString const*) + 2964 >> 12 com.apple.HIToolbox 0x9489c07d MenuSelectCore(MenuData*, >> Point, double, unsigned long, OpaqueMenuRef**, unsigned short*) + 227 >> 13 com.apple.HIToolbox 0x9489b8bb _HandleMenuSelection2 + 465 >> 14 com.apple.HIToolbox 0x9489b6d9 _HandleMenuSelection + 53 >> 15 com.apple.AppKit 0x9136ff96 _NSHandleCarbonMenuEvent + >> 285 >> 16 com.apple.AppKit 0x91344b46 _DPSNextEvent + 2304 >> 17 com.apple.AppKit 0x91343dd6 -[NSApplication >> nextEventMatchingMask:untilDate:inMode:dequeue:] + 156 >> 18 com.apple.AppKit 0x913061f3 -[NSApplication run] + 821 >> 19 com.apple.AppKit 0x912fe289 NSApplicationMain + 574 >> 20 com.myAppIdentifier 0x0000330a _start + 216 >> 21 com.myAppIdentifier 0x00003231 start + 41
Crashes inside dyld or libobjc during library load often has one of two causes: 1. A library binary on disk or in the dyld shared cache is corrupted. 2. A memory error earlier in the app corrupted a data structure, and that data structure went unused until library load time. This particular crash is manipulating objc's method caches, so #2 is more likely. If a memory smasher hits a method cache, but that class's methods happen not to be called, then the corruption can go unnoticed for a long time. If the user is sufficiently sophisticated, you might be able to get them to run your app with Guard Malloc enabled via DYLD_INSERT_LIBRARIES. That is probably your best chance of catching a memory smasher. -- Greg Parker gpar...@apple.com Runtime Wrangler _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
