Post not yet marked as solved
There have been occasional questions about remote debugging. Unfortunately I see a couple of them which were reasonable basic questions got no answer at all. I will try this again. A couple questions had some mention of lldb server. In some cases clearly the people asking the questions already knew a bit about remote debugging. Yet I can find no documentation about it.Does XCode or other tools that will work with XCode support debugging over the internet? If so what are the reqirements re XCode version and macOS version, whether the client and server can have unmatched versions, etc.?My immediate need (without extra steps) is to debug a process running on Sierra (no XCode installed yet) from a development system running XCode 7.3.1 under El Capitan.The need for remote debugging is to be able to diagnose crashes that don't happen on my development systems. There have also been questions concerning crash logs, but crash logs are of limited use unless the crash can be opened into a debugger with full ability to examine the stack and local variables.Thanks in advance!
Post not yet marked as solved
I want to do source level debugging of an external environment using Xcode's graphical debugger.
I have an External Build System project with local source files that builds libraries/executables (not macOS or iOS) and creates their dSYM symbol files (also stored locally). I have a script that I can run from Xcode that starts the library/executables (in an external environment), and gets their slide addresses so their symbols can be loaded into lldb. The script also returns a gdb-remote url that I can use with lldb to begin debugging.
Is there a way for Xcode to use the lldb info gathered by my script to start its graphical debugger?
If this feature doesn't exist, then I see two simple ways that this feature could be implemented:
a) In the Run Action, there's a Run Script action in the Pre-actions to start the remote environment and gather the debug info to create a lldb script that has the gdb-remote command, and commands to add the target modules, and to load the target modules with their slide values. All of that I've already implemented. The Run Action can then have an option to launch lldb with the generated lldb source script.
b) The Run Script action in the Pre-actions of the Run Action that sets up the external environment and gathers the debug info can launch lldb itself with the generated lldb source script. The Run Action can have an option to watch the terminal output for an lldb prompt and then take over when the prompt appears.
Post not yet marked as solved
HI devs, help me please, i want to debug Big Sur kernel on inter-based macbook from Monterey on m1, i have installed KDK_11.6.4_20G417.kdk in Monterey system on m1 macmini, then launch lldb, have created target and got this message : WARNING! Python version 3 is not supported for xnu lldbmacros.
(lldb) target create /Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel
warning: 'kernel' contains a debug script. To run this script in this debug session:
command script import "/Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/kernel.py"
To run all discovered debug scripts in this session:
settings set target.load-script-from-symbol-file true
Current executable set to '/Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel' (x86_64).
(lldb) settings set target.load-script-from-symbol-file true
##############################
WARNING! Python version 3 is not supported for xnu lldbmacros.
Please restart your debugging session with the following workaround
defaults write com.apple.dt.lldb DefaultPythonVersion 2
##############################
Loading kernel debugging from /Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/kernel.py
LLDB version lldb-1300.0.42.3
Swift version 5.5.2-dev
settings set target.process.python-os-plugin-path "/Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/lldbmacros/core/operating_system.py"
settings set target.trap-handler-names hndl_allintrs hndl_alltraps trap_from_kernel hndl_double_fault hndl_machine_check _fleh_prefabt _ExceptionVectorsBase _ExceptionVectorsTable _fleh_undef _fleh_dataabt _fleh_irq _fleh_decirq _fleh_fiq_generic _fleh_dec
command script import "/Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/lldbmacros/xnu.py"
error: module importing failed: Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Library/Developer/KDKs/KDK_11.6.4_20G417.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/lldbmacros/xnu.py", line 123
print "Execution interrupted by user"
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Execution interrupted by user")?
settings set target.process.optimization-warnings false
How can i solve this problem? lldb linked with python 3, but kdk uses python 2, also command line tools version 12.5.1 which uses python 2 i can not install on monterey too.
Post not yet marked as solved
Hi,
I have error messages when I try to print some values in debug like "po varname" or "po expression"
I have messages:
error: expression failed to parse:
error: Couldn't realize type of self.
I use Xcode without rosetta, 13.3
I tried to clear derived data and clean project, it helps but after relaunch Xcode I have the same problem again
Post not yet marked as solved
In some particular situation, Xcode debugger or lldb cli cannot correctly extract some value that returned by a async throw function and handled by guard let try?.
Here is the minimum example:
import Dispatch
func test() async throws -> [Int] {
return [369]
}
let group = DispatchGroup()
group.enter()
let task = Task {
guard let res = try? await test() else { return }
print(res)
group.leave()
}
group.wait()
If added a break point at print(res), the debugger cannot show the value of res.
Due to forum limitation, I cannot paste a screenshot here...
if use p res or po res at lldb cli, it shows:
(lldb) p res
error: expression failed to parse:
error: <EXPR>:3:1: error: cannot find 'res' in scope
res
^~~
(lldb) po res
error: expression failed to parse:
error: <EXPR>:3:1: error: cannot find 'res' in scope
res
^~~
If test() returns a dict, or a costom struct, the issue retains. But if returned a trivial value like Int, it acts normally.
Also, if remove the guard statement, make res a optional value(use let res = try? await test()), debugger can extract the value.
Above results are compiled and run in this environment:
Swift 5.6.1
Xcode 13.4.1 (13F100)
lldb-1316.0.9.46
macOS 12.4
x86_64 arch
Post not yet marked as solved
We are running into an issue where breakpoints are not resolving on Xcode 14 (The same break points on Xcode 13.4.1 are working fine). They change to an outline when we run our app
I have tried all the usual fixes
Cleaned the build
Cleaned Derived data
Restarted Xcode
Restarted the machine
Re-cloned the repo to see if starting fresh helps
I have also tried
Removing all symbol stripping
Ensuring the DSYM is getting generated and is loaded in the debugger
Removing all optimization options
Tried the Xcode 14.1 beta
What's really strange is the break points will work occasionally and will work for a few runs and then stop working again. Does anyone have any suggestions?
Post not yet marked as solved
I don't know when this started but it's basically brought my development to a standstill. I know it worked fine in macOS 13.2.1, though I didn't try Xcode 14.3 RC 2 in 13.2.1.
Basically, Xcode 14.3 RC 2 (14E222b) and also Xcode 14.2 (14C18) (which had been stable up till now) are both unable to launch the app in debug mode. As soon as the launched/debugged app finally starts, the following is printed to Xcode's console:
Message from debugger: The LLDB RPC server has crashed. You may need to manually terminate your process. The crash log is located in ~/Library/Logs/DiagnosticReports and has a prefix 'lldb-rpc-server'. Please file a bug and attach the most recent crash log.
The crash log is always the same. The full log is at https://gist.github.com/NSGod/5e194900bd6f5a9ac9328b936a26037e.
There seems to be an infinite loop in thread 6:
Thread 6 Crashed:: <lldb.process.internal-state(pid=30877)>
0 LLDB 0x12030cfb4 ParseTrieEntries(....) + 20
1 LLDB 0x12030d653 ParseTrieEntries(....) + 1715
After I initially encountered this issue in Xcode 14.3 RC 2 (14E222b) with my business project, I tried creating a new Cocoa app using Xibs and Objective-C and still encountered the problem in that project. I've cleaned out the build folders, etc. but that made no difference. I opened both my business project and a new project in Xcode 14.2 (14C18) but saw no difference (it still crashes). I also tried in a new user account using both versions of Xcode but they both crash.
Could having Python 3.10 and 3.11 installed through MacPorts anything to do with it (I noticed Python 3.9 in the binary images, but I'm not sure).
Any ideas?
Post not yet marked as solved
The .NET Runtime has shipped an lldb extension that looks to extend LLDB functionality to be able to reason about .NET managed code. This has been working for a long time, but now it fails to load with the error error: this file does not represent a loadable dylib. Loading works if I use a self-compiled version of LLDB. I can't really debug XCode's LLDB, but there are some logs that seemed to hint it was signing checks failing for library validation, but neither Developer nor Application signing would satisfy these. LLDB resides within the XCode bundle at /Applications/Xcode.app/Contents/Developer/usr/bin/lldb. codesign confirms that the bundle enforces library validation. Is there any way to confirm this is the issue? It looks like:
Library Validation failed: Rejecting '/*/libsosplugin.dylib' (Team ID: none, platform: no) for process 'lldb(77691)' (Team ID: none, platform: yes), reason: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)
and
Library Validation failed: Rejecting '/*/libsosplugin.dylib' (Team ID: UBF8T346G9, platform: no) for process 'lldb(77691)' (Team ID: none, platform: yes), reason: mapping process is a platform binary, but mapped file is not
If that's the issue, what's the suggested way forward to have loadable lldb plugins? If not, what's the recommended way to diagnose this? lldb logging is verbose, but doesn't provide any information around this.
Post not yet marked as solved
Env: Monterey 12.6.5, Xcode 14.0.1 Recent update for xcode. Straight forward declaration of bitset, but a large one. std::bitset<1048567> bs ; Running code in xcode, suddenly started getting lldb notice "Message from debugger: The LLDB RPC server has exited unexpectedly. You may need to manually terminate your process. Please file a bug if you have reproducible steps." upon entering the function itself, not when executing the bitset declaration line. Moved the declaration to main, and still lldb notice. Then noticed bitset size in debugger dialog is 256 (see snippet image), although the bitset's "real" size is as declared (debugger shows real size in parentheses, but only show first 256 bits). Checked vector, it is show and represents in full. Duplicated on Ventura 13.3.1, Xcode 14.2. Suspect the LLDB issue was from changing bitset size to pow(2,64) before, which compiles, but generates "thread EXC_BADACCESS ..." error/warning. Two issues: first, why only display first 256 bits of a bitset in debugger? And if there is a logical reason, then change the description for the hard-set 256 size when n >=256 from "size=256" to "view size=256" With the lldb error, I thought there was an error that did not exist, notably compiler was now changing my declared size to 256 for any size n > 256. Second, the "thread EXC_BADACCESS..." error when bitset size is too large should be reported by compiler as max size exceeded, after all, the bitset size n declared has to be a const and the compiler knows both n and the max bitset size_t N...the error reported is better than nothing, but not the most meaningful.
Hi folks, I'm trying to debug some broken constraints and I stumbled upon a post on medium that showed how to get the memory address of the view with broken constraints and how to change the bg color for easy debugging.
In the post the person show the following code
ex [(UIView *)0x7f94ff5b3890 setBackgroundColor: [UIColor greenColor]]
It changes the background color of the UIView that has a broken constraint to easily identify it on the app.
My goal is to write that code in Swift, since I'm not very familiar with Objective-C and I'd like to know how it looks in Swift.
I've got as far as this (fake address for posting purposes)
(lldb) ex -l swift -- import Foundation
(lldb) ex -l swift -- import UIKit
(lldb) ex -l swift -- UnsafeMutableRawPointer(bitPattern: 0x000)?.load(as: UIView.self)
(UIView?) $R9 = 0x000 {
UIKit.UIResponder = {
ObjectiveC.NSObject = {}
}
}
But if I try to print the backgroundColor or any other property, I get this error:
2023-06-29 11:31:22.644347-0300 APP - DBG[...] +[APP.Button frame]: unrecognized selector sent to class 0x000
error: Execution was interrupted, reason: internal ObjC exception breakpoint(-5)..
The process has been returned to the state before expression evaluation.
Any clues on how to do it or why it is happening?
(Also any sessions regarding this kind of debugging is welcome)
Post not yet marked as solved
Why did I get an error in playground in debug window for this code?
print("// MARK: - Start execable code here...")
do {
let store = CNContactStore()
if try await store.requestAccess(for: .contacts) {
// Do something with Contacts.
let phoneNumber = CNPhoneNumber(stringValue: "903-276-1046")
let predicateForContactsMatchingPhoneNumber = CNContact.predicateForContacts(matching: phoneNumber)
let contactFetchRequest = CNContactFetchRequest(keysToFetch: thoroughKeysToCompare)
contactFetchRequest.predicate = predicateForContactsMatchingPhoneNumber
contactFetchRequest.unifyResults = true
var contactOfMe: CNContact! = nil
try! store.enumerateContacts(with: contactFetchRequest) {
contact, stop in
contactOfMe = contact
stop.pointee = true
}
let contact = Contact(cnContact: contactOfMe)
for property in contact.enumerated() {
print("- \(property)")
}
} else {
// Handle if Contacts access is denied.
fatalError()
}
} catch {
// Handle any error.
print("error requesting access: \(error.localizedDescription)")
}
Debug window:
// MARK: - Start execable code here...
Playground execution failed:
error: Execution was interrupted, reason: shared-library-event.
The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation.
* thread #1, queue = 'com.apple.main-thread'
frame #0: 0x00007ff80002f931 libobjc.A.dylib`_mapStrHash(_NXMapTable*, void const*) + 73
frame #1: 0x00007ff80002fc7f libobjc.A.dylib`_NXMapMember(_NXMapTable*, void const*, void**) + 35
frame #2: 0x00007ff80003b7ae libobjc.A.dylib`getProtocol(char const*) + 41
frame #3: 0x00007ff8000428e6 libobjc.A.dylib`class_conformsToProtocol + 337
frame #4: 0x00007ff80004ab4e libobjc.A.dylib`-[NSObject conformsToProtocol:] + 47
frame #5: 0x0000000109c27951 UIKitCore`_UIFocusItemContainerIsScrollableContainer + 74
frame #6: 0x0000000109c28e38 UIKitCore`-[_UIFocusEnvironmentContainerTuple initWithOwningEnvironment:itemContainer:] + 194
frame #7: 0x0000000109c28fed UIKitCore`+[_UIFocusEnvironmentContainerTuple tupleWithOwningEnvironment:itemContainer:] + 70
frame #8: 0x0000000109c4f41e UIKitCore`_UIFocusRegionContainerFromEnvironmentAndContainer + 44
frame #9: 0x0000000109c27ed3 UIKitCore`_UIFocusItemContainerAddChildItemsInContextWithArguments + 1162
frame #10: 0x000000010a99c439 UIKitCore`-[UIView _searchForFocusRegionsInContext:] + 962
frame #11: 0x0000000109c6b37f UIKitCore`-[_UIFocusMapSnapshot addRegionsInContainer:] + 4583
frame #12: 0x0000000109c69740 UIKitCore`-[_UIFocusMapSnapshot _capture] + 456
frame #13: 0x0000000109c67fc5 UIKitCore`-[_UIFocusMapSnapshot _initWithSnapshotter:mapArea:searchArea:] + 628
frame #14: 0x0000000109c6cce2 UIKitCore`-[_UIFocusMapSnapshotter captureSnapshot] + 227
frame #15: 0x0000000109c5f450 UIKitCore`-[_UIFocusMap _inferredDefaultFocusItemInEnvironment:] + 147
frame #16: 0x0000000109c2b1cf UIKitCore`-[_UIFocusEnvironmentPreferenceEnumerationContext _inferPreferencesForEnvironment:] + 157
frame #17: 0x0000000109c2abbc UIKitCore`-[_UIFocusEnvironmentPreferenceEnumerationContext _resolvePreferredFocusEnvironments] + 118
frame #18: 0x0000000109c2ab12 UIKitCore`-[_UIFocusEnvironmentPreferenceEnumerationContext prefersNothingFocused] + 31
frame #19: 0x0000000109c2beeb UIKitCore`_enumeratePreferredFocusEnvironments + 198
frame #20: 0x0000000109c2c061 UIKitCore`_enumeratePreferredFocusEnvironments + 572
frame #21: 0x0000000109c2c061 UIKitCore`_enumeratePreferredFocusEnvironments + 572
frame #22: 0x0000000109c2c061 UIKitCore`_enumeratePreferredFocusEnvironments + 572
frame #23: 0x0000000109c2bd11 UIKitCore`-[_UIFocusEnvironmentPreferenceEnumerator enumeratePreferencesForEnvironment:usingBlock:] + 230
frame #24: 0x0000000109c2c747 UIKitCore`-[_UIDeepestPreferredEnvironmentSearch deepestPreferredFocusableItemForEnvironment:withRequest:] + 817
frame #25: 0x0000000109c95837 UIKitCore`-[UIFocusUpdateContext _updateDestinationItemIfNeeded] + 265
frame #26: 0x0000000109c95627 UIKitCore`-[UIFocusUpdateContext _destinationItemInfo] + 22
frame #27: 0x0000000109c95535 UIKitCore`-[UIFocusUpdateContext nextFocusedItem] + 24
frame #28: 0x0000000109c71ea6 UIKitCore`-[UIFocusSystem updateFocusIfNeeded] + 1347
frame #29: 0x0000000109c7608c UIKitCore`__43-[UIFocusSystem _updateFocusUpdateThrottle]_block_invoke + 34
frame #30: 0x000000010a94b971 UIKitCore`-[_UIAfterCACommitBlock run] + 57
frame #31: 0x000000010a94be71 UIKitCore`-[_UIAfterCACommitQueue flush] + 191
frame #32: 0x000000010a3926eb UIKitCore`_runAfterCACommitDeferredBlocks + 782
frame #33: 0x000000010a380fa2 UIKitCore`_cleanUpAfterCAFlushAndRunDeferredBlocks + 96
frame #34: 0x000000010a3b6be1 UIKitCore`_afterCACommitHandler + 58
frame #35: 0x00007ff8003b1c12 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
frame #36: 0x00007ff8003ac57f CoreFoundation`__CFRunLoopDoObservers + 515
frame #37: 0x00007ff8003acaa2 CoreFoundation`__CFRunLoopRun + 1121
frame #38: 0x00007ff8003ac264 CoreFoundation`CFRunLoopRunSpecific + 560
frame #39: 0x00007ff8003ad234 CoreFoundation`CFRunLoopRun + 40
frame #40: 0x00007ff83755a4e3 libswift_Concurrency.dylib`swift_task_asyncMainDrainQueueImpl() + 35
frame #41: 0x00007ff83755a4b4 libswift_Concurrency.dylib`swift_task_asyncMainDrainQueue + 52
frame #42: 0x00000001015d409f $__lldb_expr32`main at <unknown>:0
frame #43: 0x0000000100e25560 EnumeratedContactsCNContact`linkResources + 256
frame #44: 0x00007ff8003b2986 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
frame #45: 0x00007ff8003b2148 CoreFoundation`__CFRunLoopDoBlocks + 399
frame #46: 0x00007ff8003ace09 CoreFoundation`__CFRunLoopRun + 1992
frame #47: 0x00007ff8003ac264 CoreFoundation`CFRunLoopRunSpecific + 560
frame #48: 0x00007ff809b4024e GraphicsServices`GSEventRunModal + 139
frame #49: 0x000000010a3827bf UIKitCore`-[UIApplication _run] + 994
frame #50: 0x000000010a3875de UIKitCore`UIApplicationMain + 123
* frame #51: 0x0000000100e256c5 EnumeratedContactsCNContact`main + 357
frame #52: 0x0000000100fbb384 dyld_sim`start_sim + 10
frame #53: 0x000000010943341f dyld`start + 1903```
Post not yet marked as solved
I’m trying to use the allocated variables given after p self ($R1 for instance) but after resuming the process and then pausing it again, I cannot access to $R1.
(lldb) p self
(Signals.MainContainerViewController) $R1 = 0x000000012ba19dc0 {
...
(lldb) po $R1
<Signals.MainContainerViewController: 0x12ba19dc0>
(lldb) c
Process 88944 resuming
(lldb) expression -O -l swift -- $R1
warning: Module "/usr/lib/system/libsystem_kernel.dylib" uses triple "arm64-apple-macosx13.4.0", which is not compatible with the target triple "arm64-apple-ios16.0.0-simulator". Enabling per-module Swift scratch context.
error: expression failed to parse:
error: <EXPR>:3:1: error: cannot find '$R1' in scope
$R1
^~~
(lldb)
Does someone have an idea?
macOS: 13.4.1 (22F82)
Xcode Version 14.3.1
Post not yet marked as solved
I'm trying to attach with lldb to a x64 process running under Rosetta, attachment itself succeeded but lldb is unable to load target neither it's modules.
And getting this output:
(lldb) process attach --pid 20586
Process 20586 stopped
* thread #1, stop reason = signal SIGSTOP
frame #0: 0x00007ff813a1d1ee
-> 0x7ff813a1d1ee: jae 0x7ff813a1d1f8
0x7ff813a1d1f0: movq %rax, %rdi
0x7ff813a1d1f3: jmp 0x7ff813a18cdb
0x7ff813a1d1f8: retq
Target 0: (No executable module.) stopped.
Architecture set to: x86_64-apple-macosx-.
(lldb) target modules list
error: the target has no associated executable images
A few weeks ago I had the same problem, but some combination of actions like rebuilding deleting and redownloading binaries and some other unknown magic fixed this behaviour. And today I stumbled upon this problem again, and same actions does not make any effect.
Attaching to process works in general (event to processes running under Rosetta), but this specific process I want to debug is causing troubles.
This is what successful attachment looks like:
(lldb) process attach --pid 20576
warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not read from the host's in-memory shared cache. This will likely reduce debugging performance.
Process 20576 stopped
* thread #1, name = 'CrRendererMain', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0x00007ff813a185b2 libsystem_kernel.dylib`mach_msg2_trap + 10
libsystem_kernel.dylib`mach_msg2_trap:
-> 0x7ff813a185b2 <+10>: retq
0x7ff813a185b3 <+11>: nop
libsystem_kernel.dylib`macx_swapon:
0x7ff813a185b4 <+0>: movq %rcx, %r10
0x7ff813a185b7 <+3>: movl $0x1000030, %eax ; imm = 0x1000030
Target 0: (Electron Helper (Renderer)) stopped.
Executable module set to "/Users/mb/work/positron/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Helper (Renderer).app/Contents/MacOS/Electron Helper (Renderer)".
Architecture set to: x86_64-apple-macosx-.
To give a bit more context my MacOS version is 13.14.1 on MacBook Pro with M2 chip.
Post not yet marked as solved
How are debug maps saved in Mach-O files? I'm trying to essentially recreate the output of dsymutil -dump-debug-map.
Post not yet marked as solved
We've got hundreds of crashes in our SwiftUI app which we think are "silent" crashes as there are no complaints from clients and yet - it happens on the main thread in the foreground so I'm not completely sure.
The annoying thing is that we have no idea by the stack trace what is causing this issue, I feel helpless as this is causing some very loud noise through management and honestly - myself who wants to have this noise cleared.
this particular crash is the highest impact (one of a few different weird crashes in our app without clear stack trace)
0 SwiftUI 0x895d90 OUTLINED_FUNCTION_2 + 836
1 SwiftUI 0x895da8 OUTLINED_FUNCTION_2 + 860
2 SwiftUI 0x1329880 OUTLINED_FUNCTION_2 + 424
3 SwiftUI 0x6806c OUTLINED_FUNCTION_441 + 584
4 SwiftUI 0x481b0 OUTLINED_FUNCTION_194 + 544
5 UIKitCore 0x1b7194 -[UIViewController removeChildViewController:notifyDidMove:] + 128
6 UIKitCore 0x77d6e8 -[UINavigationController removeChildViewController:notifyDidMove:] + 80
7 UIKitCore 0x205224 -[UIViewController dealloc] + 768
8 UIKitCore 0x1036c -[UINavigationController viewDidDisappear:] + 372
9 UIKitCore 0xd9c4 -[UIViewController _setViewAppearState:isAnimating:] + 1012
10 UIKitCore 0x46e61c -[UIViewController __viewDidDisappear:] + 136
11 UIKitCore 0x7ec024 __64-[UIViewController viewDidMoveToWindow:shouldAppearOrDisappear:]_block_invoke_3 + 44
12 UIKitCore 0x1a3f24 -[UIViewController _executeAfterAppearanceBlock] + 84
13 UIKitCore 0x1a3e68 -[_UIAfterCACommitBlock run] + 72
14 UIKitCore 0x1a3d9c -[_UIAfterCACommitQueue flush] + 176
15 UIKitCore 0x1a3ca8 _runAfterCACommitDeferredBlocks + 496
16 UIKitCore 0x3f530 _cleanUpAfterCAFlushAndRunDeferredBlocks + 108
17 CoreFoundation 0x43564 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28
18 CoreFoundation 0xabd9c __CFRunLoopDoBlocks + 368
19 CoreFoundation 0x7bbbc __CFRunLoopRun + 856
20 CoreFoundation 0x80ed4 CFRunLoopRunSpecific + 612
21 GraphicsServices 0x1368 GSEventRunModal + 164
22 UIKitCore 0x3a23d0 -[UIApplication _run] + 888
23 UIKitCore 0x3a2034 UIApplicationMain + 340
24 SwiftUI 0x1d1014 OUTLINED_FUNCTION_895 + 2420
25 SwiftUI 0x13216c block_copy_helper.1 + 388
26 SwiftUI 0x11b4bc OUTLINED_FUNCTION_901 + 2868
Number 27 will be our app's Main function and that it - no other trace of our apps code.
Firebase is saying this happens 100% on iOS 16 only and always on the foreground.
How can I get to the bottom of this? how can I debug such a crash?
Post not yet marked as solved
xcrun devicectl has support for installing and launching apps but does it support launching a debugserver? I've tried xcrun devicectl device process launch /usr/libexec/debugserver to no avail.
Is there something I'm missing or perhaps another tool that would let me start a debugserver from command line?
Post not yet marked as solved
Hello, I am facing an issue when debugging cpp code through the XCode after updating to XCode 15.0.
During debugging, in a variables watch view, it is shown for the collections (let's take std::vector as an example) that its size is 0 even if it is not. If I add it as an expression to watch, it is fine. Also if I print it in lldb console, it is also fine. Any thoughts on this?
Post not yet marked as solved
Hello,
My purpose is to understand how macOS works.
Here is what i've done: I have wrote a c program on a M1 CPU with this lines:
printf("Before breakpoint\n");
asm volatile("brk #0");
printf("After breakpoint\n");
When i run this program with lldb, a breakpoint is hit on the second line. So i suppose lldb is writing a "brk #0" instruction when we put a breakpoint manually.
I can't continue to next line with lldb "c" command. PC stays on the brk instruction. I need to manually set PC to next instruction in lldb.
Now, what i want to do is to create my own debugger. (I want to understand how lldb works).
I have managed to ptrace the target program and i was able to catch an event with waitpid when "brk #0" is hit. But i don't know how i can increase PC value and continue execution because i can't do this on Silicon CPU:
ptrace(PTRACE_GETREGS, child_pid, NULL, &regs);
ptrace(PTRACE_SETREGS, child_pid, NULL, &regs);
kill(child_pid, SIGCONT);
So my question is: How does lldb managed to change ARM64 registers of a remote process ?
Thanks
Post not yet marked as solved
Hello,
I have tried to create a thread with thread_create_running API.
It works but i would like to suspend this thread. I can call thread_suspend, but my thread has already been start before i call this API.
Is there a way to create a thread without running it automaticaly.
Thanks
Post not yet marked as solved
Hello.
I am currently developing a C++ application for x86_64 using XCode, and I am experiencing the same problem as described in the following link.
https://discourse.llvm.org/t/lldb-doesnt-stop-on-sigabrt-assert-with-x86-executable-on-apple-arm/69749/1
Due to this bug, when the application crashes, it is difficult to tell which source code caused the crash, and this is reducing our development efficiency.
How can this be fixed?
Thank you in advance for your help.