Debugger and computed properties = crash?

General
1

This is something I’ve seen on and off for years but now it’s causing some problems so I thought I’d ask.

I like computed properties and use them occasionally. When I view certain objects in the debugger, the app crashes (not Xojo).

I think it’s due to computed properties and their need to run code when viewed in the debugger.

The problem is that I can’t a) determine which property (or behavior in the property) is the problem and b) I can’t filter for viewing in the debugger by using a pragma like #debugbuild because that’ll kill the behavior for the whole build, not just viewing in the debugger.

the crash report suggests an unhanded nil-object exception but I don’t get those in my app normally so is it in Xojo?

help…

2

you can put a breakpoint in your computed property and it will hit that if the debugger calls it to get the value

that might be instructive

3

Everybody gets those eventually. When your app “broke” it should have shown you the line containing your Nil Object

You already answered that yourself.

4

OK, I put breakpoints in each computed property in the class, its super class and its super class…

Still crashed. No sign of nil obj in crash report just a “Exception Type: EXC_BAD_ACCESS (SIGSEGV)”

Any other suggestions?

It’s a particular class that I know I can’t look at in the debugger, so it seems like I should be able to isolate it. It’s just I can’t figure out how.

5

You’re giving conflicting info so I’m a bit lost.

Why not? Is it a third-party encrypted class? In that case, I’d contact the 3rd party vendor.

6

Sorry, confusion not intended.

I mean that this time around (with breakpoints in place) it doesn’t show up as a nil obj error - but nothing else is different (crash occurs in came class instance)

I can’t look at it because of the crash I’m referring to. The debugger works normally for all other classes but as soon as I link into an instance of the class, the app crashes.

7

Comment out the code in each computed property, one at a time, until you no longer get the exception. Then examine the last one you commented out. Maybe post the code here.

8

Put a breakpoint before the crash occurs and then step through until you get the crash to pinpoint where it is occurring.

9

[quote=129617:@Steve Upton]OK, I put breakpoints in each computed property in the class, its super class and its super class…

Still crashed. No sign of nil obj in crash report just a “Exception Type: EXC_BAD_ACCESS (SIGSEGV)”

Any other suggestions?

It’s a particular class that I know I can’t look at in the debugger, so it seems like I should be able to isolate it. It’s just I can’t figure out how.[/quote]

Put the crash report on pastebin (or something similar) or file a bug report with a project, steps to reproduce, and the crash report.

10

OK, thanks for your help so far. I’m working on a simplified version of my code that exhibits the same problem but it’s tough.

Along the way I’ve learned a few things:

  1. The class that crashes the app, when viewed in the debugger, is a subclass of a subclass. If I strip it down to nothing; no properties, no constructor or other methods, nothing - it still crashes the app.

  2. If I move one level up and create an instance of the subclass, I can view it fine in the debugger.

So in other words, a naked subclass (of a subclass) kills the app in debugging.

I created a new sub/sub-class from scratch - same problem. (in case there was something I couldn’t see in the project that was causing a problem)

Any ideas?

I’ll continue to try to isolate the code to find a failing example I can submit. If I simply create a 3-level subclass in a separate project it’s fine so there’s something else…

11

[quote=129881:@Steve Upton]OK, thanks for your help so far. I’m working on a simplified version of my code that exhibits the same problem but it’s tough.

Along the way I’ve learned a few things:

  1. The class that crashes the app, when viewed in the debugger, is a subclass of a subclass. If I strip it down to nothing; no properties, no constructor or other methods, nothing - it still crashes the app.

  2. If I move one level up and create an instance of the subclass, I can view it fine in the debugger.

So in other words, a naked subclass (of a subclass) kills the app in debugging.

I created a new sub/sub-class from scratch - same problem. (in case there was something I couldn’t see in the project that was causing a problem)

Any ideas?

I’ll continue to try to isolate the code to find a failing example I can submit. If I simply create a 3-level subclass in a separate project it’s fine so there’s something else…[/quote]

Why not post the crashing project so others can take a peek at it ?

12

It’s huge, it’s quite complicated, and it’s quite proprietary.

Would if I could…

13

[quote=129884:@Steve Upton]It’s huge, it’s quite complicated, and it’s quite proprietary.

Would if I could…[/quote]

Can’t you just keep your class in a class thingy that crashes ? BTW, even without posting it, just moving that part of your very big proprietary program into a smaller project may allow you to find the needle that a huge haystack makes so difficult to locate…