URGENT: Fatal Lua Error in Solar2D Builds

Solar2D General Questions/Discussion
#23

OK- This is a bit of a fool’s errand, but could you install 3707 and see if you can launch the app there? I know 3707 can’t build for Android, but it can at least get us to where things break for you.

Also, the billing library is not directly tied to the Solar2D build. If you manually set your version of plugin.google.iap.billing.v2 to v13 it should work with 3706. The current version (v16) incorporates the new Android API and might not work, but I’ve been using v13 successfully with an older version of Solar2D since June, and it uses the new billing library.

As for build.settings and the sandbox, I just checked and the SpriteTiles demo has as generic a build.settings file as you can imagine, and writes literally nothing to the sandbox besides the three folders that are created automatically.

#24

Yet another weird thing to try:

  • Open up the main.lua of SpriteTiles and delete everything.
  • Save it.
  • Try launching it in 3709.

I just got a black screen.

#25

@clang As you recommended I try, selected the Corona Simulator for 3709 and chose Get Info, then turned on “Open with Rosetta”. Problem still occurs.

#26

@colinmorgan I installed 3707 as you recommended, problem still occurs.

#27

@colinmorgan Were you recommending I change:
[“plugin.google.iap.billing.v2”] = { publisherId = “com.solar2d” },
TO
[“plugin.google.iap.billing.v13”] = { publisherId = “com.solar2d” },
???
Still problem exists.

#28

@colinmorgan After deleting everything in SpriteTiles, I also received a black screen and the problem does NOT occur. :slight_smile:

What does this mean?

#29

So the crashing on launch starts with 3707? OK.

#30

This was a side issue so you could build with 3706 and at least be in compliance with the new billing requirements.

["plugin.google.iap.billing.v2"] =
	{
	publisherId = "com.solar2d",
	version = "v13",
	},
#31

Well, it means that the simulator is successfully parsing config.lua and build.settings, because even if main.lua is blank, both of those files are read by the simulator.

Next step: Into your blank main.lua file, add

print( "logging" )

and see what happens.

If that works, restore SpriteTiles main.lua to its original form and put a print statement on line 7 (before anything actually occurs) and see what happens.

#32

After trying all of these things (except v13) as @colinmorgan has it, the problem disappeared. I can run SpriteTiles, and I can run my own app. This tells me that one of the things we’ve done somehow changed something on my system to make it work. I’m not satisfied leaving this as a mystery, so I’ve removed 3707 & 3709, then restarted my computer. I then installed 3709 again and it still works. I cleared the sandbox and it still works. CONCLUSION: One of the last 3 things I tried above, did something that caused a system fix for Corona Simulator’s benefit. My educated guess is turning on the checkbox to Open using Rosetta fixed it so that even with the checkbox now off, the problem is resolved. But it’s just a guess, still, since I can’t duplicate the problem and solution. Thank you to @colinmorgan and @clang for your help! Seriously, thank you :slight_smile:

#33

:tada::tada::tada:
Great News.

#34

Glad to hear the problem is no longer happening.

My guess is that the resolution of xcprivacy, or the introduction of the x86_64 toolchain in API34 may affect the Solar2D Simulator running on Mac with arm64 architecture chips.

Anyway, feel free to continue exploring Solar2D.

1 Like
#35

This problem has restarted again. No amount of restarting or toggling Rosetta is working; so there is something else incompatible with my system and Solar2D in that is causes Lua to fatally crash before allowing my code to startup.

Even Solar2D Sample Code results in the same Lua issue.

This must be fixed and I remain available to try anything.

#36

I think it’s safe to say that the problem has something to do with your computer. Have you considered making an appointment at your local Apple Store to see if one of the geniuses can help?

#37

100% of everything works on my computer. The only issue I’ve ever had, now twice, is related to a LUA issue running on my system. Is there any way to capture what issue occurs causing LUA to Crash even before running the first line of my own LUA code?

#38

One way to get richer information is to debug Solar2D Simulator using source code, i.e., open the platform/mac/ratatouille.xcodeproj project and debug rttplayer target using Xcode and trace all the called software and scripts step by step.
Debugging requires a little knowledge of Mac software development and shell scripting, and the good thing is that there’s a lot of Lua scripting involved.

But in other words, I would recommend that you use another Mac to see if there is a problem, or try to create a freshly installed Mac system on your computer via virtual machine software, and consider reinstalling your system once the problem no longer occurs. Please make a backup before reinstalling your system, I am not responsible for that action.

#39

My point is that you have a problem that no one else has. Furthermore, that problem briefly went away and then returned just as mysteriously. Nothing about Solar2D changed during that time. What changed was something on your computer.
For example, maybe some other program you run modifies a shared library that Solar2D uses in a way that causes it to not work. In this hypothetical scenario, you got Solar2D to work again by completely clearing it out, reinstalling it from scratch, fiddling with Rosetta, etc., and it worked fine until you ran whatever program it was that modifies a shared library. Then, next time you launch Solar2D, suddenly it doesn’t work.
Part of the 3707 release was upgrading to Xcode 15.3, so there was definitely work done on the Mac portion of the code. That undoubtedly was the trigger for whatever conflict is occurring on your machine, but based on all the evidence we have, this problem is limited to your machine. Hence my suggestion that you have someone look at your computer. Maybe someone looking at your specific computer could point to a potential conflict. All the rest of us can do is say, “It works for me, have you tried X?”

1 Like
#40

@colinmorgan That’s good reasoning thank you for your help. How do you suggest that I’ll make an appointment at the Apple Store.

#42

I’ve opened the Simulator directly and then my project and it runs perfect. The entire problem appears related to the fact that the > button on ZeroBrane must startup the simulator improperly. Could this be a permissions issue? If not, what must I change to get the > button to work again in ZeroBrane Studio?

#43

Execuse me? Do you mean that using ZeroBrane from the start instead of launching directly from Simulator causes it to not work? And yet launching directly from Simulator has always worked fine?
Thanks.