"Error in error handling"

[borbware]

Has something changed in error handling? In 1.2.2997-dev pro i got this error message when running my game, but in 1.2.2883-dev pro everything works normally.

I use Lua, and the relevant code seems to be on line 98 in ldo.c....

[borbware]

hmm, i traced _VERSION and it differs, it used to be Lua 5.3 but now it's Lua 5.4

[borbware]

Okay, I figured something out. The culprit was this cursed function that I used to convert floats to integers:

function makeint(f)
	return string.format("%.0f",f)|0
end

(Luckily, Lua 5.3+ has a function math.tointeger that can be used instead.)

By running makeint(3.0) in the test cart, I actually got a meaningful error message instead of error in error handling:

[string "-- title:   game 
title..."]:15: attempt to perform 
bitwise operation on a string value
stack traceback:
	[C]: in metamethod 'bor'
	[string "-- title:   game 
title..."]:15: in function 'makeint'
	[string "-- title:   game 
title..."]:21: in function 'TIC'

So, my findings are:

1. I guess when the stack is big enough, you don't get descriptive error messages anymore? Can this be fixed?
2. There are some breaking changes in Lua 5.3->Lua 5.4.

This wasn't the only breaking change I found: After resolving this error, I stumbled upon another similar one. I'll continue my investigations, even though it is quite difficult because I can't see which line the error originated from....

[borbware]

Found another deprecation: math.atan2 is deprecated and should be replaced with math.atan that accepts two arguments now. Apparently this was already deprecated in Lua 5.3 but somehow it still worked before 5.4.

Nothing crashes for now, but I'll continue investigations later...

[Miguel-hrvs]

I thought that the difference between 5.3 to 5.4 was smaller. I'll see if I can fix the error handler. We could also discuss if we want to revert to 5.3.

[nesbox]

I reverted to Lua 5.3, a lot of complaints.
Also, I think if we want 5.4 we need to add it as a separate language, like lua54 or lua+ or something.

[borbware]

Note: Reverting to Lua 5.3 did not fix the error handling, it still only prints "error in error handling" in the current build 3002.

I built the TIC-80 executable with the following options:

$ cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=MinSizeRel -DBUILD_SDLGPU=On -DBUILD_PRO=On .. 
$ mingw32-make -j4

As Lua 5.4 deprecations aren't an issue anymore, I updated the issue title accordingly.

[nesbox]

Hmm, it's strange, maybe try to rebuild, or add --fresh flag to make
cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=MinSizeRel -DBUILD_SDLGPU=On -DBUILD_PRO=On .. --fresh

[borbware]

I used your command, but error in error handling still appears with a fresh rebuild... 🤔

[borbware]

i tried to reproduce the issue with a fresh cart, but somehow i just don't seem to figure out what causes it. In EMUUROM, i just need to do this in main.lua and i get the error:

asdfTIC=function()
	asdfasdf() -- produces the error
end

TIC=asdfTIC

In a fresh cartridge, this does not produce the error! So I guess it's either about

• using require to import files (even though the error happens in non-required file???)
• having a big cartridge in general

Very perplexing.

UPDATE: Okay, it is require that causes it. If I require the same files that I use in EMUUROM, suddenly the error message changes from

>[string "-- title:   game 
title..."]:12: attempt to call a nil 
value (global 'asdfasdf')
stack traceback:
	[C]: in global 'asdfasdf'
	[string "-- title:   game 
title..."]:12: in function 'TIC'

to error in error handling.

[borbware]

Gosh, I'm an idiot. No, it was not require, it was a mishap of my own doing. Namely, these lines:

mode="demo debug"
demo=mode:find("demo")
debug=mode:find("debug")

I'm using this mode string variable to create multiple boolean variables (like demo and debug here), so I can add checks based on the "mode" of my application. HOWEVER, I've chosen the name for one certain boolean very very poorly, because what I'm doing on the third line is effectively overriding the Lua debug library!

So yeah, this isn't really a TIC-80 issue, and this issue can be closed.

Still no idea why it broke the error reporting on the new TIC-80 version, instead of working fine previously, but this is easily fixed on my end by just renaming the variable.

[Miguel-hrvs]

Maybe rare cases like this can happen when optimizing with O3 instead of O2, but that's just an untested possibility.