Subject: [ANN] Lua 5.5.1 (rc1) now available

[Luiz Henrique de Figueiredo]

Lua 5.5.1 (rc1) is now available for testing at
https://www.lua.org/work/lua-5.5.1-rc1.tar.gz

The SHA256 checksum is
c1dbdbb5be08bbd0589edd786b8878620a05cba09cbcc4275e65d1f384ef18e6  -

The Git commit ID is
84938a7d2b680d2d28ec99606e84fe712efd9a69

Lua 5.5.1 fixes all bugs listed in
https://www.lua.org/bugs.html#5.5.0

The complete diffs from Lua 5.5.0 are available at
https://www.lua.org/work/diffs-lua-5.5.0-lua-5.5.1.html
https://www.lua.org/work/diffu-lua-5.5.0-lua-5.5.1.html

We thank everyone for their feedback on Lua 5.5 till now.

All feedback welcome. Thanks.
--lhf

[Christophe Delord]

Le 15/07/2026 à 22:53, Luiz Henrique de Figueiredo a écrit :

Lua 5.5.1 (rc1) is now available for testing at
https://www.lua.org/work/lua-5.5.1-rc1.tar.gz

All feedback welcome. Thanks.
--lhf

Hello,

Lua 5.5.1-rc1 passes all LuaX tests but there are some undefined behaviours detected by UBSan.

E.g.:

make MYCFLAGS="-fsanitize=address -fsanitize=undefined" MYLDFLAGS="-fsanitize=address -fsanitize=undefined"
src/lua -v

produces:

lua-5.5.1/src/lstate.c:352:14: runtime error: member access within misaligned address 0x7d51507e0608 for type 'union GCUnion', which requires 16 byte alignment
0x7d51507e0608: note: pointer points here
 be be be be  be be be be be be be be  08 08 01 00 be be be be  be be be be be be be be  80 00 7e 50
              ^ 
lua-5.5.1/src/lstate.c:201:3: runtime error: member access within misaligned address 0x7d51507e0608 for type 'union GCUnion', which requires 16 byte alignment
0x7d51507e0608: note: pointer points here
 be be be be  00 00 00 00 00 00 00 00  08 08 01 00 be be be be  90 00 7e 50 11 7d 00 00  80 00 7e 50
              ^ 
Lua 5.5.1  Copyright (C) 1994-2026 Lua.org, PUC-Rio
lua-5.5.1/src/lgc.c:443:3: runtime error: member access within misaligned address 0x7d51507e0608 for type 'union GCUnion', which requires 16 byte alignment
0x7d51507e0608: note: pointer points here
 be be be be  00 00 00 00 00 00 00 00  08 08 01 00 be be be be  c0 00 7e 50 11 7d 00 00  80 00 7e 50
              ^ 
lua-5.5.1/src/lgc.c:140:29: runtime error: member access within misaligned address 0x7d51507e0608 for type 'union GCUnion', which requires 16 byte alignment
0x7d51507e0608: note: pointer points here
 be be be be  00 00 00 00 00 00 00 00  08 08 01 00 be be be be  c0 00 7e 50 11 7d 00 00  80 00 7e 50
              ^ 
lua-5.5.1/src/lgc.c:168:30: runtime error: member access within misaligned address 0x7d51507e0608 for type 'union GCUnion', which requires 16 byte alignment
0x7d51507e0608: note: pointer points here
 be be be be  00 00 00 00 00 00 00 00  08 08 01 00 be be be be  c0 00 7e 50 11 7d 00 00  80 00 7e 50
              ^ 
lua-5.5.1/src/lgc.c:367:7: runtime error: member access within misaligned address 0x7d51507e0608 for type 'union GCUnion', which requires 16 byte alignment
0x7d51507e0608: note: pointer points here
 be be be be  00 00 00 00 00 00 00 00  08 08 01 00 be be be be  c0 00 7e 50 11 7d 00 00  80 00 7e 50
              ^ 
lua-5.5.1/src/lgc.c:737:48: runtime error: member access within misaligned address 0x7d51507e0608 for type 'union GCUnion', which requires 16 byte alignment
0x7d51507e0608: note: pointer points here
 be be be be  00 00 00 00 00 00 00 00  08 20 01 00 be be be be  c0 00 7e 50 11 7d 00 00  80 00 7e 50
              ^ 
