> On Mar 16, 2015, at 19:21 , Greg Parker <[email protected]> wrote: > > >> On Mar 16, 2015, at 4:47 PM, Rick Mann <[email protected]> wrote: >> >>> otool -t -V APP > /tmp/longFileOfDisassembly >>> >>> vi the file and look for _dsyrk_ instances, they should be in comments like >>> ## symbol stub for _dsyrk_ >>> >>> scan backwards to find what routine you’re in, should be a couple of >>> screenfuls up at most. >>> >>> Obviously better using a debug version of the code :) >> >> I tried that. I get this: >> >> $ otool -tV MyApp | edit >> otool(49911,0x7fff7f1cd300) malloc: *** error for object 0x6b2db0: pointer >> being freed was not allocated >> *** set a breakpoint in malloc_error_break to debug > > Are your command-line tools out of date with respect to your installed Xcode? > Try using `xcrun otool` and similar for the other command-line tools you run. > > >> But it does generate a couple million lines of output before crashing. I can >> find only one reference: >> >> 00175308 f3c4e972 blx 0x5395f0 @ symbol stub for: _dsyrk_ >> >> But nothing more. There doesn't seem to be any debug info (despite this >> being a debug build; the dSYM is separate, dunno how to incorporate that). > > That is a call site. Look upwards in the disassembly for the nearest > preceding symbol. If you are lucky then that symbol will be a useful one. If > you are unlucky then that symbol will be a red herring because the real > symbol was stripped. > > otool will not read the matching dSYM file, but lldb will. Try this: > 1. Place your app and your dSYM in the same directory > 2. `xcrun dwarfdump -u /path/to/YourApp.app/YourApp` and `xcrun dwarfdump -u > /path/to/YourApp.app.dSYM`. This will print UUIDs. Make sure the app and the > dSYM match. > 3. `xcrun lldb -arch arm64 /path/to/YourApp.app`. If your app is 32-bit then > use `-arch armv7s` instead. > 4. In lldb, `image list YourApp`. That should print YourApp's executable and > its dSYM file. > 5. In lldb, `x/i 0x00175308`. That should print the branch instruction that > you found using otool. > 6. In lldb, `image lookup -v -a 0x00175308`. That will print everything lldb > knows about that address and the function it is in. If all has gone well then > that will include function names, file names and line numbers, and any > inlining involved.
Thanks, Greg, that's useful info. I ended up semi-manually searching various .o files generated, and we discovered that the Ceres build was looking for a different flag to avoid using dsyrk_. Once we got that building correctly, I was finally able to produce a binary that didn't try to link against it. Sure would be nice if Xcode would just tell me where that symbol is referenced when app validation fails. ;-) -- Rick Mann [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
