Yosemite issues

On apps written by REAL 2011r3, in Carbon, are anyone finding problems running them in Yosemite?

I have Yosemite and I have ran all my apps in it and they work fine. But recently I’ve gotten about 3 customers saying that the app starts, but just stalls. No windows showing, no menu bar population - just the app in the menu bar. So the process is running but it must not get going.

I write to the system log almost immediately, but that doesn’t show up, thus just the executable is internally failing somewhere. The only thing in the system log that mentions anything is one that says “gestaultSysteminformation returns the wrong version number” but its a warning and something that doesn’t seem to be fatal. It’s just the version number.

I know I’m running Carbon and that’s deprecated but Yosemite should run them fine, as my Yosemite does. (That is to say, please don’t answer by recommending Cocoa.) I know I’m running an old REAL but again it still SHOULD work. (That is to say, please don’t recommend using Xojo instead. Look, I’ll get updated in those things one of these days, but as it stands now, my program should work and does work on my and other peoples machines.) I also cannot find anything on Google.

So I’m stumped - has anyone found any problems like this? And how have you addressed them?

There have been several reported issues on this forum of Carbon apps misbehaving on Yosemite. You have clearly stated that you don’t want to hear the obvious solution, so I don’t know what anyone else can offer.

The problem with having 3 customers reporting an issue is how you are going to reproduce it in order to fix it. Admitting the 3 issues are identical.

Who knows what specific thing causes the app to stall ? I have seen that happen with antiviruses in Windows, so it could be that too. Or something entirely different. For instance, I noticed that Thunderbird, which I do not know if it is Carbon or Cocoa, now takes forever to actually become operational after showing the main window. Worse yet, it seems to snatch all resources during the three minutes or so it does who knows what that stalls.

Yosemite is full of surprises…

I went into detail in my question because on this list often you get answers that are not “thoughtful” (that is, full of thought). I do appreciate the help, but really think about what you are saying. If I have a nail, and I need to pound it into a piece of wood, I’m not going to call a construction company. That OBVIOUSLY will work, but isn’t it prudent to look for the most expedient solution first? Like a hammer?

Maybe you have it in your head that “deprecated” means “won’t work”, “never works”, “don’t dare use it because it will be unstable” or other mythical ideas. Deprecated simply means that such technologies may not work properly in newer OS’s. However, it is very obvious (using your term) that Apple with Carbon is going to be at least responsible about it. It isn’t going to sabotage it secretly etc. Yosemite was made public beta and if Carbon was seriously threatened, it’d be known by know. So far I haven’t heard anyone saying on a fundamental level Carbon is unusable in Yosemite.

I also made clear that it was simply a startup problem and my code hadn’t even been hit yet, which means it’s either a core REAL problem (that is rbframework.dylib) or a plugin issue.

So while I really truly appreciate your answer, your answer was misinformed. I"m not dumb and I’m not going to make major changes UNLESS I know why I have to do it. Sounds prudent to me.

OK, back to the question - anyone experiencing startup errors with REAL2011r3-built apps that don’t even hit your code?

I have a 2010 R1-built Carbon app and have (so far) not run into any serious problems under Yosemite. I suppose that’s not terribly helpful, other than to say that it’s not affecting all REALbasic Carbon apps.

I’ve seen weird stuff with IPCSockets and third party apps - can you get your 3 clients to run EtreCheck or similar and see what they have installed?

can those clients run activity monitor and make a sample of the app?
So you can see which function blocks.

I think that this may be some code signing analysis… I have this happening for one customer with a Cocoa (2014r2.1) based application. Console doesn’t seem to report anything useful (except about an XPC process, which I’m not using any XPC).

I can’t reproduce it in house either. Then again Yosemite runs like complete poop on a '09 17" MBP. Even my wife got pissed off waiting for it.

That certainly is a politer word than I would have used. IMHO, it’s the worst OS X release in a decade, but I think everyone knows how I feel about Yosie.

[quote=143480:@Christian Schmitz]can those clients run activity monitor and make a sample of the app?
So you can see which function blocks.[/quote]
Good suggestion!

@Garth Hjelte:
I’ve tested the few apps I wrote years ago with REALStudio Pro 2010 R5 with Carbon and they all operate fine on Yosemite. I’ve tested them with the handful of people that actually have the apps and also have Yosemite installed and they are running fine as well. My apps are not really using anything special out side of REALStudio and REALSQLSERVER, but they are indeed Carbon apps.

