The most recent crash log shows calls to the QuartzCore, which does graphics.
My guess is there is a corrupted graphic somewhere. Could be in something you are adding to FMP or a graphic contained in FMP.
If it's a graphic you are adding then you'll have to figure out which one it is.
If it's an internal graphic then deleting the FMP application and reinstalling should fix it.
I have been liaising with FMI over this and the cause was as follows:
I was using a technique I first saw from BruceRobertson setting some vars within conditional formatting for another purpose, i.e. not for cond' formatting, in this case getting the dimensions of the web viewer in order to dynamically display them in a merge variable with neither a script nor a field.
Works like magic and very lovely thing to see, like everything that Bruce comes up with..
The expression was:
However, it transpires, and I guess this is because this is not something that FMI would have anticipated someone doing with cond' formatting, that this innocent expression often crashed FMA14v4 whether it was local or hosted.
So I have discontinued using this technique until I hear that it is safe to do so.
It would be interesting to learn whether you can reproduce this yourself?
The webviewer was an object named webviewer and the two vars were displayed as merge variables. The expression was the conditional formatting for the merge variable.
I wasn't able to crash any of my FMP 14 Mac databases typing CMD-B.
Can you create a sample app and a list of steps to reproduce the issue? That's what will generally be required for FM to fix this, that is, unless it's already a "known problem".
Some ideas and observations:
From your crash file it looks like the heap space was nearly exhausted in the file I looked at. Maybe add more memory or reduce the number of apps requiring dynamic memory allocation?
Try this solution on another computer to try to divide the problem space.
Not that this is necessarily a solution in any way, but the current OS/X release is 10.11.3.
Thanks for your observation, I confirm that I have liaised with FMI on this and they have identified and reproduced this crasher as I described in my previous post. Hence I assume that it will come through as a fix in a future version.
I can also confirm that when I had removed the set gvar in the conditional formating as described I returned to the happy state of not suffering frequent crashes from this cause.
This was in our new Deskspace CMS App.
See the screens shot attached. As the App builds responsive web pages we thought it would be nice to display the width of the web viewer, the data that our css media queries use to make the page responsive, on the screen and the simplest method was to do it as described above, as inoperative conditional formatting which merely set the gvar with which we displayed the viewer width.
It did work like magic, instantly changing as the viewer changed width, brilliant, until we eventually discovered it was also triggering these dreadful crashes.
I can't say whether it was just the method of setting the gvar which was the cause or whether it was that method in conjunction with the web viewer on the same layout, I merely removed that feature and got on with building Deskspace CMS v2. I had actually rebuilt the entire app from scratch because I though initially there was corruption in the original file.
You can download Deskspace CMS Release 2 from our site for free and try it yourself