Cocoa still not as crash-free as carbon

General
1

Cocoa looks good, however, it crashes on Mac at the same rate as Carbon 3 years ago.
So, IMO carbon is the way to go for large Mac applications.
Cocoa is so much better than it used to be 3 years ago - it was crashing all the time… I’m really looking forward to when it is as crash free as carbon

2

Well, not to be flip, but the frameworks typically don’t just crash randomly and it’s not like they surreptitiously co-opt your webcam, run your mug through facial recognition software, and decide to ruin your day just because.

There’s a reason why you experience every crash. If you could at least get a stack crawl for the crashed thread (easy on Mac) and post it here along with a description of what you’re doing, I bet we could help you isolate it in short order. Then you could submit an actionable report through Feedback or work around your issue.

My own experience is that the Cocoa framework is doing quite well in both 2012r2.1 and Xojo 2013. From beta testing, I know of a few fundamental improvements to the Cocoa framework in 2013r1. So I would guess that you’re doing things a little differently than I am with Cocoa apps if they’re just crashing on you.

3

So what’s it like when you do mean to be flip? :slight_smile:

4

I agree with Brad, if you can share some crash reports maybe we can help figure out what is crashing. I have to say with the apps we’re working on, the main cause of crashing is more to do with my own declares than the Xojo framework.

My last one, was a function that worked fine on 10.6~10.8, but on a future OS version, would kill the app within minutes (eating up the memory along the way). I then discovered an API that does what my function did, but much faster and didn’t leak memory on this unspoken OS version.

5

Same here. I had been using a Cocoa(!) declare for NSAnimation… the ShowPoofs animation when deleting stuff.
Been working fine for years in a Carbon app built with RB2009

Switched to 2012 for Carbon, and Xojo for Cocoa , and now that call kills the app stone dead.
I can live without the API call.

6

Well, I’m not using any api calls - however, I am using the MBS quicktime functions.
I can understand that any simple apps would work wonderfully with cocoa. However, I have a recording window which crashes the app when I go to close the window. This also happened in RB2010v1 and then in a couple of version later, this worked perfectly with no crashes. That’s why I reasoned that when cocoa functions like RB2011, I’ll be extremely happy (besides the fact that noteplayer in cocoa plays at the right volume)!!!

The stack crawl - is that the error message report after the crash?

(PS it never happens in Windows - how ironic is that!)

7

I developp 10 applications which I had to adapt from Carbon to Cocoa. Most of the work was on the Thread because I was wrong, I did bad things Carbon tolerates and Cocoa doesn’t.
But, i had to add some workarround too.
It took me some hard work, but everythings seems fine now.

2 friends of me abandoned Xojo because they didn’t reach, and didn’t take the time, to do the correction they had to do.

I’m a little disappointed because I thought Cocoa build would be very less heavy (Mb) than Carbon. But it’s the same.

8

[quote=41476:@Jeff Tullin]Switched to 2012 for Carbon, and Xojo for Cocoa , and now that call kills the app stone dead.
I can live without the API call.[/quote]
Post the declare and maybe we can help fix it for you.[quote=41487:@Sean Clancy]Well, I’m not using any api calls - however, I am using the MBS quicktime functions.[/quote]
I would suggest making a demo project you can send to Christian as it sounds like the crash may be in his plugin. Once you can reproduce it, he’s really quick to fix it.

9

Heres what I had, from declare sub. (goes back a way…)

[code]CocoaPoofs 1.0 4/17/2007
charles@declareSub.com
www.declareSub.com

This is a class that wraps the Cocoa code for displaying an NSAnimationEffect. Currently, the
single effect is the poof. But Apple has designed the interface so as to allow for the addition
of additional effects, and so we do the same.

NSAnimationEffect has two shared methods.

Sub ShowPoof(left as Integer, top as Integer, width as Integer = 0, height as Integer = 0)
Sub ShowDisappearingItemDefault(left as Integer, top as Integer, width as Integer = 0, height as Integer = 0)
[/code]

[code] Shared Sub ShowPoof(left as Integer, top as Integer, width as Integer = 0, height as Integer = 0)
const NSAnimationEffectPoof = 10

