Break on assert


Carl Hoefs
 

How can I break in Xcode on this assert? Breaking on 'all exceptions' and 'runtime exceptions' doesn't catch it. There's no 'Break on assertions' option...

[Assert] Cannot be called with asCopy = NO on non-main thread.

-Carl


Steve Mills
 

On Oct 31, 2020, at 15:59, Carl Hoefs <newslists@...> wrote:

How can I break in Xcode on this assert? Breaking on 'all exceptions' and 'runtime exceptions' doesn't catch it. There's no 'Break on assertions' option...

[Assert] Cannot be called with asCopy = NO on non-main thread.

Try adding a symbolic breakpoint on NSAssert, Assert, or whatever else you think might be the actual symbol name.

Steve via iPad


Carl Hoefs
 

I've tried all the incantations I can think of, including those you suggest along with -[NSException raise]. (This is an iOS app, if it matters any...)

-Carl

On Oct 31, 2020, at 2:08 PM, Steve Mills via groups.io <sjmills@...> wrote:

On Oct 31, 2020, at 15:59, Carl Hoefs <newslists@...> wrote:

How can I break in Xcode on this assert? Breaking on 'all exceptions' and 'runtime exceptions' doesn't catch it. There's no 'Break on assertions' option...

[Assert] Cannot be called with asCopy = NO on non-main thread.

Try adding a symbolic breakpoint on NSAssert, Assert, or whatever else you think might be the actual symbol name.

Steve via iPad



Steve Mills
 

On Oct 31, 2020, at 16:15, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

I've tried all the incantations I can think of, including those you suggest along with -[NSException raise]. (This is an iOS app, if it matters any...)
How about NSLog, log, print, um, there are a bunch of lower level ones I can’t think of. slog? logv? Or whatever the newer system logging stuff is?

Steve via iPad


Carl Hoefs
 

If I break on those, it would never finish. Surely there's a way to break on an assertion?

-Carl

On Oct 31, 2020, at 2:18 PM, Steve Mills via groups.io <sjmills=mac.com@groups.io> wrote:

On Oct 31, 2020, at 16:15, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

I've tried all the incantations I can think of, including those you suggest along with -[NSException raise]. (This is an iOS app, if it matters any...)
How about NSLog, log, print, um, there are a bunch of lower level ones I can’t think of. slog? logv? Or whatever the newer system logging stuff is?

Steve via iPad






Alex Zavatone
 

If it’s in Objective-C, add a symbolic breakpoint and then this.

-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:]

You could also add a symbolic breakpoint for the condition of “On Throw”.

So, it would trigger when an exception is thrown.

Alex Zavatone


On Oct 31, 2020, at 3:59 PM, Carl Hoefs <newslists@...> wrote:

Break on assertions'


Alex Zavatone
 

If this is in a release build, you might also want to log it or rucn off the assert flags for release builds.

There are some good old notes up on SO from Xcode 4 days.

Alex Zavatone




On Oct 31, 2020, at 3:59 PM, Carl Hoefs <newslists@...> wrote:

Break on assertions'


Carl Hoefs
 

I've added those; still no break. 

This isn't a release build, and there's no explicit assertions in the ObjC code. I assumed that the [Assert] was being raised from the iOS runtime.

-Carl


On Oct 31, 2020, at 2:21 PM, Alex Zavatone via groups.io <zav@...> wrote:

If it’s in Objective-C, add a symbolic breakpoint and then this.

-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:]

You could also add a symbolic breakpoint for the condition of “On Throw”.

So, it would trigger when an exception is thrown.

Alex Zavatone


On Oct 31, 2020, at 3:59 PM, Carl Hoefs <newslists@...> wrote:

Break on assertions'



Alex Zavatone
 

To test these out, cause an assertion after your app launches.

Symbolic breakpoints are really easy to screw up.

If you want to email me directly, I have time to help you on this.



On Oct 31, 2020, at 4:27 PM, Carl Hoefs <newslists@...> wrote:

I've added those; still no break. 

