Export Application crashes in Sierra but in Yosemite works perfectly

Hello Everyone
I have this serious issues that I’m not able to track. I exported my sketch processing to application and I tested in several machines, but two of then were OS X Sierra and the application opens the windows, but even before it shows something crashes and quits automatically. I am using several libraries and i always export using embed Java. The issues as far as I could tested is only concerned to Sierra because In Yosemite runs and rocks as I expected without any crashes or other error. Someone Experienced this issue? If yes Do you know how to solved?

I hope you were able to resolve this issue.

I haven’t personally seen anything like this, but with “several libraries” there is just so much that could be happening – no idea what those libraries are or what they do. Have you checked crash logs?

Have you tried adding “try / catch” exception blocks to your library loading / invocation so that you could inspect the error in the exported application?

Tried simply disabling the libaries and running, then re-adding one at a time until it breaks?

Hi Jeremy
I already tested my exported application in Yosemite, High Sierra, Windows 10, and Sierra (in two different Computers). The last two, the application crashed as I explained. Maybe I did not explain it well. It is not the export process that is giving me problems, I just can not run the application in Sierra. Another interesting pattern is that both computers are macbook pro early 2011 if that matters.
Here you can see the crashLog I exported in pdf https://drive.google.com/file/d/1CrMhYbmjZBX32XFjBHiB41buRiDdHCGS/view?usp=sharing
I still fell a bit lost interpreting the crash Log but as I understood there is a problematic frame in the Graphic Driver whatever it means. Well I don’t think the problem has to do with my code, since the application worked in 10 computers. Only two failed and both has similar properties.
I hope this give you more information.
Thank in advance
João

Based on searching issues from your error log, this thread might be relevant to your issue:

1 Like

Hello Jeremy
In fact, I had seen this, but my head was pointed in the other direction. This is a topic started in 2015 and since then many processing versions have been released. Still the problem persists. I’m glad that my machine does not give me problems, even being a Macbook Pro late 2011 with an AMD Radeon HD 6750M replaced by Apple for free, for a few defects detected in these generations of macbook. At least that’s what they said. At that time, Apple’s warranty policies were fairer. Nowadays the relationship between Apple and the Customer is unpleasant. As soon as you buy your machine and leave the store, it becomes obsolete. The end of the post you addressed to me is not a happy ending. It reminds me of the same attitude that Apple has now "1) it is out of Processing(NOT TRUE), and 2) it affects 8 year old machines.There is simply no way to make it a priority.I do not even know why I bother writing this for you. I spend months working and trying to develop a reliable code for an application which at the end may not work on some machines, undermine the confidence. So it should be priority?! I know it is a free platform for coding but it is really good one, and it is not restricted to idiomatic results as code platform like Touchdesigner. Well, I’m sorry for venting this.Thank you for everything.

I think I understand your point of view. I run several 7+ year-old machines with OS X, and am quite happy with them, and I am running my main Processing laptop on Sierra right now. Still, I suspect that at a certain point it would be easier to have your sketch just check and then quit gracefully if the system doesn’t meet system requirements.

If you want reliable deployment on Sierra-on-hardware-X, I can imagine some workarounds – but I would start by nailing down the cause of the problem as precisely as possible. Not ALL P2D/P3D sketches on Sierra on that hardware crash, am I right? So it is something about your sketch specifically that invokes some aspect of graphics in a way that will not work on that os+hardware. Perhaps you can work around it, but you need to know what it is that needs working around. Can you isolate the part that is crashing through debugging?

1 Like

I don’t want to do an application exclusively for Sierra this wouldn’t make sense. My code doesn’t have anything orthodox. I am using P2D, because in my sketch I’m using PGraphics. The library I am using is OscP5. And I not going to start doing workarounds, messing with a code that was careful designed and it successfully ran in several computers, except two, running Sierra on a mackBook early 2011. That’s all I know. I’m not going to do anything until I realize that the problem is with my code. If the Processing API eventually has some incompatibilities issues, messing with my code just to make it work in a case scenario, does not sound a good practice.Thank you for your help.

I’m not sure I understand what you mean by “orthodox”, but what you do is up to you!

It seems like just not running on macBook 2011 fixes your problem – that’s a very reasonable resolution, and is probably what I would do! If you change your mind about wanted to run on those machines as well, you know a way forward – that thread suggests two solutions:

  1. try making a first draw() round with no method calling (see thread example https://github.com/processing/processing/issues/4104#issuecomment-397882703 )
  2. try using the 3.0b5 build of Processing – this is reported to work with the HD3000 GPU

Hi Jeremy don’t take me wrong. I will try to do that, but I don’t have direct access to those machines that reported crashed so for me is a bit difficult to debug. I’m trying to build a library to processing and of course I would like to have 100% success on running in all machine. But I think this might be illusory. Yet I think in 12 only 2 failed is a positive achievement. Thank for everything. :wink:

1 Like