“LLDB crash”

I think there is a bug in Xcode. Normally lldb can get symbols from binary with DWARF. dSYM is not required.

Xcode Version 10.1 (10B61)Nothing changed, by lldb command all right, but error sometimes occurs.

fatal error: Failure: file /Users/john/Desktop/CustomCoreML/cats_dogs/ViewController.swift, line 75 (lldb)

On the crash, can you tell what Vision.framework is doing? On my iOS 18.5 (I don't have iPad, but I suppose it's similar, if not same.), the crash point (-[VNCoreMLModel predictWithCVPixelBuffer:options:error:] + 148) is attempting to access .model property of VNCoreMLModel object. (lldb) dis -s 0x00000001bc61626c -e 0x00000001bc61626c+148 Vision`-[VNCoreMLModel predictWithCVPixelBuffer:options:error:]: : ;; x0 is self, which is `VNCoreMLModel` object. 0x1bc616290 <+36>: mov x23, x0 : ;; Accessing `.model` property of the `VNCoreMLModel` object. 0x1bc6162f8 <+140>: mov x0, x23 0x1bc6162fc <+144>: bl 0x1bc857f60 ; objc_msgSend$model ;; Return address 0x1bc616300 <+148>: bl 0x1bdf7d200 If you see the same, I might suspect the MLModel object stored in CoreMLModelContainer is somehow broken, perhaps overreleased. (It's hard to tell whether it's a framework bug or application's bug. )

the way I understand it is that the clipview is the contentview of the scrollview. Calling [scrollView setDocumentView: imageView] produces a warning. setDocumentView wants an NSClipview.The NSClipView does have a documentView so I tried:[self.scrollView.contentView setDocumentView:imageView];which also doesn't work. The image shows up in the scrollview.I have examined each of the objects in the debug output window and everything seems right, except no scrolling.for example:(lldb) po imageView.frame(origin = (x = 0, y = 0), size = (width = 1920, height = 1200))(lldb) po self.scrollView.frame(origin = (x = 62, y = 52), size = (width = 324, height = 209))(lldb) po self.scrollView.contentView.frame(origin = (x = 1, y = 1), size = (width = 322, height = 207))

XCode 10.2.1I am jumping into this thread because it keeps coming up in my DuckDuckGo searches, and because it features the comments of Quinn -- someone who over the years I have come to associate with excellent information. So...Is there any way to have LLDB _NOT_ add all of the child breakpoints? I am getting numerous spurious child breakpoints added to my code, and I have not found any way to prevent this.I have inserted a screenshot from XCode showing a typical such event. I set a breakpoint at line 240, and LLDB has decided to set an additional breakpoint at line 243. I have tried adding dummy code between the various closing braces, but that just moves the problem around. LLDB still insists on breaking at a point that is not in the same flow path as the intentional breakpoint. If, for example, I add dummy code between the @catch closing brace and the method closing brace, the undesired child breakpoint moves to the @catch closing brace.This mostly seems to occur with @try-@cat

That's just how the trap manifests. If you run the code in lldb, you should see it has stopped on the fsqrt instruction that is being passed the negative value.

You've declared john to be of type Person?, which is not a class type even though Person is a class type. Right. Which means the LLDB command you need is: (lldb) language swift refcount john! refcount data: (strong = 4, unowned = 1, weak = 1) Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I'm not sure, but I thought I saw this being done in a WWDC video. Perhaps What's New in lldb, or one of the Swift sessions?

Thank you for your answer: Here some more information: I compiled with -g -o0, but it doesn't look like there is more infromation. I used debugger lldb and it tells the stuff at the end of this mail. hmm.. doesn't like my source. The randomSwap function is sadly pretty large. I can't make it smaller without loosing speed, by speed is very important for timetabling, since it might run many hours to find solutions. Is there an other way how I can debug it? Here the lldb results: vd@Mini-von-Volker fet-6.9.6_BENCHMARK % lldb /Users/vd/Downloads/fet-6.9.6_BENCHMARK/fet.app/Contents/MacOS/fet (lldb) target create /Users/vd/Downloads/fet-6.9.6_BENCHMARK/fet.app/Contents/MacOS/fet Current executable set to '/Users/vd/Downloads/fet-6.9.6_BENCHMARK/fet.app/Contents/MacOS/fet' (arm64). (lldb) r Process 7992 launched: '/Users/vd/Downloads/fet-6.9.6_BENCHMARK/fet.app/Contents/MacOS/fet' (arm64) 2023-10-21 21:19:11.202644+0200 fet[7992:30690] [default] CGSWindowShmemCreateWithP

Does this happen if you run the app in the debugger? If so, please do that and then, when you get stuck, break into the debugger, generate a backtrace of the main thread (see the commands below), and post it here.(lldb) thread select 1 (lldb) bt … the backtrace will show up here …Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com