Re: Xcode call stack

On Aug 25, 2016, at 2:15 PM, Carl Hoefs wrote: > >> On Aug 25, 2016, at 12:04 PM, Jens Alfke wrote: >> >> >>> On Aug 25, 2016, at 11:53 AM, Carl Hoefs >>> wrote: >>> >>> I figured out that the following is Xcode's humorous way of saying

Re: Xcode call stack

Ahhh. Awesome. TY Jim. Could you share why they would be listed as being redacted? Private internal interfaces? Why does Xcode need to redact them in the first place? TY. Learning is half the battle - Gandalf. On Aug 25, 2016, at 2:28 PM, Jim Ingham wrote: > That won't make any

Re: Xcode call stack

> On Aug 25, 2016, at 12:04 PM, Jens Alfke wrote: > > >> On Aug 25, 2016, at 11:53 AM, Carl Hoefs > > wrote: >> >> I figured out that the following is Xcode's humorous way of saying "only >> change

Re: Xcode call stack

> On Aug 25, 2016, at 12:15 PM, Carl Hoefs > wrote: > > >> On Aug 25, 2016, at 12:04 PM, Jens Alfke > > wrote: >> >> >>> On Aug 25, 2016, at 11:53 AM, Carl Hoefs >>

Re: Xcode call stack

That won't make any difference. These are symbols from the system libraries, not from your app. Jim > On Aug 25, 2016, at 12:20 PM, Carl Hoefs > wrote: > >> >> On Aug 25, 2016, at 12:15 PM, Carl Hoefs >> wrote: >> >> >>>

How to use the ALTERNATE_PERMISSIONS_FILES build setting?

Apple's Cocoa framework header files have permissions 644, or u+w,go-w,a+r. All of the third-party framework header files I have ever examined have permissions 755, or u+w,go-w,a+rX, instead -- meaning that the headers are marked as executable. A number of online commentaries say that all

Re: Xcode call stack

On Aug 25, 2016, at 2:04 PM, Jens Alfke wrote: > >> On Aug 25, 2016, at 11:53 AM, Carl Hoefs >> wrote: >> >> I figured out that the following is Xcode's humorous way of saying "only >> change the UI from the main thread". Okay, got it. But what's with all the

Re: Xcode call stack

Right. Historically, OS X included a lot of symbol names for un-exported symbols, because they made backtraces much more useful. Over time many such symbols have accumulated, to the point where they actually constitute a pretty bit chunk of memory mapped into every process. That's not an

Re: Xcode call stack

> On Aug 25, 2016, at 12:31 PM, Alex Zavatone wrote: > >> This occurred while running my iOS app from Xcode, connected to my iPhone. >> In Xcode I have the "All Exceptions" breakpoint disabled (otherwise it would >> break in some thread for "apparently no reason"). Xcode

Re: Xcode call stack

Ah, maybe I was taking Carl's "apparently no reason" referencing lldb when he meant no apparent reason in the debugee. I was concerned that he was seeing the C++ exception breakpoint causing stops that didn't have an appropriate stop reason in the lldb stop output or the in Xcode's pc ribbon.

Re: Xcode call stack

> On Aug 25, 2016, at 3:02 PM, Jim Ingham wrote: > > Ah, maybe I was taking Carl's "apparently no reason" referencing lldb when he > meant no apparent reason in the debugee. I was concerned that he was seeing > the C++ exception breakpoint causing stops that didn't have an

Re: Xcode call stack

If you are still in lldb when you see this log, you should be able to just do: (lldb) image lookup -va for all the addresses in the third column to see the correct symbols. Jim > On Aug 25, 2016, at 12:15 PM, Carl Hoefs > wrote: > > >> On Aug 25, 2016, at

Re: Xcode call stack

On Aug 25, 2016, at 12:55 , Jim Ingham wrote: > >> On Aug 25, 2016, at 12:31 PM, Alex Zavatone > > wrote: >> >>> This occurred while running my iOS app from Xcode, connected to my iPhone. >>> In Xcode I have the "All Exceptions"

Re: Xcode call stack

On Aug 25, 2016, at 5:02 PM, Jim Ingham wrote: > Ah, maybe I was taking Carl's "apparently no reason" referencing lldb when he > meant no apparent reason in the debugee. I was concerned that he was seeing > the C++ exception breakpoint causing stops that didn't have an appropriate > stop