Re: debugging crashes in dyld?
Re: debugging crashes in dyld?
- Subject: Re: debugging crashes in dyld?
- From: Greg Parker <email@hidden>
- Date: Tue, 27 Sep 2011 14:58:06 -0700
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 email@hidden Runtime Wrangler
_______________________________________________
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