Filemaker crashes more with calls to applescripts with ASOC in them

AppleScript
#1

Some heavy stuff for Mark and Shane…

I’m calling applescripts from within filemaker to do something with parameters and after finishing it fills in a global field in filemaker.
BUT!!! When building the scripts with ASOC in them they often let filemaker crash after some runs of the same script. the crash reports then always shows something like

Application Specific Information:
abort() called
*** error for object 0x7fe67e017408: incorrect checksum for freed object - object was probably modified after being freed.

I already contacted filemaker about this, send them a stack trace, but they say filemaker is not involved.
They said: The crashed thread only shows system calls (libsystem, CoreGraphics, HIToolbox, CoreFoundation, AppKit).

see thread https://community.filemaker.com/thread/181805

Is there anything I can do to find out what’s going wrong.
With the same setup but without ASOC I can run the scripts for hours without any issue.

any help would greatly be appreciated. I als have the feeling that building a script with SD7 is more vulnerable than one build in SD6. Is this possible?

#2

Anybody any idea how I can try to find out what is causing the crash?

#3

This would appear to be a memory corruption bug. These kinds of problems are very difficult to trace because the cause is usually displaced in time from the consequence. In this case, you have some piece of memory being deallocated, and then reallocated to some other purpose, and then being modified after its deallocation by code which has a stale reference to the memory.

There are no obvious clues in your crash report and I cannot think of any good ways of tracing this without involving some of the debugging tools built into Xcode. This isn’t viable given that you only have the FileMaker binary to work with.

ASObjC makes it exceeding easy to corrupt memory. I would start by auditing all of the ASObjC code to ensure you are allocating and messaging objects correctly.

You say that the script crashes once ASObjC code is introduced into FileMaker. Does this same ASObjC code crash when it runs from SD or the Script Editor? If you can reproduce the crash in SD, that rules FileMaker out of the equation which is somewhat helpful. This also points the finger firmly at your ASObjC code.

#4

Thnx Mark,
For your explanation. No it doesn’t crash when run from SD.
Maybe Shane can have a look at a part of the code :slight_smile:
I’m calling a API with the following code and maybe I’m not deallocating some parts correctly?

