This problem really puzzles me, since AppleScriptObjC should handle garbage collection just fine on its own.
Anyway, the steps to reproduce this error are:
Create a new Cocoa-AppleScript-Application project
Insert single call to NSMakePoint anywhere in the project's nameAppDelegate.applescript file. The file should now look something like this:
script testAppDelegate
property parent : class "NSObject"
on applicationWillFinishLaunching_(aNotification)
-- Insert code here to initialize your application before any files are opened
set single_point to NSMakePoint(5, 10) of current application
display alert "X-value of point: " & x of single_point
end applicationWillFinishLaunching_
on applicationShouldTerminate_(sender)
-- Insert code here to do any housekeeping before your application quits
display alert "Terminating"
return current application's NSTerminateNow
end applicationShouldTerminate_
end script
Run the application
The above application will launch and display the alert "X-value of point: 5.0" (as expected), but immediately after the alert it will crash with the following EXC_BAD_ACCESS error in the file main.m: main.m error
Thus, somewhere a call is being made to an object that no longer exists. If we profile the application with NSZombies enabled, it confirms that a zombie has been messaged and gives this additional info: zombie info
I've also tried the same thing with NSMakeRange and NSMakeRect instead, and it gives exactly the same result. I suspect every call to a Core Foundation function will crash the application this way. However, if we as an example call stringValue() of a NSTextField, it works just fine.
Putting the call outside of applicationWillFinishLaunching_ does not solve it either. So what am I doing wrong?
I'm using XCode 4.3.3 on OSX Lion 1.7.4
EDIT: After some further research, I realized I do not need to call NSMakePoint, I could just create an AppleScript record like {|x|:0, |y|:0} and it will work just like an NSPoint object. So that solves it, I guess.
Related
I have an Applescript that runs fine on my Macbook Retina but fails on a Mac Mini.
Both are running MacOS 10.9.2.
After peeling the onion a bit I'm able to reproduce the problem with a one-line Applescript:
tell application "MidiPipe" to activate
On the Mini that throws the error:
An error of type -10810 has occurred.
On the Macbook the MidiPipe application opens.
MidiPipe works normally on the Mini when started from the Finder or from Launchpad.
Google provides no insight into this error.
Well, I found this: http://www.thexlab.com/faqs/error-10810.html and this: http://osxdaily.com/2010/02/09/mac-error-10810/ and this: http://forums.adobe.com/thread/1389805 . At least one of these suggests a RAM problem.
But just to make sure you've tried every weird variation, have you tried the following:
1) using a full path:
tell application "Full:Path:To:MidiPipe.app" --(probably "YourHDName:Applications:MidiPipe.app"?
2) using an actual tell block:
tell application "MidiPipe"--or full path
activate
end tell
3) using the Finder:
tell application "Finder" to open "Full:Path:To:MidiPipe.app"
4) using shell:
do shell script "open /Applications/MidiPipe.app"
?
After looking at the links in CRGreen's answer, it looks like this is likely being caused by the process table being full on the mini. This, in turn, prevents any new applications from opening. According to The X Lab:
Error -10810 is a Launch Services result code indicating an unknown error. One cause of this error is that the Mac® OS X process table is full. When the process table is full, new (not currently running) applications cannot be opened until another running application ends. Programming errors in third-party applications can fill-up the process table, leading to the -10810 error when opening an application.
I would start by restarting the mini to see if that clears the process table, allowing you to to start MidiPipe.
If that doesn't work, you should look at your Activity Monitor to see if there is a specific program filling up your process table.
Could be nothing more than another mysterious grieving crap from Apple.
Today I have faced this myself, first time after using four different Mac Minis as build servers for Continuous Integration of Mobile apps for about two years or so.
My Jenkins runs the osascript from the bash script to build the app.
A few days ago the office experienced the power outage and all Macs went down. After powering them back on I have got this error at osascript execution on one of my Macs.
I have tried just to re-build - with the same result.
First thing I stumbled upon was https://jacobsalmela.com/2014/08/04/infamous-execution-error-error-type-10810-occurred-10810/ , but none of them applied to me.
Then I googled more general 10810 issue occurrences and went through couple of questions here on SO.
Still no luck.
Next I reached to the server via SSH using PuTTY and tried telling Terminal to do the very basic script like
osascript -e 'tell application "Terminal"
activate
tell window 1
do script "counter=0; while true; do if [ \"$counter\" -gt \"10\" ]; then
break; else counter=$((counter + 1)); sleep 1; fi; done; exit;"
end tell
end tell'
This worked fine.
Then I tried to run the whole bash script that Jenkins used to execute. Everything went just perfect and the app was uploaded to HockeyApp as the result.
I came with the thought that the issue is that Jenkins runs it remotely on that Mac and finally I have tried just to re-build again and it magically worked fine this time.
No idea what it was, but since then I have performed three or more builds already and all of them were successful.
Note I haven't changed anything, and my script:
1) never used a full path;
2) always used an actual tell block;
3,4) nothing like that from the accepted answer was ever used.
So... Go away mysterious grieving crap! Go away! :)
Where XCode generate error for application crash ?
I'm crazyng ! My application when open second file xib with webview then it crash. But I don't know why ? how can i Know where is error ?
You need to learn how to use the debugger in Xcode.
Run your app under the debugger then instead if simply getting a stack trace Xcode will stop at the line the fault occurs and show you your code and variables. You can then examine the contents of your variables, the call tree, etc. and hunt down the problem.
Once you know the general area of the problem you can place breakpoints to pause your application before the problem occurs and check whether your variables have the values expected etc. Then you can run till the next breakpoint, or step through your code a line at a time.
You can add code, such as NSAssert's and NSLog's to your app to check progress and display information without stopping the run, etc.
It's a process, and some problems will be harder to track down, but you'll get quicker at it with practice.
The Xcode documentation will tell you all about the debugger.
HTH
I have a VB6 app that has a ton of 3rd party components. The app works well, but on exit (and only when running as a standalone EXE, e.g. not in the IDE), it pops up an error message:
I've seen errors like these before but typically it says which component is missing dependencies or is not registered properly.
I ran it through Process Monitor and got the following files that it cannot find:
And then it quits. I googled the file names that it cannot find and can't seem to find anything. It seems like its searching for a variation of MSComENU, MSComEN and MSCOENU dlls.
I checked and rechecked to make sure that all the the 3rd party components are there and they are - the application functions fine, it wouldn't if they weren't there.
It is worth noting that error occurs after the last line of VB6 code (in Form_Unload event) has fired. I know this because the last line is a message box that does appear.
Much, much later EDIT: I finally got back to dealing with the problem and figured it out by process of elimination (and it was a loooong process). In the end it had nothing to do with any MSCOMM*.dll entries. In fact, I do not know why they still show up in Process Monitor. The problem was much simpler.
I had several 3rd party controls on the main form. In an effort not to pollute the main form with a ton of event handling code, I delegated these controls to a new class, like so:
' declaration code in main form'
Private WithEvents moDelegateObject as clsDelegateObject
' still in the main form, after initialization'
Set moDelegateObject = new clsDelegateObject
With moDelegateObject
Set .ThirdPartyCtlHandler1 = me.ThirdPartyCtl1
Set .ThirdPartyCtlHandler2 = me.ThirdPartyCtl2
Set .ThirdPartyCtlHandler3 = me.ThirdPartyCtl3
end with
' declarations and properties inside of clsDelegateObject'
Private WithEvents moThirdPartyCtlHandler1 as ThirdPartyCtl
Private WithEvents moThirdPartyCtlHandler2 as ThirdPartyCtl
Private WithEvents moThirdPartyCtlHandler3 as ThirdPartyCtl
Public Event FooEvent() ' other various events as well '
Public Property Set ThirdPartyCtlHandler1(o as ThirdPartyCtl)
moThirdPartyCtlHandler1 = o
End Property
Public Property Get ThirdPartyCtlHandler1() as ThirdPartyCtl
ThirdPartyCtlHandler1 = moThirdPartyCtlHandler1
End Property
' ... Repeat for each handler ...'
What was missing was code to explicitly deallocate these objects prior to closing. This is something that Visual Basic typically does. So I added the following in the Form_QueryClose in the main form:
With moDelegateObject
Set .ThirdPartyCtlHandler1 = Nothing
Set .ThirdPartyCtlHandler2 = Nothing
Set .ThirdPartyCtlHandler3 = Nothing
End with
Set moDelegateObject = Nothing
Last line turned out to be superflous, but I threw it in there for completeness sake. I think it was a combination of delegating controls to a delegate class and receiving events from it in the Main form and using a good number of really obscure 3rd party controls which contributed to this problem. It is probable that the 3rd party control does not cleanly deallocates itself. Anyway, lesson learned.
This could be a DLL_PROCESS_DETACH or CoUninitialize problem. Raymond Chen's blog "The Old New Thing" has a couple of relevant articles:
When DLL_PROCESS_DETACH tells you that the process is exiting, your best bet is just to return without doing anything
Do you know when your destructors run? Part 1.
Quick overview of how processes exit on Windows XP
How you might be loading a DLL during DLL_PROCESS_DETACH without even realizing it
The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification
As you said these are 3rd party components. You could try to make smaller test cases until the problem disappears to pinpoint the buggy component. You could also try a native code debugger and analyze what code created the error message.
The simplest solution however to work around the issue is trying to force a specific load-order of all those components. In the Main() or startup form, try to use some functionality of each 3rd party component in a fixed order. If the bug still appears, change the order until the problem vanishes. That might work.
You could try using dependency walker on the list of references in the project file to see if any of those third party files are missing dependencies. If no dependencies are missing then try registering the files again using regsvr32. If any of the regsvr32 commands fail then you may have found the component with missing dependencies.
I created a small test Mac app using the Core Data template (on Lion 10.7 and Xcode 4). I used the example on this site, http://www.swampfoetus.net/chapter-7-fail/, to hook up all the Cocoa Bindings with a tableview, an NSArrayController, a text box and an Add button. The NSArrayController is linked to the managedObjectContext of the App Delegate.
Everything seems to work fine when I launch the app ... I can type in text and press Add, and it gets saved in the tableview. I saved a few rows, and then pressed Save in the file menu (linked to the saveAction IBAction) and quit the app. I can see the data being saved in the xml data file (I renamed it .xml ... the PSC is of type NSXMLStoreType).
The problem is that when I launch the app again, it launches without the data that was saved in the Core Data file in the previous run.
This happens each time ... I can add data and it keeps appending to the data file, but at launch it never seems to read from this data file.
Any ideas what could be wrong here? I haven't messed around with the App Delegate generated code at all, only set up the bindings which seem to work fine. What could I check to make sure it's setup correctly?
If the data shows up in the persistent store, then the only explanation would be a problem with the binding where the UI doesn't display the previous data for some reason. It's hard to say why that is happening but my guess would be a fetch predicate or some other bound qualifier that causes the controller to ignore older objects so that they are not displayed.
I can't say for sure because I don't have access to the book.
This is one of the drawbacks of using bindings. When they work, they're fantastic but when they don't, they're a ##%! to debug.
I created a skeleton Active X DLL with its Instancing property set to MultiUse and only one function which does nothing but pop up a message box saying that it has been called.
Then I created a test program and added the DLL to its References.
I added code to declare a variable of the DLL's Classmodule, to create a new object and to call the function.
In all cases I used Intellisense code completion, so VB6 certainly about the DLL and it's class & method.
However, when I run the tester it reports runtime "error 91 object variable or With block variable not set" when trying to create the New object.
This is new territory for me, so hopefully it is something obvious.
Update: I added a message box in a DLL fn() to say that it had been called, then went to a real life web site that uses Active X to call into the DLL and saw the message box - but I still get the error in a VB tester application(!?)
It would be easier to find the problem if you could post the calling code and the DLL class.
Here's a guess. Have you remembered the Set on the line that creates the new object?
Correct code
Set obj = New MyDLL.MyObject
Incorrect code
obj = New MyDLL.MyObject
Try changing the function in your active x dll to return a message instead. Show your message box in your calling code, not in the dll.
Else, try in command prompt, regsvr32 "myDll.dll", and then run your code.