I have thousands of sales over the years.
All shipped copies before the end of 2013 went out as Carbon.
I do get upgrade sales, but not one person has reported the older software stopped working.
That could mean the older copies are not still in use, or that the people with the older machines haven’t upgraded to Yosemite. (I only did that on one of my machines for example)

But as everyone else said, its not a widespread issue, and my app has plugins in use.

Yosemite is very slow in the first few uses.
It grinds away doing new indexing of stuff on your machine, and not as a low priority task.
It gets better.
(Still looks like a Fisher price OS, though…)

Does the app call home in startup?
Access the web in any way? If so, do these people have Little Snitch installed?

Write preferences files somewhere? If so, do these people have Sophos Antivirus installed?

If you can’t recreate it, you don’t know its not your code that is being hit yet.

At one point, one has to ponder the relative weight of 3 users versus the total number of happy campers. For a successful general public product with, as said Jeff, thousand of sales, three is not many at all. Even in the enchanted Mac OS X world, sht happens. Without the tremendous fragmentation experiences over at Windows, still customers install all sorts of nasty buggers like antiviruses and things that lurk in the background and mess up things. Worse, some systems are corrupt and do all sorts of strange things. Then there is the user competence and the bizarre things he does. One of my popular font sells in the thousands per year to teachers. A particularly ansy crowd with sometimes surprising levels of technical ignorance. Every other week, one of them tries to dump a zip file into the Fonts folder or into Font Book and complains the product is corrupted. Those who get in touch I give step by step instructions. But there are a few sad cases who never report and go to the Paypal dispute process, screaming a yelling. That is life. If necessary, I rather refund quickly the nasty on, before it gets the best of me, and forget about the bug in the user brain.

Now if one is selling to say, a dozen of corporate clients and 3 of them are not happy, that becomes a quite different issue. Then with a closer relationship, it should be possible to get much more information from them as to what is happening to be able to understand.

Would Yosemite be Apple’s Windows 8 like Snow Leopard was its XP ? :wink:

How do you sample a process before it exists? Because the problem is very early and I can’t sample the process that quickly.

Again, remember that practically none of my code gets hit. Almost immediately, I write to the system log and nothing shows in the system log, except some thing about gestaltSystemVersion returning the wrong thing. Nothing before the system log write occurs of any significance.

Well, I got one sample report back, it looks like it might be MIDI in the MBS MIDI .rbx. I’ve talked to you a little about this, Christian. I’m using the latest MBS. I’m not calling it yet in the program, it’s seems to be something that runs on init or something?

  • 2918 start (in Translator 6) + 43 [0x14ff20c]
    • 2918 _start (in Translator 6) + 116 [0x14ff2b6]
    • 2918 % main  (in Translator 6) + 36  [0x25f4]
    •   2918 _Main  (in Translator 6) + 218  [0x2a53]
    •     2918 REALbasic._RunFrameworkInitialization%%p  (in Translator 6) + 42  [0x24d193]
    •       2918 RunFrameworkInitialization  (in rbframework.dylib) + 83  [0x1953373]
    •         2918 _Startup  (in Translator 6) + 28  [0x290a]
    •           2918 REALbasic._RuntimeInitExternalClasses  (in Translator 6) + 60  [0x24ce70]
    •             2918 RuntimeInitExternalClasses  (in rbframework.dylib) + 26  [0x195331e]
    •               2918 LoadPlugins  (in rbframework.dylib) + 1304  [0x199383a]
    •                 2918 REALPluginMain  (in MBS Real Studio Audio Plugin.rbx_1.dylib) + 295  [0x667f2f7]
    •                   2918 pm_init  (in MBS Real Studio Audio Plugin.rbx_1.dylib) + 88  [0x6680208]
    •                     2918 MIDIClientCreate  (in CoreMIDI) + 340  [0x66bacd3]

What form of this are you using ?
There’s a known issue using the old simple style once you get past 10.9 and even with the bug fix releases beyond .9 (i.e. 10.6.10 , etc)
see https://forum.xojo.com/16320-recognize-version-of-os-x/p1#p134819

Actually, here’s the important stuff:

