Comments
-
Greg Hurrell
Thanks for the report, tinsun.
Those stack traces look incomplete. Did you hand edit them to remove all the stack frames which didn't have the word Synergy in them?
For example, your first one:
12 org.wincent.Synergy 0x00010b73 -[SynergyController timer:] + 9203 13 org.wincent.Synergy 0x0000ce21 -[SynergyController handleNotification:] + 425 27 org.wincent.Synergy 0x00002dd2 start + 54
The way we interpret stack traces is from the bottom up:
- so there is stack frame 27 where Synergy is starting
- the call chain leads from one function/method to another until we get to stack frame 13, so there are 14 frames missing from your report there
-
frame 13 is evidently triggered by iTunes sending a
notification about a track-change or player-state-change
event, at which point it calls the
timermethod (frame 12) - then we have 12 missing frames leading up to frame 0 where the crash actually occurred
Without seeing the rest of the frames I would guess that this is bug #640 again; ie. the full trace will probably look something like this (this one comes from my own machine):
Thread 0 Crashed: 0 com.apple.applescript 0x00679d85 TUASFrame::UnlinkTo(TUASFrameType, TUASUnlinkExtent) + 53 1 com.apple.applescript 0x00677ad3 BCReturn() + 111 2 com.apple.applescript 0x0066233f UASExecute1() + 2439 3 com.apple.applescript 0x00662884 UASExecute(unsigned char) + 178 4 com.apple.applescript 0x006340e4 ASExecute(unsigned long, unsigned long, long, unsigned long*) + 302 5 ...ple.CoreServices.CarbonCore 0x928c3905 CallComponentFunctionCommon + 537 6 ...ple.CoreServices.CarbonCore 0x92908cb8 CallComponentFunction + 122 7 com.apple.applescript 0x0062fae2 AppleScriptComponent + 1744 8 com.apple.applescript 0x0064b927 AGenericManager::HandleOSACall(ComponentParameters*) + 63 9 ...ple.CoreServices.CarbonCore 0x928c35cd CallComponentDispatch + 29 10 com.apple.openscripting 0x93d25390 OSAExecute + 61 11 com.apple.Foundation 0x961f0f7b -[NSAppleScript(NSPrivate) _executeWithMode:andReturnError:] + 107 12 com.apple.Foundation 0x961f0e51 -[NSAppleScript executeAndReturnError:] + 49 13 org.wincent.Synergy 0x0000ea07 -[SynergyController timer:] + 647 (SynergyController.m:2256) 14 org.wincent.Synergy 0x0000ce21 -[SynergyController handleNotification:] + 425 (SynergyController.m:5509) 15 com.apple.Foundation 0x96107bda _nsnote_callback + 106 16 com.apple.CoreFoundation 0x9203f71b __CFXNotificationHandleMessage + 587 17 com.apple.CoreFoundation 0x9203f80e __CFXNotificationReceiveFromServer + 238 18 com.apple.CoreFoundation 0x9203a555 __CFMachPortPerform + 117 19 com.apple.CoreFoundation 0x9205e921 CFRunLoopRunSpecific + 3921 20 com.apple.CoreFoundation 0x9205ed18 CFRunLoopRunInMode + 88 21 com.apple.HIToolbox 0x949b76a0 RunCurrentEventLoopInMode + 283 22 com.apple.HIToolbox 0x949b74b9 ReceiveNextEventCommon + 374 23 com.apple.HIToolbox 0x949b732d BlockUntilNextEventMatchingListInMode + 106 24 com.apple.AppKit 0x90f327d9 _DPSNextEvent + 657 25 com.apple.AppKit 0x90f3208e -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 26 com.apple.AppKit 0x90f2b0c5 -[NSApplication run] + 795 27 com.apple.AppKit 0x90ef830a NSApplicationMain + 574 28 org.wincent.Synergy 0x00002dd2 start + 54
Now, as a programmer, normally when you see a stack trace like this you might like to think, "Ah, look! It is crashing in system code!". But in reality, in about 99.5% of cases you haven't found a bug in Mac OS X but rather the bug is in your code and something you are doing is creating circumstances which will cause a crash in the system APIs.
There are some rare cases — the 0.5% — where you actually have discovered a bug in the OS, and these NSAppleScript cases are such. See bug #640 for more details on that. Sometimes system bugs can be worked around and you can use an alternative API or some kind of trick to prevent them from being triggered, but in the case of NSAppleScript I can't really avoid the issue without ripping out the entire nervous system of the application and rewriting it. I have been working on this, but it's likely that Apple will fix the bug before I finish the rewrite.
So go back and have a look at your crash logs and see if "NSAppleScript" appears anywhere in the stack trace. If it does, looks like you're hitting bug #640. Unfortunately those crashes are fairly random; in my case I seem to be getting a crash every few days but I know others have seen them more often. Going back to 3.2 is a viable option if you're seeing these crashes often.
If you're not seeing an NSAppleScript crash, then please do post the full stack traces. You can use
<pre></pre>tags to prevent them from getting misformatted (I'm about to go back and fix the formatting on your description there). -
anonymous
Created
,
edited
im having the same problem and im running it on a mac pro 10.5.2 as well. any fixes? do you need to see crashreports?
reecesuggs at gmail dot com
-
Greg Hurrell
Well take a look at your crash reports; if you see NSAppleScript then you're actually seeing bug #640. That's a bug in Leopard, so I'm encouraging people to file bug reports with Apple about it (see bug #640 for more details). You can also go back to 3.2 if you prefer not to put up with the crashes while waiting for the fix from Apple.
-
Greg Hurrell
As this one does look to be a duplicate of bug #640, going to mark this one as CLOSED.
Add a comment
Comments are now closed for this issue.