LLDB crash

The following should answer your question:protocol X { } extension X { func foo() { print(I'm an X foo) } } protocol Y { } extension Y { func foo() { print(I'm a Y foo) } } protocol Z { func foo() } struct Foo: Z, X, Y { }For your conveniece, is the playground output:Playground execution failed: /var/folders/rv/mwcdgk492x7g23_0byfwyjtw0000gn/T/./lldb/1444/playground261.swift:44:8: error: type 'Foo' does not conform to protocol 'Z' struct Foo: Z, X, Y ^ /var/folders/rv/mwcdgk492x7g23_0byfwyjtw0000gn/T/./lldb/1444/playground261.swift:41:10: note: multiple matching functions named 'foo()' with type '() -> ()' func foo() ^ /var/folders/rv/mwcdgk492x7g23_0byfwyjtw0000gn/T/./lldb/1444/playground261.swift:33:10: note: candidate exactly matches func foo() ^ /var/folders/rv/mwcdgk492x7g23_0byfwyjtw0000gn/T/./lldb/1444/playground261.swift:20:10: note: candidate exactly matches func foo() ^

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)

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

I added a category method to UIView called floating to see if I could get any information about the caller or the context. Every time, I get a view with no superview, and a single UILabel subview (textless, unfortunately). (lldb) po self <UIView: 0x7f7fc7f02160; frame = (0 0; 320 10); layer = <CALayer: 0x618000629020>> (lldb) po self.subviews <__NSArrayM 0x618000a44350>( <UILabel: 0x7f7fc7f02810; frame = (10 0; 310 10); opaque = NO; userInteractionEnabled = NO; layer = <_UILabelLayer: 0x618000482940>> ) (lldb) po self.superview 0x0000000000000000I'm getting four calls to this method per UITableViewCell in my table, and it happens regardless of whether I'm in a table with standard or custom UITableView cells. Anyone know what -[UITableViewAccessibility _accessibilitySortedElementsWithin] might be doing with such a view?

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

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. )

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

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

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?

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.

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