Re: unprotected error in call to Lua API (13)

[Élie Michel <elie.michel@...>]

Thanks all for your answers!

Dirk,

Torch is a computing library: https://github.com/torch/torch7
I precise this because it my be the Torch backend, which is interacting
with the GPU and managing its memory by itself, that makes thing go wrong.

I put the "Errors" lines in my sample code by habit, but as Philipp
pointed out after that, these line are not the one printing my error.


Philipp,

Good catch! This is indeed a PANIC error. I actually though that the
"PANIC" keyword was added but the framework I am writing a plugin for,
hence I did not precise it.

What made me come to the list is that in the most typical cases, the
mention after "unprotected error in call to Lua API" is an error
description, not an error code. So "13" is… some kind of description!

Thanks for pointing me out the files to look at, I will try to put a
breakpoint and debug that. (I use LuaJIT, so `lib_aux.c`.)

I will also look at the `lua_CFunction` trick, but my interaction is
quite simple:

1. I run the script one to define the globals
2. I fill my input object, which is a Torch object and can be handled in
C directly.
3. I get the main loop function from the globals, push my Torch object
and call it
4. I get the result (Torch object too)
5. I go to 2.


Thanks,
Élie

Le 08/10/2015 05:38, Philipp Janda a écrit :
> Am 08.10.2015 um 09:12 schröbte Dirk Laurie:
>> 2015-10-08 0:36 GMT+02:00 Elie Michel <elie.michel@exppad.com>:
>>> I have at the beginning something like this:
>>>
>>>      if (luaL_loadfile(L, "test.lua") || lua_pcall(L, 0, 0, 0)) {
>>>          cout << "Error: " << lua_tostring(L, -1) << endl;
>>>      }
>>> ...
>>> if (lua_pcall(L, 1, 0, 0)) {
>>>         cout << "Error: " << lua_tostring(L, -1) << endl;
>>>    }
>>
>> The error code for luaL_loadfile can only be 2,4 or 6 and for lua_pcall
>> 2,4 or 6 so 13 does not come from here.
>>
>> Find other places in your code with "Error:"
> 
> If I interpret the subject (unprotected error in call to Lua API)
> correctly, the error happens *outside* of every `pcall`. So it's the
> `panic` function in `lauxlib.c` (`lib_aux.c` in case of LuaJIT) which is
> printing the error message, not the OP. The good news is that you can
> put a debugger break point on `panic` (or `exit`) and see in the
> backtrace where the error is thrown. "13" is a strange error message
> though, so I suspect that the Lua stack gets messed up somehow in the
> loop. Maybe a Lua(JIT) library with API checks enabled
> (`-DLUA_USE_APICHECK`) can shed some light ...
> 
> Anyway, unprotected errors smell bad, so I recommend putting (almost)
> all interaction with the Lua API into a `lua_CFunction` that is called
> via `lua_cpcall`. See the source code of the Lua interpreter (`lua.c`)
> for an example.
> 
> HTH,
> Philipp
> 
> 
> 
>

Attachment: signature.asc
Description: OpenPGP digital signature