Re: Xcode call stack

[Alex Zavatone]

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 "only 
>>> change the UI from the main thread". Okay, got it. But what's with all the 
>>>  stuff in the call traceback? It make it essentially useless.
>> 
>> Where did you get the backtrace from? Usually when there are no real symbol 
>> names, it means the app has had debug symbols stripped out and there’s no 
>> dSYM file available to provide symbol names.
>> 
> 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 generates this 
> backtrace in the bottom console log output area. 

OK, that's freaking strange.

> How does one build to explicitly include debug symbolication info?

Check your build settings and make sure that you are looking at All, not Basic.

Then search for this magical phrase: Strip Debug Symbols During Copy

Expand that.  Set lots of them to NO.

Run your same test.  

Lemmie know if that saves the universe form the forces of evil, or leaves you 
out alone in the snow.

Cheers.


> -Carl
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list  (Xcode-users@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/zav%40mac.com
> 
> This email sent to z...@mac.com

 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode call stack

[Alex Zavatone]

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 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:
>>> 
>>> 
 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 the UI from the main thread". Okay, got it. But what's with all 
> the  stuff in the call traceback? It make it essentially 
> useless.
 
 Where did you get the backtrace from? Usually when there are no real 
 symbol names, it means the app has had debug symbols stripped out and 
 there’s no dSYM file available to provide symbol names.
 
>>> 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 generates 
>>> this backtrace in the bottom console log output area. 
>>> 
>>> How does one build to explicitly include debug symbolication info?
>> 
>> Okay, in Xcode I see the following relevant build settings:
>> 
>> - Strip Debug Symbols During Copy
>> - Strip Linked Product
>> 
>> I'll set them both to NO.
>> -Carl
>> 
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Xcode-users mailing list  (Xcode-users@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/xcode-users/jingham%40apple.com
>> 
>> This email sent to jing...@apple.com
> 
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list  (Xcode-users@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/zav%40mac.com
> 
> This email sent to z...@mac.com


 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode call stack

[Carl Hoefs]

> 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 the UI from the main thread". Okay, got it. But what's with all the 
>>  stuff in the call traceback? It make it essentially useless.
> 
> Where did you get the backtrace from? Usually when there are no real symbol 
> names, it means the app has had debug symbols stripped out and there’s no 
> dSYM file available to provide symbol names.
> 
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 generates this backtrace in 
the bottom console log output area. 

How does one build to explicitly include debug symbolication info?
-Carl

 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode call stack

[Carl Hoefs]

> 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 >> > 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 
>>>  stuff in the call traceback? It make it essentially useless.
>> 
>> Where did you get the backtrace from? Usually when there are no real symbol 
>> names, it means the app has had debug symbols stripped out and there’s no 
>> dSYM file available to provide symbol names.
>> 
> 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 generates this 
> backtrace in the bottom console log output area. 
> 
> How does one build to explicitly include debug symbolication info?

Okay, in Xcode I see the following relevant build settings:

- Strip Debug Symbols During Copy
- Strip Linked Product

I'll set them both to NO.
-Carl


 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode call stack

[Jim Ingham]

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:
>> 
>> 
>>> 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 the UI from the main thread". Okay, got it. But what's with all the 
  stuff in the call traceback? It make it essentially useless.
>>> 
>>> Where did you get the backtrace from? Usually when there are no real symbol 
>>> names, it means the app has had debug symbols stripped out and there’s no 
>>> dSYM file available to provide symbol names.
>>> 
>> 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 generates this 
>> backtrace in the bottom console log output area. 
>> 
>> How does one build to explicitly include debug symbolication info?
> 
> Okay, in Xcode I see the following relevant build settings:
> 
> - Strip Debug Symbols During Copy
> - Strip Linked Product
> 
> I'll set them both to NO.
> -Carl
> 
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list  (Xcode-users@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/jingham%40apple.com
> 
> This email sent to jing...@apple.com


 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

How to use the ALTERNATE_PERMISSIONS_FILES build setting?

[Bill Cheeseman]

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 framework header files 
should have permissions 644, as Apple's do, because headers are not executable, 
and that makes sense to me.

But I can't figure out how to configure the Xcode build settings for my own 
framework to accomplish this. I set the Deployment build setting ALTERNATE_MODE 
(Alternate Install Permissions) to u+w,go-w,a+r, instead of the default 
u+w,go-w,a+rX. But I haven't found a workable way to set the 
ALTERNATE_PERMISSIONS_FILES (Alternate Permissions Files) setting. This setting 
is supposed to contain the paths to the framework header files, but every way I 
have tried to construct the paths either accomplishes nothing or causes the 
build to fail because the header files aren't found.

Can anybody explain how to set ALTERNATE_PERMISSIONS_FILES to accomplish my 
goal?

(I assume I can fall back on a run script build phase calling CHMOD -- right? 
But I would like to know how to use the ALTERNATE_PERMISSIONS_FILES build 
setting, which seems to be designed specifically to do this sort of thing.)



 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode call stack

[Alex Zavatone]

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 
>>  stuff in the call traceback? It make it essentially useless.
> 
> Where did you get the backtrace from? Usually when there are no real symbol 
> names, it means the app has had debug symbols stripped out and there’s no 
> dSYM file available to provide symbol names.
> 
> —Jens

Yeah, there's a Strip Debug Symbols build setting that you can turn off.

If you have this from an app's log report, the Mac that you used to build that 
app still has the debug symbols and you can symbolicate to get them back and 
see what the methods really were.

That's what I was asking about in my previous email.  If that's the case, I can 
show you how to do that.

Let us know.

- Alex Zavatone
> ___
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list  (Xcode-users@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/zav%40mac.com
> 
> This email sent to z...@mac.com

 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode call stack

[Jim Ingham]

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 issue on OS X, 
but iOS is a more memory constrained device.  So as an optimization, the 
strings for the names of all the "private_extern" symbols were removed from the 
part of the shared cache that's mapped into memory, and replaced with a single 
string "redacted".  Since the actual symbol record holds a pointer to the name 
string, this shrunk the shared cache's memory footprint quite a bit.  And since 
you can't use the name of an unexported symbol, it doesn't affect how programs 
run.

The strings are all still on the system, and lldb/ instruments/ 
CoreSymbolication know how to find them, but since they aren't mapped into 
memory, they aren't available when running in process.  This log is most likely 
from the "backtrace" system call in the app, which just looks through the 
symbol name pointer, and finds "redacted".

Jim 

> On Aug 25, 2016, at 12:35 PM, Alex Zavatone  wrote:
> 
> 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 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:
 
 
> 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 the UI from the main thread". Okay, got it. But what's with all 
>> the  stuff in the call traceback? It make it essentially 
>> useless.
> 
> Where did you get the backtrace from? Usually when there are no real 
> symbol names, it means the app has had debug symbols stripped out and 
> there’s no dSYM file available to provide symbol names.
> 
 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 generates 
 this backtrace in the bottom console log output area. 
 
 How does one build to explicitly include debug symbolication info?
>>> 
>>> Okay, in Xcode I see the following relevant build settings:
>>> 
>>> - Strip Debug Symbols During Copy
>>> - Strip Linked Product
>>> 
>>> I'll set them both to NO.
>>> -Carl
>>> 
>>> 
>>> ___
>>> Do not post admin requests to the list. They will be ignored.
>>> Xcode-users mailing list  (Xcode-users@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/xcode-users/jingham%40apple.com
>>> 
>>> This email sent to jing...@apple.com
>> 
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Xcode-users mailing list  (Xcode-users@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/xcode-users/zav%40mac.com
>> 
>> This email sent to z...@mac.com
> 


 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode call stack

[Jim Ingham]

> 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 generates this 
>> backtrace in the bottom console log output area. 
> 
> OK, that's freaking strange.
> 
> 

I agree with Alex.  If you can reproduce this in something you can put in a bug 
report, please file a bug and I'll take a whack at fixing it.

Jim


 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode call stack

[Jim Ingham]

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.  But re-reading, 
it's quite likely that he really meant "I see no reason why this code should be 
throwing exceptions".

To help with that issue we'll have to first finish the task of reading the 
actual exception object from the throw point, and providing some way to say 
"don't stop for exceptions of kind X."  Then you'll at least be able to pass by 
exceptions you don't care about.  We have radars requesting that already, BTW...

Jim  


> On Aug 25, 2016, at 1:17 PM, Quincey Morris 
>  wrote:
> 
> 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" breakpoint disabled (otherwise it 
 would break in some thread for "apparently no reason"). Xcode generates 
 this backtrace in the bottom console log output area. 
>>> 
>>> OK, that's freaking strange.
>>> 
>>> 
>> 
>> I agree with Alex.  If you can reproduce this in something you can put in a 
>> bug report, please file a bug and I'll take a whack at fixing it.
> 
> This is almost certain the known “issue” with frameworks that use exceptions 
> for flow control instead of as crashes. This happens in several 
> Apple-provided frameworks that are written in C++, because in C++ using 
> exceptions for flow control is a normal pattern**.
> 
> It *occasionally* happens in 3rd party frameworks written in Obj-C that don’t 
> follow the rules for handling exceptions as crashes.
> 
> You can mitigate the first case by turning off only C++ exceptions. If you 
> run into the second case, there’s no really good solution.
> 
> 
> 
> ** That said, it may be that Apple has tried to eliminate these cases in the 
> last couple of years, so it may be worth bug-reporting anyway. If nothing 
> else, it shines some light on the problem.
> 


 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode call stack

[Carl Hoefs]

> 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 appropriate 
> stop reason in the lldb stop output or the in Xcode's pc ribbon.  But 
> re-reading, it's quite likely that he really meant "I see no reason why this 
> code should be throwing exceptions".

No worries, I simply didn't understand why Xcode was breaking where it did. No 
program-related information was given in the call stack, so it took me a lot of 
time to track down what was causing it. The bug was difficult to reproduce 
because it happened only under certain tortured conditions (within a BTLE 
peripheral delegate callback method in which I would present a UIAlert on an 
intermittent write failure. Can't do that there; all is well now).

Thanks for all the very interesting info!
-Carl


 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode call stack

[Jim Ingham]

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 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 the UI from the main thread". Okay, got it. But what's with all the 
>>>  stuff in the call traceback? It make it essentially useless.
>> 
>> Where did you get the backtrace from? Usually when there are no real symbol 
>> names, it means the app has had debug symbols stripped out and there’s no 
>> dSYM file available to provide symbol names.
>> 
> 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 generates this 
> backtrace in the bottom console log output area. 
> 
> How does one build to explicitly include debug symbolication info?
> -Carl
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list  (Xcode-users@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/jingham%40apple.com
> 
> This email sent to jing...@apple.com


 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode call stack

[Quincey Morris]

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" breakpoint disabled (otherwise it 
>>> would break in some thread for "apparently no reason"). Xcode generates 
>>> this backtrace in the bottom console log output area. 
>> 
>> OK, that's freaking strange.
>> 
>> 
> 
> I agree with Alex.  If you can reproduce this in something you can put in a 
> bug report, please file a bug and I'll take a whack at fixing it.

This is almost certain the known “issue” with frameworks that use exceptions 
for flow control instead of as crashes. This happens in several Apple-provided 
frameworks that are written in C++, because in C++ using exceptions for flow 
control is a normal pattern**.

It *occasionally* happens in 3rd party frameworks written in Obj-C that don’t 
follow the rules for handling exceptions as crashes.

You can mitigate the first case by turning off only C++ exceptions. If you run 
into the second case, there’s no really good solution.



** That said, it may be that Apple has tried to eliminate these cases in the 
last couple of years, so it may be worth bug-reporting anyway. If nothing else, 
it shines some light on the problem.

 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode call stack

[Alex Zavatone]

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 reason in the lldb stop output or the in Xcode's pc ribbon.  But 
> re-reading, it's quite likely that he really meant "I see no reason why this 
> code should be throwing exceptions".
> 
> To help with that issue we'll have to first finish the task of reading the 
> actual exception object from the throw point, and providing some way to say 
> "don't stop for exceptions of kind X."  Then you'll at least be able to pass 
> by exceptions you don't care about.  We have radars requesting that already, 
> BTW...
> 
> Jim  

You're turning down good beers, Jim.  I'd check your fridge before you make 
such a decision.

And on a completely unrelated note.  THANK ZEUS for Symbolic Breakpoints.  I 
just spent 6 hours tracking down an issue that was obscured by "aggressive 
optimization" in one of the sub libs of an iOS project-o-pain (who needs ARC 
these days?) that caused the debugger to report nil in cases where the value 
WASN'T NIL and caused the program indicator to jump back and forth when 
executing some compiled code within an external lib.

Well, the only way I was able to get to data and methods was by using symbolic 
breakpoints.  When I got to the end of the problem and fixed it, 5 hours later, 
since the debugger and console were providing misleading status on data values 
AND breakpoints were ignored in the external libs, I decided to look into this 
aggressive optimization issue.

Well, there was only one standard optimization set and that was in the Release 
build config of one of the linked libs for fastest, smallest.  Pretty standard 
stuff.

BUT…

Some rocket surgeon has changed the build schemes for this linked lib to use 
the Release configuration from the Run scheme.  And that caused all of the hell 
with a useless debugger. and console.

And the whole write up to the vendor took another hour, so that's a joyous 6+ 
hours on one issue out of a 18 hour day.

At least all the problems I've had with this code since January now have 
disappeared.

Blessed be symbolic breakpoints.  Someone's on my Christmas list for those 
puppies.

Cheers.
- Alex Zavatone
 ___
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list  (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to arch...@mail-archive.com