This isn't a release build, and there's no explicit assertions in the ObjC code. I assumed that the [Assert] was being raised from the iOS runtime.

-Carl


On Oct 31, 2020, at 2:21 PM, Alex Zavatone via groups.io <zav@...> wrote:

If it’s in Objective-C, add a symbolic breakpoint and then this.

-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:]

You could also add a symbolic breakpoint for the condition of “On Throw”.

So, it would trigger when an exception is thrown.

Alex Zavatone


On Oct 31, 2020, at 3:59 PM, Carl Hoefs <newslists@...> wrote:

Break on assertions'




Alex Zavatone
 

These should help.

https://developer.apple.com/documentation/swift/1541112-assert

https://www.hackingwithswift.com/read/18/3/debugging-with-assert



On Oct 31, 2020, at 4:27 PM, Carl Hoefs <newslists@...> wrote:

I've added those; still no break. 

This isn't a release build, and there's no explicit assertions in the ObjC code. I assumed that the [Assert] was being raised from the iOS runtime.

-Carl


On Oct 31, 2020, at 2:21 PM, Alex Zavatone via groups.io <zav@...> wrote:

If it’s in Objective-C, add a symbolic breakpoint and then this.

-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:]

You could also add a symbolic breakpoint for the condition of “On Throw”.

So, it would trigger when an exception is thrown.

Alex Zavatone


On Oct 31, 2020, at 3:59 PM, Carl Hoefs <newslists@...> wrote:

Break on assertions'




David Brittain
 

Try setting the Main Threader checker option in the Scheme, The issue
is likely you are calling uikit from outside the main thread, If so,
the Main thread checker will log that for you.

On Sat, 31 Oct 2020 at 14:33, Alex Zavatone via groups.io
<zav=mac.com@groups.io> wrote:

To test these out, cause an assertion after your app launches.

Symbolic breakpoints are really easy to screw up.

If you want to email me directly, I have time to help you on this.



On Oct 31, 2020, at 4:27 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

I've added those; still no break.

This isn't a release build, and there's no explicit assertions in the ObjC code. I assumed that the [Assert] was being raised from the iOS runtime.

-Carl


On Oct 31, 2020, at 2:21 PM, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

If it’s in Objective-C, add a symbolic breakpoint and then this.

-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:]

You could also add a symbolic breakpoint for the condition of “On Throw”.

So, it would trigger when an exception is thrown.

Alex Zavatone


On Oct 31, 2020, at 3:59 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Break on assertions'






--
David Brittain
david@paperetto.com


Alex Zavatone
 



On Oct 31, 2020, at 4:35 PM, David Brittain <websites@...> wrote:

Try setting the Main Threader checker option in the Scheme, The issue
is likely you are calling uikit from outside the main thread, If so,
the Main thread checker will log that for you.

On Sat, 31 Oct 2020 at 14:33, Alex Zavatone via groups.io
<zav@...> wrote:

To test these out, cause an assertion after your app launches.

Symbolic breakpoints are really easy to screw up.

If you want to email me directly, I have time to help you on this.



On Oct 31, 2020, at 4:27 PM, Carl Hoefs <newslists@...> wrote:

I've added those; still no break.

This isn't a release build, and there's no explicit assertions in the ObjC code. I assumed that the [Assert] was being raised from the iOS runtime.

-Carl


On Oct 31, 2020, at 2:21 PM, Alex Zavatone via groups.io <zav@...> wrote:

If it’s in Objective-C, add a symbolic breakpoint and then this.

-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:]

You could also add a symbolic breakpoint for the condition of “On Throw”.

So, it would trigger when an exception is thrown.

Alex Zavatone


On Oct 31, 2020, at 3:59 PM, Carl Hoefs <newslists@...> wrote:

Break on assertions'








--
David Brittain
david@...







Carl Hoefs
 

Yes, Main Thread Checker is already checked. I assume that's what's generating the assert messages? Where does it log addt'l info to?

-Carl


On Oct 31, 2020, at 2:35 PM, David Brittain <websites@...> wrote:

Try setting the Main Threader checker option in the Scheme, The issue
is likely you are calling uikit from outside the main thread, If so,
the Main thread checker will log that for you.

On Sat, 31 Oct 2020 at 14:33, Alex Zavatone via groups.io
<zav@...> wrote:

To test these out, cause an assertion after your app launches.

Symbolic breakpoints are really easy to screw up.

If you want to email me directly, I have time to help you on this.



On Oct 31, 2020, at 4:27 PM, Carl Hoefs <newslists@...> wrote:

I've added those; still no break.

This isn't a release build, and there's no explicit assertions in the ObjC code. I assumed that the [Assert] was being raised from the iOS runtime.

-Carl


On Oct 31, 2020, at 2:21 PM, Alex Zavatone via groups.io <zav@...> wrote:

If it’s in Objective-C, add a symbolic breakpoint and then this.

-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:]

You could also add a symbolic breakpoint for the condition of “On Throw”.

So, it would trigger when an exception is thrown.

Alex Zavatone


On Oct 31, 2020, at 3:59 PM, Carl Hoefs <newslists@...> wrote:

Break on assertions'








-- 
David Brittain
david@...




Steve Mills
 

On Oct 31, 2020, at 16:18, Steve Mills <sjmills@mac.com> wrote:



On Oct 31, 2020, at 16:15, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

I've tried all the incantations I can think of, including those you suggest along with -[NSException raise]. (This is an iOS app, if it matters any...)
How about NSLog, log, print, um, there are a bunch of lower level ones I can’t think of. slog? logv? Or whatever the newer system logging stuff is?
You can set a symbolic breakpoint on print or whatever, then turn on the Don’t Stop checkbox or whatever it’s called, then add an action to print the stack to the log. The last stack logged before the assert would be the one you want, right?

Steve via iPad


Carl Hoefs
 

It's the 'whatever' that I'm having trouble with! I did try 'print' and NSLog, but it didn't break there either...

-Carl

On Oct 31, 2020, at 2:39 PM, Steve Mills via groups.io <sjmills=mac.com@groups.io> wrote:

On Oct 31, 2020, at 16:18, Steve Mills <sjmills@mac.com> wrote:



On Oct 31, 2020, at 16:15, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

I've tried all the incantations I can think of, including those you suggest along with -[NSException raise]. (This is an iOS app, if it matters any...)
How about NSLog, log, print, um, there are a bunch of lower level ones I can’t think of. slog? logv? Or whatever the newer system logging stuff is?
You can set a symbolic breakpoint on print or whatever, then turn on the Don’t Stop checkbox or whatever it’s called, then add an action to print the stack to the log. The last stack logged before the assert would be the one you want, right?

Steve via iPad






Alex Zavatone
 

Whatever should be explained in the links I sent you.

On Oct 31, 2020, at 4:42 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

It's the 'whatever' that I'm having trouble with! I did try 'print' and NSLog, but it didn't break there either...

-Carl


On Oct 31, 2020, at 2:39 PM, Steve Mills via groups.io <sjmills=mac.com@groups.io> wrote:

On Oct 31, 2020, at 16:18, Steve Mills <sjmills@mac.com> wrote:



On Oct 31, 2020, at 16:15, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

I've tried all the incantations I can think of, including those you suggest along with -[NSException raise]. (This is an iOS app, if it matters any...)
How about NSLog, log, print, um, there are a bunch of lower level ones I can’t think of. slog? logv? Or whatever the newer system logging stuff is?
You can set a symbolic breakpoint on print or whatever, then turn on the Don’t Stop checkbox or whatever it’s called, then add an action to print the stack to the log. The last stack logged before the assert would be the one you want, right?

Steve via iPad










David Brittain
 

Where does it log addt'l info to?
It should log to the console too.

On Sat, 31 Oct 2020 at 14:46, Alex Zavatone via groups.io
<zav=mac.com@groups.io> wrote:

Whatever should be explained in the links I sent you.