lua-5.5.1/src/lgc.c:1148:20: runtime error: member access within misaligned address 0x7d51507e0608 for type 'union GCUnion', which requires 16 byte alignment
0x7d51507e0608: note: pointer points here
 be be be be  00 00 00 00 00 00 00 00  08 24 01 00 be be be be  c0 00 7e 50 11 7d 00 00  80 00 7e 50
              ^ 
lua-5.5.1/src/lgc.c:1149:9: runtime error: member access within misaligned address 0x7d51507e0608 for type 'union GCUnion', which requires 16 byte alignment
0x7d51507e0608: note: pointer points here
 be be be be  00 00 00 00 00 00 00 00  08 24 01 00 be be be be  c0 00 7e 50 11 7d 00 00  80 00 7e 50
              ^ 
lua-5.5.1/src/lgc.c:1536:3: runtime error: member access within misaligned address 0x7d51507e0608 for type 'union GCUnion', which requires 16 byte alignment
0x7d51507e0608: note: pointer points here
 be be be be  00 00 00 00 00 00 00 00  08 04 01 00 be be be be  90 00 7e 50 11 7d 00 00  80 00 7e 50
              ^ 

Regards,

Christophe.

[Luiz Henrique de Figueiredo]

> Lua 5.5.1-rc1 passes all LuaX tests but there are some undefined behaviours detected by UBSan.

Are these undefined behaviours absent in Lua 5.5.0?
--lhf

[Christophe Delord]

There are no such undefined behaviours in Lua 5.5.0.

[Christophe Delord]

Here is a patch in lstate.h that seems to fix these UBs:


/*
** Type used only to capture, via 'LUAI_MAXALIGN' (see luaconf.h), the
** strictest alignment that Lua objects may require (e.g., because
** 'struct Udata' embeds 'LUAI_MAXALIGN' and is itself a member of
** 'union GCUnion'). Used below to keep 'LX.l' correctly aligned.
*/
typedef union { LUAI_MAXALIGN; } L_Umaxalign;

#define MAX(a, b) ((a) > (b) ? (a) : (b))

/*
** thread state + extra space
*/
typedef struct LX {
  lu_byte extra_[MAX(LUA_EXTRASPACE, sizeof(L_Umaxalign))];
  lua_State l;
} LX;

[Christophe Delord]

or :

/*
** thread state + extra space + alignment
*/
typedef struct LX {
  lu_byte extra_[LUA_EXTRASPACE];
  union {
    union { LUAI_MAXALIGN; } dummy_align_;
    lua_State l;
  };
} LX;

[Roberto Ierusalimschy]

> Le 15/07/2026 à 22:53, Luiz Henrique de Figueiredo a écrit :
> > Lua 5.5.1 (rc1) is now available for testing at
> > https://www.lua.org/work/lua-5.5.1-rc1.tar.gz
> >
> > All feedback welcome. Thanks.
> > --lhf
>
> Hello,
>
> Lua 5.5.1-rc1 passes all LuaX tests but there are some undefined behaviours
> detected by UBSan.
>

> [...]

>
> lua-5.5.1/src/lstate.c:352:14: runtime error: member access within
> misaligned address 0x7d51507e0608 for type 'union GCUnion', which requires
> 16 byte alignment
> 0x7d51507e0608: note: pointer points here
>  be be be be  be be be be be be be be  08 08 01 00 be be be be  be be be be
> be be be be  80 00 7e 50
>               ^

> [...]

I believe gcc is being overzealous here and possibly breaking the C
standard. The standard says this:

"A pointer to a union object, suitably converted, points to each of
its members [...], and vice versa."

So, if a member is an int, it should be valid to convert a pointer to
int (with its 4-byte alignment) to a pointer to the union, and then
convert it back to a pointer to int.

-- Roberto

[Roberto Ierusalimschy]

> Le 15/07/2026 à 22:53, Luiz Henrique de Figueiredo a écrit :
> > Lua 5.5.1 (rc1) is now available for testing at
> > https://www.lua.org/work/lua-5.5.1-rc1.tar.gz
> >
> > All feedback welcome. Thanks.
> > --lhf
>
> Hello,
>
> Lua 5.5.1-rc1 passes all LuaX tests but there are some undefined behaviours
> detected by UBSan.
>

> [...]

And thanks for the feedback :-)

-- Roberto

[Berwyn Hoyt]

> lua-5.5.1/src/lstate.c:352:14: runtime error: member access within
> misaligned address 0x7d51507e0608 for type 'union GCUnion', which requires
> 16 byte alignment
> 0x7d51507e0608: note: pointer points here
>  be be be be  be be be be be be be be  08 08 01 00 be be be be  be be be be
> be be be be  80 00 7e 50
>               ^
> [...]