ShowEffect NSAnimationEffectPoof, left, top, width, height
End Sub
[/code]

  [code]      soft declare sub NSShowAnimationEffect lib CocoaLib (animationEffect as Integer, x as Single, y as Single, width as Single, height as Single, animationDelegate as Ptr, didEndSelector as Ptr, contextInfo as Ptr)
  
  NSShowAnimationEffect theEffect, left, Screen(0).Height - top, width, height, nil, nil, nil [/code]

    soft declare function NSSelectorFromString lib CocoaLib (aSelectorName as CFStringRef) as Ptr
    soft declare sub objc_msgSend Lib CocoaLib (theReceiver as Ptr, theSelector as Ptr)
    
    objc_msgSend p, NSSelectorFromString("release")[/code]


 [code]  Private Shared Function NewAutoreleasePool() As Ptr
  #if targetMacOS
    soft declare function NSClassFromString lib CocoaLib (aClassName as CFStringRef) as Ptr
    soft declare function NSSelectorFromString lib CocoaLib (aSelectorName as CFStringRef) as Ptr
    soft declare function objc_msgSend Lib CocoaLib (theReceiver as Ptr, theSelector as Ptr) as Ptr
    
    dim thePool as Ptr = objc_msgSend(NSClassFromString("NSAutoreleasePool"), NSSelectorFromString("alloc"))
    thePool = objc_msgSend(thePool, NSSelectorFromString("init"))
    return thePool
  #endif
End Function

Called like this:

#if targetmacos then NSAnimationEffect.ShowPoof mycanvas.left+(selectedx -topleftx) * nSize1 + 60, mycanvas.top+(selectedy -toplefty) * nSize1 + 60, 100,100 #endif

10

[quote=41487:@Sean Clancy]The stack crawl - is that the error message report after the crash?
[/quote]

Yes. You can also get it from the “Console” app under “User Diagnostic Reports”. If you’re developing software as anything other than to entertainment/therapy for yourself, understanding stack crawls should be highest on your list. Post one here, and we’ll guide you through what it means.

11

[quote=41476:@Jeff Tullin]Same here. I had been using a Cocoa(!) declare for NSAnimation… the ShowPoofs animation when deleting stuff.
Been working fine for years in a Carbon app built with RB2009

Switched to 2012 for Carbon, and Xojo for Cocoa , and now that call kills the app stone dead.
[/quote]

Declares aren’t just magic. If they’re working in Carbon and crashing in Cocoa, it means that you were setting them up correctly in Carbon, and you’re not setting them up correctly in Cocoa. “Setting them up correctly” can mean all sorts of low level things, from correctly initializing a toolkit (or the framework having done so), to having enough stack space, to passing large enough memory blocks, etc.

If you see “bugginess” around declares or plugins, the responsibility starts with the author of the declares or plugins, not Xojo. That’s not to say that Xojo might ultimately be responsible for a particular problem, but the search for whose problem it is starts with the extension developer. Stack crawls on crashes tend to be an excellent first order sort for that responsibility.

12

Absolutely agree.
I cant work out what the problem is, so I took out the call.
Its no biggie, and its not Xojo.

Xojo itself has not been without issue, however…
Ive been building stable Carbon apps in 2009 for years, even though I owned later licences.

Switched to 2012, and the Carbon version slowed to a crawl.
So I was more or less forced to ditch Carbon and pre-10.6 customers all in one week (i still get sales from people on 10.4) , and start building Cocoa only with Xojo.
It seems stable enough for me (very large app), unlike Carbon. Weird.

13

[quote=41502:@Jeff Tullin] soft declare sub NSShowAnimationEffect lib CocoaLib (animationEffect as Integer, x as Single, y as Single, width as Single, height as Single, animationDelegate as Ptr, didEndSelector as Ptr, contextInfo as Ptr)

  NSShowAnimationEffect theEffect, left, Screen(0).Height - top, width, height, nil, nil, nil [/quote]

The only change I can see is to pass structures instead of individual singles.

[code] declare sub NSShowAnimationEffect lib “Cocoa” ( effect as integer, center as NSPoint, size as NSSize, animationDelegate as Ptr, didEndSelector as Ptr, contextInfo as Ptr )

Dim center as NSPoint
center.X = X
center.y = y

Dim size as NSSize
size.width = width
size.height = height

NSShowAnimationEffect( NSAnimationEffectPoof, center, size, nil, nil, nil )[/code]

I just tried it and it works here without crashing.