OS X 10.9.5 and Previous IDE versions

General
1

Hi Folks,

I updated two systems to 10.9.5 this weekend and have been rewarded with continuous IDE crashes in debug runs in RS12r2.1 and Xojo13r4.1. If I reboot those same systems back to 10.9.4, things continue to work as they should.

Here’s the repeating section of the crash dump:

8 com.apple.AE 0x91767b15 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*) + 387 9 com.apple.AE 0x9173a842 AESendMessage + 3574 10 com.apple.AE 0x91766e62 aeSend + 464 11 com.apple.HIToolbox 0x94aa0b1c AESend + 87 12 com.apple.HIToolbox 0x94a19836 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 2746 13 com.apple.HIToolbox 0x949e6795 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 2546 14 com.apple.HIToolbox 0x949e5668 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 386 15 com.apple.HIToolbox 0x949f8811 SendEventToEventTarget + 88 16 com.apple.HIToolbox 0x94a37cb6 SendTSMEvent + 75 17 com.apple.HIToolbox 0x94c85497 SendTextInputEvent + 1400

The other stuff is variable, but that is the same for all 14 crashes I witnessed.

If you are currently dependent on any of the older IDE versions, it might be wise to keep a system around that’s running 10.9.4 or 10.8.5.

'Cause the 10.10 train is barreling down the tracks and we can’t move fast enough to get out of its way :slight_smile:

2

I’m running 10.9.5 with many versions & have had 0 crashes like this

3

Here, 10.9.5 and 13r3 are fine.

4

No issues here.

5

No issues, working as usual.

6

Well, I guess YMMV applies here. Both system updated from 10.9.4 to 10.9.5 are exhibiting that aeDispatchAppleEvent crash. Rebooting into their cloned 10.9.4 volumes alleviates the crash.

7

the full stack trace might prove useful in a report
not sure but there has to be something different about your set up vs everyone else’s that can account for this

8

Because this only happens with the older releases …

9

Cant imagine what changed but obviously something has
This is one reason I keep a way to start all supported systems (current rMBP can boot 10.7, 10.8, 10.9 and 10.10) and I still have a VM with 10.6 - although I can get rid of that since we moved the minimum requirements up
Not sure if thats a viable option for you ?

10

This is just Carbon saying goodbye one dot release at a time. :slight_smile:

Check if this old trick can help: reboot and hold the keys 3 and 2 while booting (to load the 32 bit kernel instead of the 64).

11

A full crash log might tell us if its a difference in the input manager
That would make sense since 2012r2.1 is still a Carbon app
So its plausible

12

And the crash report is clearly from a Carbon app.

13

Exactly
Hence why given what I can see I suspect it is the text input system from Carbon which works increasingly less well on newer & newer versions of OS X
This might just be that manifesting itself

14

[quote=130986:@Tim Jones]Hi Folks,

I updated two systems to 10.9.5 this weekend and have been rewarded with continuous IDE crashes in debug runs in RS12r2.1 and Xojo13r4.1. If I reboot those same systems back to 10.9.4, things continue to work as they should.

Here’s the repeating section of the crash dump:

8 com.apple.AE 0x91767b15 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*) + 387 9 com.apple.AE 0x9173a842 AESendMessage + 3574 10 com.apple.AE 0x91766e62 aeSend + 464 11 com.apple.HIToolbox 0x94aa0b1c AESend + 87 12 com.apple.HIToolbox 0x94a19836 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 2746 13 com.apple.HIToolbox 0x949e6795 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 2546 14 com.apple.HIToolbox 0x949e5668 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 386 15 com.apple.HIToolbox 0x949f8811 SendEventToEventTarget + 88 16 com.apple.HIToolbox 0x94a37cb6 SendTSMEvent + 75 17 com.apple.HIToolbox 0x94c85497 SendTextInputEvent + 1400

The other stuff is variable, but that is the same for all 14 crashes I witnessed.

If you are currently dependent on any of the older IDE versions, it might be wise to keep a system around that’s running 10.9.4 or 10.8.5.

'Cause the 10.10 train is barreling down the tracks and we can’t move fast enough to get out of its way :)[/quote]

Like Norman’s said, toss a whole crash report up on Pastebin or something.

15

Witnessed it 5 times yesterday with 12r2.1 (building for 10.6).

Also, noticed that any Color setting are getting shifted left on loading the recovered data - for instance:

&xFFFFFF00 becomes &cFFFF00

and Yellow is definitely not white :(.

Again, it’s the older IDEs exhibiting the issues, so I don’t expect fixes, just wanted to warn others since It didn’t occur under 10.9.3.

For now, I’ve added a 10.8.5 VM to my system for work in the older IDEs (I love having 32GB!).

16

Also: a boot in the recovery partition and repair disk / repair permission may help. I do that once a week.

At least, making a bunch of successive reboot help too if you download / create / trash many many files every day.

17

Yes, I’ve noticed that caching in 10.9.5 seems to be a bit longer lived than in previous versions. I’ve never had to reboot my systems as much as I have in 10.9.5.

18

BTW - running under the 10.8.5 VM has solved the crashes and my 10.6 customers are safe once again :slight_smile:
.

19

If you average new items (files and folder) and delete items in a day is low and their size is low too (some KB), need is not a good word to use in that case.

If, like me you download tons of files every day, your finder will start to be slow, slower, the slowest you’ll ever saw.

In the shutdown and start process, the OS defragmentation is running. That explains why the computer is working a bit of time at shutdown / boot times sometions takes more time than usual.

Why people compete to be the one that shutdown / reboot the less number of time a year is out of my understanding.

20