Search results for

LLDB crash

29,559 results found

Post

Replies

Boosts

Views

Activity

Reply to Symbolicating crash report pointing to some wrong method
With your updated test project, I'm seeing the correct backtrace. I built and ran the app as is (in Release mode) using Xcode 15.4, deployed to a device running iOS 17.4. Here's the snippet of the crash log I fetched from the device (using the button for triggering the abort scenario) 3 libsystem_c.dylib 0x1a6063b8c abort + 191 4 CrashTestSDK 0x103248254 0x103244000 + 16980 5 CrashTestSDK 0x103248a94 0x103244000 + 19092 6 CrashTest 0x102cb40f0 @objc ViewController.crashAppWithAbort(_:) + 124 ... Binary Images: 0x103244000 - 0x10324ffff CrashTestSDK arm64 <25321678ecfa3cc28cba4f8f1fafe640> /private/var/containers/Bundle/Application/76B6A167-32E3-4146-9905-C62B1E79EFDF/CrashTest.app/Frameworks/CrashTestSDK.framework/CrashTestSDK 0x102cb0000 - 0x102cbffff CrashTest arm64 <4569900143be3563b1da376612981bb7> /private/var/containers/Bundle/Application/76B6A167-32E3-4146-9905-C62B1E79EFDF/CrashTest.app/CrashTest I symbolicated the log with the following two approaches: % xcrun crashlog /Path/To/C
Aug ’24
Reply to Where can I find headers for LLDB.framework shipped with Xcode?
The various frameworks lurking within Xcode are not considered API. If you want to use LLDB framework in your own code, grab the open source code and build it yourself. how can I know which commit was used to compile lldb that got shipped with Xcode If you do the above then you don’t need to know exactly which commit was used. However, you should be able to work this out anyway, by correlated lldb -v with the tags on that repo. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Apr ’22
Reply to macOS Xcode debugging: can I single-step just one thread while another thread runs free?
I don’t think you can do this from the Xcode GUI but in LLDB you can use the -m option to determine whether other threads will run. In the LLDB prompt, type help thread step-in (or help thread step-over) for more info. This should work at the LLDB prompt in Xcode’s console panel. Be aware that many parts of macOS are multi-threaded and so the this-thread option may well hang if you call into framework code. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: App & System Services SubTopic: Core OS Tags:
Dec ’21
PreviewShell crashes and breaks the preview canvas
Since the first beta of Xcode 16, randomly when editing a SwiftUI view a crash report opens with the message PreviewShell quit unexpectedly. After that, annoyingly often the canvas fails to reload correctly, and shows this broken thing: The only way to get it working again is to restart Xcode, but it happens so often that it really impacts productivity. Does this happen to anyone else? If so, have you found a solution? I've already filed a report (FB14876223)
9
0
3.3k
Aug ’24
Reply to Name shared breakpoints
Hi, After taking a closer look, this appears to be a bug in Xcode. Could you please file a feedback describing your usage and the results you're getting, and share the feedback number here ? As a workaround, you could use Xcode's console debugger to create named breakpoints by doing: Show all the breakpoints. (lldb) breakpoint list Add a name to one of the breakpoint in the list. (lldb) breakpoint name add -N <breakpoint-name> <breakpoint-id> Unfortunately, the breakpoints named on the console debugger won't show up in Xcode's Breakpoint Navigator. To list your newly named breakpoints, you can do: Print the named breakpoints list. (lldb) breakpoint name list One benefit of using the console debugger is that you can have all the lldb commands to create and name your breakpoints saved to a file contained in your Xcode project. This lldbinit file can then be checked into your version control system of choice (i.e. git) but more importantly, you can use it in the Sc
Jun ’20
Reply to Bypass ASLR for debugging purposes
I would like to add something: When we debug a program with lldb, it seems base address is always 0x100000000 on macOS Sonoma (Apple Silicon). So if lldb is able to force a target program's base address, we might have a way to do that too ? And is there a way to disable ASLR for a specific binary when compiling it on macOS ? Thanks
Topic: Privacy & Security SubTopic: General Tags:
Oct ’23
lldb cannot po string anymore (worked last week)
Latest Xcode 7.3 (7D1002)Since yesterday I got the same bug as described here:http://stackoverflow.com/questions/24125539/xcode-lldb-print-statements-fail-nsundomanagerhttp://www.openradar.me/search?query=15890965except that it even happens with NSString variables: po someString error: instance method 'URLEncodedString' has incompatible result types in different translation units ('void *' vs. 'NSString *') error: instance method 'URLDecodedString' has incompatible result types in different translation units ('void *' vs. 'NSString *') note: instance method 'URLEncodedString' also declared here note: instance method 'URLDecodedString' also declared here error: 2 errors parsing expressionI found a workaround for local variables (even though this problem is different):http://lists.apple.com/archives/xcode-users/2014/May/msg00088.htmlctrl-click on variable in local variables list and choose “print description” Printing description of someString: ipadwhich helps a little but cannot print more complex com
0
0
777
May ’16
Reply to Crash log and symbolication when using Xcode Cloud
If I archive only using Xcode Cloud (with the option to include symbol enabled), can the Xcode Organizer show symbolicated crash logs for app builds that are more than 30 days old (the archive availability window)? For example, a crash for an app version released 6 months ago. This is where you should treat Xcode Cloud as separate from what happens after you submit a build to App Store Connect. Xcode Cloud can do an archive your app, and then additionally submit that build to the App Store according to options you configure. You could do both of those at your desk as well, with the same options. So if you ask Xcode Cloud to upload your build to the App Store with symbols, you'll get automatically symbolicated crash reports in Xcode Organizer, the same way as if you submitted the build to the App Store by archiving at desk in Xcode and submitting from your desk, with the option to include symbols enabled. After this point of submitting to the App Store, you're then in the world of su
Jun ’25
fatal error: unexpectedly found nil while unwrapping an Optional value (lldb)
I have no idea what to do. I am building a weather app. I created a variable with the url and I know the url works but I need the data for the place the user types into the text field. So I concatenate my UITextField in the correct place in the url and I get this error in the log.fatal error: unexpectedly found nil while unwrapping an Optional value(lldb) here is my code:import UIKitclass ViewController: UIViewController { @IBOutlet weak var textfield1: UITextField! @IBOutlet weak var outputlbl: UILabel! @IBAction func findtheweather(sender: UIButton) { let url = NSURL(string: http://www.weather-forecast.com/locations/ + textfield1.text! + /forecasts/latest)! let task = NSURLSession.sharedSession().dataTaskWithURL(url) { (data, response, error) -> Void in if let urlcontent = data { let webcontent = NSString(data: urlcontent, encoding: NSUTF8StringEncoding) let websitearray = webcontent!.componentsSeparatedByString(3 Day Weather Forecast Summary:</b><span class=read-more-small><span
1
0
1.8k
Jun ’16
Reply to crash report _NSThreadPerformPerform
Thank you. I was able to successfully reproduce printing the UIKit applicationWillTerminate: selector in my modified test app.My test app crash report shows the x1 register had an address of:0x0000000190bef16dThe test app crash report also shows the load address of UIKit:0x1900ad000 - 0x190e3afff UIKit arm64 <7ef942f43c3e3e4aa6cec127b68ecbab> /System/Library/Frameworks/UIKit.framework/UIKitIn the debugger, the image list shows the base address of UIKit as:[ 6] 7EF942F4-3C3E-3E4A-A6CE-C127B68ECBAB 0x00000001900ad000 /Users/andrewshort/Library/Developer/Xcode/iOS DeviceSupport/10.1.1 (14B100)/Symbols/System/Library/Frameworks/UIKit.framework/UIKitOf course the UUIDs match up since this is just a test app that I'm intentionally crashing. So, now I calculate the offset of x1 from the crash report base address:(lldb) p/x 0x0000000190bef16d-0x1900ad000 (long) $0 = 0x0000000000b4216dNote that 0x0000000000b4216d is the same value you got!and add that to your new base
Nov ’16