On Oct 31, 2020, at 4:42 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

It's the 'whatever' that I'm having trouble with! I did try 'print' and NSLog, but it didn't break there either...

-Carl


On Oct 31, 2020, at 2:39 PM, Steve Mills via groups.io <sjmills=mac.com@groups.io> wrote:

On Oct 31, 2020, at 16:18, Steve Mills <sjmills@mac.com> wrote:



On Oct 31, 2020, at 16:15, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

I've tried all the incantations I can think of, including those you suggest along with -[NSException raise]. (This is an iOS app, if it matters any...)
How about NSLog, log, print, um, there are a bunch of lower level ones I can’t think of. slog? logv? Or whatever the newer system logging stuff is?
You can set a symbolic breakpoint on print or whatever, then turn on the Don’t Stop checkbox or whatever it’s called, then add an action to print the stack to the log. The last stack logged before the assert would be the one you want, right?

Steve via iPad














--
David Brittain
david@paperetto.com


Carl Hoefs
 

Those appear to be Swift-specific. Nevertheless I tried breaking at assert, assertionFailure, precondition, preconditionFailure, fatalError, etc. No break.

-Carl


On Oct 31, 2020, at 2:46 PM, Alex Zavatone via groups.io <zav@...> wrote:

Whatever should be explained in the links I sent you.

On Oct 31, 2020, at 4:42 PM, Carl Hoefs <newslists@...> wrote:

It's the 'whatever' that I'm having trouble with! I did try 'print' and NSLog, but it didn't break there either...

-Carl


On Oct 31, 2020, at 2:39 PM, Steve Mills via groups.io <sjmills@...> wrote:

On Oct 31, 2020, at 16:18, Steve Mills <sjmills@...> wrote:



On Oct 31, 2020, at 16:15, Carl Hoefs <newslists@...> wrote:

I've tried all the incantations I can think of, including those you suggest along with -[NSException raise]. (This is an iOS app, if it matters any...)

How about NSLog, log, print, um, there are a bunch of lower level ones I can’t think of. slog? logv? Or whatever the newer system logging stuff is?

You can set a symbolic breakpoint on print or whatever, then turn on the Don’t Stop checkbox or whatever it’s called, then add an action to print the stack to the log. The last stack logged before the assert would be the one you want, right?

Steve via iPad




















Steve Mills
 

What about not running from Xcode? Just launch it on the device and make it assert, then you should get a real crash log and stack crawl, right?

Steve via iPad


James Walker
 

On Oct 31, 2020, at 2:38 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Yes, Main Thread Checker is already checked. I assume that's what's generating the assert messages? Where does it log addt'l info to?
Besides checking Main Thread Checker in the scheme, look at your breakpoint navigator and make sure there is a breakpoint “Main Thread Checker (Runtime Issue)” that’s enabled, or perhaps an “All Runtime Issues” breakpoint.


-Carl


On Oct 31, 2020, at 2:35 PM, David Brittain <websites@paperetto.com> wrote:

Try setting the Main Threader checker option in the Scheme, The issue
is likely you are calling uikit from outside the main thread, If so,
the Main thread checker will log that for you.

On Sat, 31 Oct 2020 at 14:33, Alex Zavatone via groups.io
<zav=mac.com@groups.io> wrote:

To test these out, cause an assertion after your app launches.

Symbolic breakpoints are really easy to screw up.

If you want to email me directly, I have time to help you on this.



On Oct 31, 2020, at 4:27 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

I've added those; still no break.

This isn't a release build, and there's no explicit assertions in the ObjC code. I assumed that the [Assert] was being raised from the iOS runtime.

-Carl


On Oct 31, 2020, at 2:21 PM, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

If it’s in Objective-C, add a symbolic breakpoint and then this.

-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:]

You could also add a symbolic breakpoint for the condition of “On Throw”.

So, it would trigger when an exception is thrown.

Alex Zavatone


On Oct 31, 2020, at 3:59 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Break on assertions'






--
David Brittain
david@paperetto.com