I believe gcc is being overzealous here and possibly breaking the C
standard.  The standard says this:

   "A pointer to a union object, suitably converted, points to each of
    its members [...], and vice versa."

So, if a member is an int, it should be valid to convert a pointer to
int (with its 4-byte alignment) to a pointer to the union, and then
convert it back to a pointer to int.

I see a possible flaws with your reasoning:

• Firstly in the abstract: regarding what the standard says, if a hypothetical union contains, for example, both a (4-byte) int and an (8-byte) pointer, then it must be 8-byte aligned to work with the pointer, even if it only needs 4-byte alignment to work with the int. Such a union would be 8-byte aligned and the statement you quote from the standard would be true. The reverse, however, does not follow from the standard: you cannot necessarily take an arbitrary int pointer (which may be 4-byte aligned) and convert it to the union (because that must be 8-byte aligned). So the standard is not infringed.
• In this particular case, all of GCUnion's members begin with CommonHeader, whose first entry is a pointer (*next), and pointers must be 8-byte aligned (on a 64-bit machine). So converting an arbitrary 4-byte aligned int to GCUnion, as was done here, is illegal in case you actually use the union as GCUnion. I guess the compiler isn't clever enough to work out that you're going to convert the GCUnion back to an int without using it as a GCUnion.

Cheers,

Berwyn

[Martin Eden]

On 2026-07-15 22:53, Luiz Henrique de Figueiredo wrote:
> Lua 5.5.1 (rc1) is now available for testing at
> https://www.lua.org/work/lua-5.5.1-rc1.tar.gz

Congratulations with release! (I still admire your admittance of bugs.)

Lua 5.5.1 (as many previous versions) sometimes produces bytecode
with unreachable instructions. (At least I don't understand
how they can be reached.)

For example "local f = function() end; return f;":

  > $ echo 'local f = function() end; return f;' | luac -p -l -s -
  >
  > main <stdin:0,0> (4 instructions at 0x5626f1974b30)
  > 0+ params, 2 slots, 1 upvalue, 1 local, 0 constants, 1 function
  >   1 [1] VARARGPREP  0
  >   2 [1] CLOSURE   0 0 ; 0x5626f1974e20
  >   3 [1] RETURN    0 2 1 ; 1 out
  >   4 [1] RETURN    1 1 1 ; 0 out
  >
  > function <stdin:1,1> (1 instruction at 0x5626f1974e20)
  > 0 params, 2 slots, 0 upvalues, 0 locals, 0 constants, 0 functions
  >   1 [1] RETURN0
  >

"RETURN 1 1 1" looks unreachable and dead code.

(I understand that's code generation quirk and code generation
is not simple thing.)

I hope dead bytecode will be reduced in future Lua versions.

-- Martin

[Andrey Dobrovolsky]

Hi Martin,

> For example "local f = function() end; return f;":

it seems to me that this source code already includes unreachable
code. Should code generator provide code analyser's functionality?

Regards,
-- Andrew


пт, 17 лип. 2026 р. о 22:38 'Martin Eden' via lua-l
<lu...@googlegroups.com> пише:

> --
> You received this message because you are subscribed to the Google Groups "lua-l" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/lua-l/7a3bc6d6-84e5-445d-80f4-d0c800aab0c8%40disroot.org.

[TopchetoEU]

> --
> You received this message because you are subscribed to the Google Groups
> "lua-l" group. To unsubscribe from this group and stop receiving emails
> from it, send an email to lua-l+un...@googlegroups.com. To view this
> discussion visit
> https://groups.google.com/d/msgid/lua-l/7a3bc6d6-84e5-445d-80f4-d0c800aab0c
> 8%40disroot.org.

AFAIK the lua compiler is made to be as dumb and simple as possible, so it can
be as fast as possible. Hence, no CFG and SSA analysis exists, which are the
only reliable methods of eliminating dead code paths.

On another side, the dead path you're seeing is the lua compiler putting a
virtual "return" statement on the end of the chunk. I presume this is done so
that a bound check in the VM loop is avoided, as the VM loop is a quite
critical section of the lua interpreter.

A tool that does said CFG optimizations on the lua bytecode level could quite
easily be made IMHO, it is a matter of building a node of instructions and
"shaking" it, and finally reconstructing it. However, 1. the compiler never
actually runs those instructions, so they don't impede performance, and 2. the
amount of dead code is negligible, so memory concerns are irrelevant here as
well.