Compiled XCode apps crashing under 2.3.6

I’m on build 73 of 2.3.6, and having an XCode issue I haven’t seen before.

While apps appear to compile and launch, ever app I try to launch on the simulator throws an error. The apps displays the launch image, then crashes in XCode, throwing this error:

2017-05-14 12:00:58.785 AppName[3419:416050] -[UIImage isLoaded]: unrecognized selector sent to instance 0x600000288930

2017-05-14 12:00:58.802 AppName[3419:416050] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘-[UIImage isLoaded]: unrecognized selector sent to instance 0x600000288930’

This is happening across multiple apps. Any clue as to what I’m looking at? Thanks.

@john when you or @simeon have a chance, I’d like to send you the XCode project on one of these apps.

They work fine within Codea, but crash in XCode on the simulator. I’ve scanned the code repeatedly for clues to the problem, but the point in the app at which it crashes changes. As far as I can see, it appears to be losing some functions from the table so that _G(“function name”) no longer maps back to the function.

But it’s hugely inconsistent between apps and even within an app.

I suspect I’ve done something flaky, perhaps recursively spawning threads or doing something else that’s causing memory to spew. But not being able to see the issue within Codea, then having it throw up at a different spot each time I go into XCode is driving me a bit mad.

I was hoping you might have a better sense of what’s happening. Thanks.

@Mark Could you put collectgarbage() at the beginning of the draw function just to rule out a memory issue.

Unfortunately, that doesn’t seem to make a difference. The app runs fine within Codea. It’s only in XCode that it fails. And when it fails, it fails quickly, after only 2-3 passes through draw.

After the first call to http.request, the _G(func) no longer returns a valid function.

Except that’s only true on some apps. On other apps, the same library making calls to web APIs through the same calls, hum right along.

I don’t do anything with XCode so I can give specific advice. But debugging code is the same no matter where it’s run. I would start by commenting out code and see what specifically causes the problem.

Again, the app runs fine in Codea. All day. It fails in XCode, but when it does, the relationship of that failure to a line of Lua isn’t clear. It seems to be related to spawning threads under http requests, but even that’s not a sure thing. The code that fails in XCode runs fine in Codea, making it darn difficult to even know where to start in a program with many, many lines of code.

@Mark As I said, I don’t do anything with XCode, but I still think that you can run XCode and keep commenting out code until it doesn’t crash. At least you can be trying stuff until someone can give you a reason. Codea might be more forgiving than XCode as to crashes which is why it runs with Codea but not XCode.

@Mark it would be great to look at the project. It seems to be a memory corruption issue. Almost as if the simulator is loading a UIImage as a project (the isLoaded is used to check if a project is loaded).

@Simeon I believe I’ve finally identified the issue as being in shaders. Within the Codea environment it seems to keep things cleaned up and there are no issues, but the shaders – which are simple, but old, and may pre-date some changes to the shader environment – appear to be causing the issue within XCode.

It’s a pain the behind to figure out, because the shaders are apparently overwriting memory somewhere, causing the app to crash at different lines pretty much every time you run it. But I’m moderately certain that’s the source of the issue.