set rResult to (NSJSONSerialization’s JSONObjectWithData:((NSString’s stringWithString:mRequestStr)'s dataUsingEncoding:(NSUTF8StringEncoding)) options:0 |error|:( missing value )) as record
if ( count of rResult) is 1 then
set mData to “”
set mRecordProperty to ((NSDictionary’s dictionaryWithDictionary:rResult)'s allKeys() as list )'s item 1 as text
set theDict to NSDictionary’s dictionaryWithDictionary:rResult
set mValue to theDict’s objectForKey:mRecordProperty
set mURL to mURL & “?” & mRecordProperty & “=” & mValue
end if
set jSONDataString to NSString’s stringWithString:mRequestStr
set jsonData to jSONDataString’s dataUsingEncoding:(NSUTF8StringEncoding)
set {aJsonDict, theError} to NSJSONSerialization’s JSONObjectWithData:jsonData options:0 |error|:( reference )
if not theError is missing value then return -128 – STOPPEN
set {mData, theError} to NSJSONSerialization’s dataWithJSONObject:aJsonDict options:0 |error|:( reference )
set aRequest to NSMutableURLRequest’s requestWithURL:(|NSURL|'s URLWithString:mURL)
aRequest’s setHTTPMethod:“GET”
aRequest’s setValue:“application/json” forHTTPHeaderField:“Content-Type”
aRequest’s setValue:("Bearer " & gAccessToken) forHTTPHeaderField:“Authorization”
if mData is not “” then aRequest’s setHTTPBody:mData
set aRes to NSURLConnection’s sendSynchronousRequest:aRequest returningResponse:( reference ) |error|:( missing value )
set resList to aRes as list
set bRes to contents of ( first item of resList)
set resStr to NSString’s alloc()'s initWithData:bRes encoding:(NSUTF8StringEncoding)
set jsonString to resStr as text
set resStr to missing value
set theResult to (NSJSONSerialization’s JSONObjectWithData:((NSString’s stringWithString:jsonString)'s dataUsingEncoding:(NSUTF8StringEncoding)) options:0 |error|:( missing value )) as record

at the top of the script I’m using the following:

use AppleScript version “2.4”
use scripting additions

use framework “Foundation”
property NSString : a reference to current application’s NSString
property NSUTF8StringEncoding : a reference to current application’s NSUTF8StringEncoding
property |NSURL| : a reference to current application’s |NSURL|
property NSMutableURLRequest : a reference to current application’s NSMutableURLRequest
property NSURLConnection : a reference to current application’s NSURLConnection
property NSJSONSerialization : a reference to current application’s NSJSONSerialization
property NSDictionary : a reference to current application’s NSDictionary

I’ve just combined some ASObjC code from Shane and Takaaki Naganoya and google searches.…

#5

I don’t have much to add to what Mark’s said. The answer to your question about saving from v6 versus v7, though, is that it won’t make any difference.

You don’t really have any control over memory allocation — AppleScript does that for you (or not).

I’m wondering whether it’s possible that using NSURLConnection is triggering something, but that’s just a gut feeling.

What happens if you use the code as an applet? Mt recollection of how FileMaker works with AS is hazy.

#6

Hi Shane thanks for the answer so far :slight_smile:
With a applet do you mean a script app that runs once or that stays open?
I’m already running the script as a application that runs if you start the script with parameters from within filemaker and quits after it returns a reply json-like to filemaker…
Sometimes it makes filemaker crash at the start and sometimes after the return of the reply by clicking on another element in filemaker itself that even has nothing to do with the script itself.

#7

I mean a script saved as a .app file.

#8

But I just now had a crash with the same error from within SD7…
crashreport_20181107-01 SD7_txt.zip (28.3 KB)

with the following short script:

use AppleScript version “2.4”
use scripting additions
use framework “Foundation”
set mPosixPath to “/Users/luc.lnt/Documents/FMP_ASSCRIPTS/PX-ERP_AppleScriptApps/PX-ERP_Teamleader - Events_0100r.app”
set mPath to ( POSIX file mPosixPath)
try
mPath as alias
on error errMsg
tell application “SystemUIServer” to activate ( display alert “AppleScriptApp '” & mPosixPath & “’ bestaat niet !” message errMsg)
end try
set dbInfo to {dbName:“PX.fmp12”, FMPversion:“17”, dbTable:“GLOBAL”, dbField:“SCRIPTRESULT”}
set theEventParam to {theEvent:“ShowScriptVersion”, thePhrasID:""}
set mParams to {dbInfo} & {theEventParam}
set reply to run script mPath with parameters mParams
tell application “FileMaker Pro Advanced”
tell database “PX.fmp12” to tell table “GLOBAL” to set field “GLOBAL” to reply
end tell

#9

and a next one…
In the handler that is called there’s no ASOC involvedcrashreport_20181107-02 SD7_txt.zip (25.5 KB)

#10

Cheers Shane,
For the error I maybe found a possible clue…
Somebody is saying that the error can be caused by the NSMutableURLRequest
see https://books.google.be/books?id=W8JMajkrmokC&pg=PT873&lpg=PT873&dq=osX+NSMutableURLRequest+dispose&source=bl&ots=QWblQaFUjO&sig=0vJzzwOMrH_3sa-5ODQwskCg-kU&hl=nl&sa=X&ved=2ahUKEwinieyk2MTeAhVKLVAKHbX4CUUQ6AEwA3oECAkQAQ#v=onepage&q=osX%20NSMutableURLRequest%20dispose&f=false

But again I don’t get it to translate this to usable in a Applescript way?
Can you help me out again?

#11

Hi Shane,
I also found that is NSURLConnection deprecated and should be replaced by NSURLSession:

-Swift code-
var request = NSMutableURLRequest(URL: NSURL(string: “YOUR URL”))
var session = NSURLSession.sharedSession()
request.HTTPMethod = “POST”

var params = [“username”:“username”, “password”:“password”] as Dictionary<String, String>

var err: NSError?
request.HTTPBody = NSJSONSerialization.dataWithJSONObject(params, options: nil, error: &err)
request.addValue(“application/json”, forHTTPHeaderField: “Content-Type”)
request.addValue(“application/json”, forHTTPHeaderField: “Accept”)

var task = session.dataTaskWithRequest(request, completionHandler: {data, response, error -> Void in
println(“Response: (response)”)})

task.resume()

But in a post from 2016 I saw that you replied that NSURLSession wasn’t possible to do in AppleScriptObjC?
I’m totally lost now :frowning:

#12

As Mark said, these kinds of errors are very difficult to track down. There’s no guarantee that there is one cause: the fact that you had it happen without ASObjC suggests an unrelated crash.

I’m not sure what to advise, other than trying to run your code in separate apps where possible, to limit any direct effect on FileMaker.

#13

NSURLSession is the more modern API, but it’s unusable from ASObjC. However, NSURLConnection should still work.

#14

It seems that using the use clause for script libraries is making filemaker more vulnerable for crashes.
After removing the ASObjC parts it kept crashing with the same errors.
Then I changed back to my old way of working with SD5 — so I could load some script libraries in resources and now after calling it multiple times it seems to no longer crash.
I again will try to add some ASObjC in my scripts and evaluate again.

Why is the use clause making a application unstable with memory leaks or corruption?
Anyone else from Apple reading this?

#15

The only hints I can give you are this:

If FileMaker is running your scripts directly, I’d guess it’s using a single instance of the AppleScript component. (You can test this by changing text item delimiters in one script, and seeing if the change is reflected in another.)

Script libraries are cached per component instances. That is, assuming the above, once one script loads a particular script library, it remains cached by AppleScript. So if another script uses, say, a different version of the lib, it will actually still get the first one loaded.

It also means any top-level values in loaded libraries are going to be persistent, and shared between any clients of that library: when you set a library property, you set it for all clients of that library using that AppleScript component instance.

In such circumstances, it’s feasible that one script could do something behind the back of another to make bad things happen.

This may all be irrelevant in your case – it’s hard to know. But in case it is relevant, you need to make sure all scripts are expecting the same library code, and that the libraries’ properties and globals are accessed by client scripts on the basis that they don’t have exclusive access. For example, you may need to consider accessing them through handlers that check their contents, rather than assuming they have the value your script last gave them.