Search results for

LLDB crash

29,559 results found

Post

Replies

Boosts

Views

Activity

fail to install lldb on Big Sur (11.0) from command line
Hi, I'm using the following command in order to install lldb without Xcode > xcode-select --install However, the window that pops up with the progress bar gets halted on task Finding Software Those are the relevant errors I could trace from log stream: 2020-07-29 14:17:28.792892+0300 0x2bfe Default 0x68a7 163 0 runningboardd: (RunningBoard) [com.apple.runningboard:process] [daemon<com.apple.dt.CommandLineTools.installondemand(502)>:843] Error 45 setting darwin role to UserInteractive: Operation not supported, falling back to setting priority 2020-07-29 14:17:28.931499+0300 0x2bff Default 0x68af 163 0 runningboardd: (RunningBoard) [com.apple.runningboard:process] [daemon<com.apple.dt.CommandLineTools.installondemand(502)>:843] Error 45 setting darwin role to UserInteractiveFocal: Operation not supported, falling back to setting priority Any idea how to tackle this issue?
1
0
570
Jul ’20
Why is CFNetworking crashing on iOS11
We have an app that is working just fine in iOS 10, but crashes in iOS 11.I am currently trying to trace the problem, but the first crash is here; CFDataRef bodyData = CFHTTPMessageCopyBody( message ); CFHTTPMessageSetBody( newMessage, bodyData ); CFRelease( bodyData ); bodyData = NULL; It seems that I get a nil value from the CFHTTPMessageCopyBody in iOS 11, but not in iOS 10;From debugger;iOS 11(lldb) po message<CFHTTPMessageRef 0x1c417fbc0(0x1c417fbd0)> { GET request, url /873769144/sec/ENCRYPTED_Television*******_240516_1.mp4 -- http:/(lldb) po bodyData<nil>(lldb) po newMessage<CFHTTPMessageRef 0x1c4360840(0x1c4360850)> { GET request, url http:/****iOS 10(lldb) po message<CFHTTPMessageRef 0x170173a40(0x170173a50)> { GET request, url /771278348/sec/ENCRYPTED_Television_**********_240516_1.mp4 -- http:/(lldb) po bodyData<>(lldb) po newMessage<CFHTTPMessageRef 0x170173b00(0x170173b10)> { GET request, u
4
0
3.1k
Oct ’17
Reply to Crash starting app after upgrade to Monterey
Is there something else that may interfere? Because I have the same disassembly result, however, I have the crash: (lldb) r Process 8502 launched: '/Users/aple/workspace/gperftools/a.out' (x86_64) malloc(128) returned 0x100604000 Process 8502 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x0000000000000000 error: memory read failed for 0x0 Target 0: (a.out) stopped. (lldb) disas -n main a.out`main: ... 0x100003f26 <+22>: movl $0x80, %edi 0x100003f2b <+27>: callq 0x100003f5e ; symbol stub for: malloc 0x100003f30 <+32>: movq %rax, -0x18(%rbp) ... 0x100003f46 <+54>: movq -0x18(%rbp), %rdi 0x100003f4a <+58>: callq 0x100003f58 ; symbol stub for: free 0x100003f4f <+63>: xorl %eax, %eax ... (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x0000000000000000 frame #1: 0x0000000100003f4f a.out`main + 63 frame #
Nov ’21
Reply to Xcode 14.2+: lldb-rpc-server has crashed.
I had an issue with Xcode 15.0 beta 5 (15A5209g) where I received the blocking error The LLDB RPC server has crashed.. I was unable to run the Playground nor proceed. My project is a Swift Package & Playground and I found that removing the folder.swiftpm made the error go away. That directory has a folder structure that looks like Breakpoint XMLs. It's possible this was corrupted and causing the blocking error. Most of my research mentioned breakpoints were the problem. Hoping this helps someone in the future.
Aug ’23
Reply to Can LLDB be used on Sandboxed Apps
Should this work? Yes. And, indeed, it does work on my machine. I created a test project from the macOS > App template, which defaults to being sandboxed, and I was able to debug it with the command-line LLDB: % codesign -d --entitlements - Test747110.app … [Dict] [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.files.user-selected.read-only [Value] [Bool] true [Key] com.apple.security.get-task-allow [Value] [Bool] true % lldb Test747110.app (lldb) target create Test747110.app Current executable set to '…/Test747110.app' (arm64). (lldb) r Process 70203 launched: '…/Test747110.app/Contents/MacOS/Test747110' ``` This is Xcode 15.2 on macOS 14.2.1. Are you sure that sandboxing is the only constraint here? If, for example, your sandboxed app was downloaded from the Mac App Store, you can’t debug that with LLDB. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: Programming Languages SubTopic: General Tags:
Feb ’24
Reply to How do i fix the sigabrt error (Tried Everything)
On the first page of the Xcode Overview document, there is a screenshot of the entire Xcode workspace. Notice at the bottom, second from the right, a white area with (lldb) in blue. That's the debugger console. Build and run your app, and when you see the SIGABRT crash, copy everything that got printed there and post it here.This is the link to the Xcode overview:https://developer.apple.com/library/prerelease/ios/documentation/ToolsLanguages/Conceptual/Xcode_Overview/index.html#//apple_ref/doc/uid/TP40010215
Sep ’15
Reply to Generating JWK from EC public key x and y coordinates
Yes here are the base64 URL encoded x and y coords that did work (this is the ONLY one that worked) x: LWUQoWBjj4yHpPcOiawHF3745LRk6s8p4pMGJ9ss y: KWY7lHhDCfzl3C70az9RNxHPty3TuLqA1FIptcQJ0g ==================================== Here is a key that does NOT work. (lldb) po publicKey <SecKeyRef curve type: kSecECCurveSecp256r1, algorithm id: 3, key type: ECPublicKey, version: 4, block size: 256 bits, y: 9FA590CFBB8C90800B80B339C6B88036CE555CACBFD90EF58DEB6823A3F3A239, x: 11403670547D66B189A336E4C187B206B6EB1B7A780A11C142EFEC59E9B6B203, addr: 0x7fa4a680fd60> (lldb) po keyData <04114036 70547d66 b189a336 e4c187b2 06b6eb1b 7a780a11 c142efec 59e9b6b2 039fa590 cfbb8c90 800b80b3 39c6b880 36ce555c acbfd90e f58deb68 23a3f3a2 39> (lldb) po xData <11403670 547d66b1 89a336e4 c187b206 b6eb1b7a 780a11c1 42efec59 e9b6b203> (lldb) po yData <9fa590cf bb8c9080 0b80b339 c6b88036 ce555cac bfd90ef5 8deb6823 a3f3a239> (lldb) po xbytes EUA2cFR9ZrGJozbkwYeyBrbrG3p4ChH
Topic: Privacy & Security SubTopic: General Tags:
Jun ’20
Problem when trying to debug with lldb on new arm64 M1
Hi everybody, I’m the maintainer of GNU Prolog (gprolog). I try to port it to the new arm64/darwin apple architecture since a contributor gave me an ssh access to its machine (I can thus only execute commands via command-line bash). I can compile gprolog (it uses a classical unix-style procedure ./configure + make using gcc (clang)). The machine is pretty fast ! However, at run-time I obtain a segmentation violation which I’d like to debug using lldb. I initially obtained this error: error: process exited with status -1 (developer mode is not enabled on this machine and this is a non-interactive debug session.) I asked the owner of the machine to enable the developer mode. But now I obtain: error: process exited with status -1 (this is a non-interactive debug session, cannot get permission to debug processes.) I saw several posts mentioning entitlements (I’m sorry I’m not an expert of Mac). Here is what I obtain with my executable (I created a simple test case executable called ./t): codesign -d -vvv
4
0
10k
Apr ’21
process exiting with SIGSEGV(-11) under lldb on M1 Ultra opens Problem Report instead of returning to the debugger
I've jumped through a couple of unexpected hoops to get here, following some suggestions online: I've used DevToolsSecurity -enalble, and I've used dseditgroup -o edit -a me -t user _developer to put myself in the _developer group. That has at least got lldb past the process exited with status -1 (developer mode is not enabled on this machine and this is a non-interactive debug session.) problem. I'm also running through VNC, rather than ssh, so that I can see pop-ups and new windows, but my preference is for ssh. The crash that I'm trying to debug is in some numpy function in a python program that is spawning multiple threads, so it's relatively hairy, but my past experience has been that running code under lldb results in return to lldb when the program segfaults, but with this code, on this machine, lldb just unhelpfully says that the workers exited with SIGSEGV(-11) and the Problem Report screen pops up to send the results to Apple. I don't want or expect Apple
0
0
1.4k
Sep ’22
Reply to lldb-rpc-server 'hangs' MacOS app won't start with debugger attached
First I was mislead about a possible entitlements/hardening conflict imposed by app store notification. command tools I used to get more info: stream log | fgrep debug lldb yielded error: QtDBus {0x0000000b}: invalid abbreviation code 1, please file a bug and attach the file at the start of this error message then I removed the QtDBus framework, then lldb would continue but fail in the load step of cocoa plugin. This was pointing to a Qt problem, I updated from Qt5.15.0 to Qt5.15.2 on this machine, then the Qt apps could be debugged again with lldb
Jan ’21
Reply to crash report _NSThreadPerformPerform
ahhh, I see. To others reading this, I found the underlying text based .crash file by doing this:(1) from the XCode Organizer, Ctrl-click on the crash report and select Show in Finder(2) This takes you to a package file with a .xccrashpoint file extension(3) Ctrl-click on the file and select Show package contents(4) drill down through the folders and you will see a file with a .crash file extension, which you can view in TextEdit or any text editorIt indeed shows the ARM Thread State, as well as the Binary Images.In my little test app based on your crashing test code, I was able to successfully reproduce printing out the string pointed to by the x1 register. In my case the x1 register in the thread state showed thisx1: 0x0000000100012d25and the Binary Image of the executable shows this:Binary Images:0x10000c000 - 0x100013fff .../testCrashReportSo the offset is presumably 0x10000c000 - 0x100000000 = 0xc000. But when I print out the contents, it's still 8 bytes off for some s
Nov ’16
Reply to LLDB RPC server has crashed
Bugreport: 27017065Presumably this bug keeps Playground from displaying the results via Debug Area.UPDATE: I cannot be 100% sure that missing any output from Playground is stricktly related with LLDB RPC server failure. The server seems to restart automatically when terminated, however, this restart does not affect the Playground to produce the output again...UPDATE 2: I have submitted another bugreport 27018553 specifically related to Playground not producing the QuickLook and Debug outputs. I believe this is because some REPL failure (is it the same as LLDB RPC server or backed by it?). I also cannot confirm that LLDB RPC server failure is direcly related to Playground not producing any output, because even though the LLDB RPC server is restarted, Playground still does not produce outputs.
Jun ’16