LuaJIT and C++ exception

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

LuaJIT and C++ exception

Andrea
Hi,

I'm going back to the common topic of C++ exceptions.

I'm using VS 2005 x86.

Basically I register a C++ function with lua_pushcclosure.
This function does not throw, since it contains a try catch like the one suggested here

http://luajit.org/api.html

What happens is the following

pcall

from lua call c closure
throw something
catch (...)
lua_pushstring
lua_error
....
.... back into lua
....
back in pcall which returns a non zero value

and I then throw a new C++ exception (caught higher in the stack in my app).

The problem is that Visual Studio reports that the 2nd exception is unhandled and basically ignores it.

This works fine with Lua (non jit).
The only way to make it work with lua jit is to ensure that the function calling lua_error does not
contain any try{}catch{} block.
It must be handled by an other function which can signal success or error via standard c methods
(e.g. the return code).
As soon as lua_error is in a function that contains try{}catch{} it fails. Mind you, lua_error is
*outside* the try{}catch{}, *not* in the catch, but still in the same function (like the link above).

Havent tried in linux yet.

Am I talking nonsense?

Andrea


Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT and C++ exception

Mike Pall-20
Andrea wrote:
> The problem is that Visual Studio reports that the 2nd exception
> is unhandled and basically ignores it.
>
> This works fine with Lua (non jit).

Well, looks like the SEH chains got messed up on Windows/x86. :-(

Lua uses setjmp/longjmp from MSVC. Even though MSDN suggests that
mixing this with C++ exceptions is not safe, the longjmp from MSVC
cleans up the SEH chain. But I can't use setjmp/longjmp in LuaJIT.

As a workaround I tried manual unwinding of SEH chains, but that
didn't work at all. Neither does RtlUnwind() do the right thing on
x86 in this case. So I don't think I can provide an out-of-the-box
solution for this in LuaJIT.

> As soon as lua_error is in a function that contains try{}catch{}
> it fails. Mind you, lua_error is *outside* the try{}catch{},
> *not* in the catch, but still in the same function (like the
> link above).

MSVC optimizes functions with try/catch constructs by adding a
single SEH frame for the whole function. So even if you use
lua_error() outside of the catch, there's still an SEH frame
around it which needs to be cleaned up.

Your options are:
- Wrap the try/catch in a separate C++ function declared as
  __declspec(noinline). Call that from a function without
  try/catch and then run lua_error() from there.
- Use either Linux or Windows/x64 which have much better C++
  exception handling interoperability.

--Mike

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT and C++ exception

Andrea
On 18/10/10 14:48, Mike Pall wrote:
> Andrea wrote:
>> The problem is that Visual Studio reports that the 2nd exception
>> is unhandled and basically ignores it.
>>
>> This works fine with Lua (non jit).
>
> Well, looks like the SEH chains got messed up on Windows/x86. :-(

I thought it was something like that. No idea though how it works.

>
> Lua uses setjmp/longjmp from MSVC. Even though MSDN suggests that
> mixing this with C++ exceptions is not safe, the longjmp from MSVC
> cleans up the SEH chain. But I can't use setjmp/longjmp in LuaJIT.

At some point I even tried to compile LuaJIT as C++ with a long list of compiler errors, and I
suspect it is not the right thing to do.

>
> Your options are:
> - Wrap the try/catch in a separate C++ function declared as
>   __declspec(noinline). Call that from a function without
>   try/catch and then run lua_error() from there.
> - Use either Linux or Windows/x64 which have much better C++
>   exception handling interoperability.
>

In the end I have 3 functions

1) the original C++ function that throws
2) a wrapper that convert exceptions into c-style return code
3) the actual function calling 2+1 and lua_error

with a macro steps 2 and 3 are hidden from the developer and
I did not notice any measurable speed change.

Thanks


Reply | Threaded
Open this post in threaded view
|

precompiled code problem in 5.1.4

Michael Newberry
In reply to this post by Mike Pall-20
We updated to Lua 5.1.4 and our Windows app fails trying to load a
pre-compiled lua library. Specifically, luaL_loadfile() returns 3 and the
error message is "bad header in precompiled chunk". This library was created
using luac.exe dated March 19 2004 (114,688 bytes). I found a reference to
what may be the same issue posted by David Manura on 22 Sep 2010. Does
anyone know a workaround?

Thanks,

Michael



Reply | Threaded
Open this post in threaded view
|

Re: precompiled code problem in 5.1.4

Peter Cawley
On Sat, Oct 23, 2010 at 7:17 PM, Michael Newberry
<[hidden email]> wrote:
> We updated to Lua 5.1.4 and our Windows app fails trying to load a
> pre-compiled lua library. Specifically, luaL_loadfile() returns 3 and the
> error message is "bad header in precompiled chunk". This library was created
> using luac.exe dated March 19 2004 (114,688 bytes). I found a reference to
> what may be the same issue posted by David Manura on 22 Sep 2010. Does
> anyone know a workaround?

What did you update *from* ?

Precompiled code is tied to the Lua version (e.g 5.0 or 5.1) that it
was compiled for, the machine endianness, the lua_Number type, and
sizes of some fundamental types (e.g. sizeof(int), sizeof(size_t)). If
any of these things differ between where the code was compiled and
where the precompiled code is loaded, then the loading will fail with
the message you gave.

Reply | Threaded
Open this post in threaded view
|

Re: precompiled code problem in 5.1.4

Luiz Henrique de Figueiredo
In reply to this post by Michael Newberry
> We updated to Lua 5.1.4 and our Windows app fails trying to load a
> pre-compiled lua library. Specifically, luaL_loadfile() returns 3 and the
> error message is "bad header in precompiled chunk". This library was created
> using luac.exe dated March 19 2004 (114,688 bytes).

Given the date of your luac.exe, it's definitely not Lua 5.1. So the message
is saying (but not too clearly) that you have the wrong version. Precompiled
Lua scripts can only be loaded in the same version of Lua with which they were
created. Did you lose the original source files?

Reply | Threaded
Open this post in threaded view
|

RE: precompiled code problem in 5.1.4

Michael Newberry
Luiz and Peter,

Thanks to both of you for your quick responses. That description makes
sense. After updating to 5.1.4, I didn't think about the compiler changing
as well. I have just created a new luac.exe from 5.1.4 and everything works.
Thanks again!

Michael


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Luiz Henrique de Figueiredo
Sent: Saturday, October 23, 2010 11:44 AM
To: Lua mailing list
Subject: Re: precompiled code problem in 5.1.4

> We updated to Lua 5.1.4 and our Windows app fails trying to load a
> pre-compiled lua library. Specifically, luaL_loadfile() returns 3 and the
> error message is "bad header in precompiled chunk". This library was
created
> using luac.exe dated March 19 2004 (114,688 bytes).

Given the date of your luac.exe, it's definitely not Lua 5.1. So the message
is saying (but not too clearly) that you have the wrong version. Precompiled
Lua scripts can only be loaded in the same version of Lua with which they
were
created. Did you lose the original source files?