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,
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 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
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
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
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
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
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
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
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```
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)