2818 Thread_545558
+ 2818 thread_start (in libsystem_pthread.dylib) + 34 [0x99048f0e]
+ 2818 _pthread_start (in libsystem_pthread.dylib) + 162 [0x9904ae45]
+ 2818 _pthread_body (in libsystem_pthread.dylib) + 138 [0x9904aecf]
+ 2818 CAPThread::Entry(CAPThread*) (in CoreMIDI) + 134 [0x3f2996c]
+ 2818 XThread::RunHelper(void*) (in CoreMIDI) + 17 [0x3f29e2b]
+ 2818 MIDIProcess::MIDIInPortThread::Run() (in CoreMIDI) + 24 [0x3f49914]
+ 2818 MIDIProcess::RunMIDIInThread() (in CoreMIDI) + 151 [0x3f45539]
+ 2818 XServerMachPort::ReceiveMessage(int&, void*, int&) (in CoreMIDI) + 123 [0x3f28ac3]
+ 2818 mach_msg (in libsystem_kernel.dylib) + 68 [0x961c5ad0]
+ 2818 mach_msg_trap (in libsystem_kernel.dylib) + 10 [0x961c6a2e]
2818 Thread_545947 DispatchQueue_39: com.apple.audio.proxy-event (serial)
2818 start_wqthread (in libsystem_pthread.dylib) + 30 [0x99048eea]
2818 _pthread_wqthread (in libsystem_pthread.dylib) + 724 [0x9904b296]
2818 _dispatch_worker_thread3 (in libdispatch.dylib) + 97 [0x9903363d]
2818 _dispatch_root_queue_drain (in libdispatch.dylib) + 395 [0x99023f89]
2818 _dispatch_queue_invoke (in libdispatch.dylib) + 186 [0x9902699d]
2818 _dispatch_queue_drain (in libdispatch.dylib) + 499 [0x99024aff]
2818 _dispatch_source_invoke (in libdispatch.dylib) + 345 [0x99024f88]
2818 _dispatch_source_latch_and_call (in libdispatch.dylib) + 710 [0x9902c9a4]
2818 ___ZN18HALB_DispatchQueue16InstallMIGServerEjmPFiP17mach_msg_header_tS1_E_block_invoke (in CoreAudio) + 34 [0x9876ebf2]
2818 dispatch_mig_server (in libdispatch.dylib) + 415 [0x9902ee5d]
2818 HALB_MIGClient_server (in CoreAudio) + 91 [0x98767c25]
2818 _XObject_PropertyListener (in CoreAudio) + 232 [0x98767d32]
2818 HALC_Object_PropertyListener (in CoreAudio) + 23 [0x98767d72]
2818 HALC_ShellInfo::WaitForCurrentProcessInitialized() (in CoreAudio) + 54 [0x98767e4a]
2818 HALB_Guard::Wait() (in CoreAudio) + 72 [0x98776648]
2818 pthread_cond_wait$UNIX2003 (in libsystem_pthread.dylib) + 71 [0x9904f1d1]
2818 _pthread_cond_wait (in libsystem_pthread.dylib) + 726 [0x9904bb06]
2818 __psynch_cvwait (in libsystem_kernel.dylib) + 10 [0x961cc516]

Christians gave me a hint about an outdated Avid CoreAudio driver, it may be correct as it’s solved one persons issue.


I don’t know how bad Windows 8 was for MS, but Yosemite is a steaming pile of crap. I can no longer stream my media from Yosemite to the AppleTV. It just won’t connect correctly. Looks like ai’m filing another big report.

I’m having problems with Home Sharing with the latest iTunes/AppleTVOS :frowning:
Make them fix it, Sam!

Hi Tim, it seems the solution is to remove the Yosie crap, until Apple get some of these issues resolved. I just can’t believe how crap Yosie is, if this is Tim Cook’s Apple, it might be time for me to think about a career change.

I seriously hope that the poor quality of work with Yosie doesn’t continue!

[quote=143819:@Sam Rowlands]Hi Tim, it seems the solution is to remove the Yosie crap, until Apple get some of these issues resolved. I just can’t believe how crap Yosie is, if this is Tim Cook’s Apple, it might be time for me to think about a career change.

I seriously hope that the poor quality of work with Yosie doesn’t continue![/quote]

A few years back, Lion was pretty bizarre. Maybe we are to wait for Snow Yoyo ?

Apple had for years made it safe to “Update first. Ask questions later.”
Yosemite seems to have tarnished that.