[ANN] Lua 5.4.0 now available

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

Re: [ANN] Lua 5.4.0 now available

Gé Weijers
On Wed, Jul 1, 2020 at 10:10 AM Ką Mykolas <[hidden email]> wrote:
>
> Disasm might be nice of the relevant section

You can generate one using this command (with gcc 10.1.0)

gcc -std=gnu99 -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_LINUX
-Wa,-adhln -c -g lobject.c > lobject.lst

With the inline substitution enabled it's really hard to figure out
what's going on.



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Roberto Ierusalimschy
In reply to this post by Pierre Chapuis
> > If you add this print in 'addnum2buff' instead, does the crash also
> > disapear?
>
> No. It prints something (e.g. 0x7ffdb5514fb0) and then it crashes.

I am afraid I didn't ask what I wanted :-)  What I meant was to print
the value of 'numbuff' in 'addnum2buff' (not 'buff'); that is the value
that becomes 'buff' in 'tostringbuff'. Better still if you could print
both values ('numbuff' and 'buff' in 'addnum2buff').

Many thanks,

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Gé Weijers
In reply to this post by Gé Weijers
On Wed, Jul 1, 2020 at 9:43 AM Gé Weijers <[hidden email]> wrote:
> I'll build the tip of the release/gcc-10 branch. That'll take a good
> while on my slow machine. Perhaps this issue has been fixed, there are
> lots of bug fix commits in that branch post 10.1.

BTW: the crash still happens.


--

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Pierre Chapuis
In reply to this post by Roberto Ierusalimschy
On Wed, Jul 1, 2020, at 21:10, Roberto Ierusalimschy wrote:

> I am afraid I didn't ask what I wanted :-)  What I meant was to print
> the value of 'numbuff' in 'addnum2buff' (not 'buff'); that is the value
> that becomes 'buff' in 'tostringbuff'. Better still if you could print
> both values ('numbuff' and 'buff' in 'addnum2buff').

[lua-5.4.0 08:07] ./src/lua -e "tostring(1.0)"
buff: 0x7ffe557f6140, numbuff: 0x7ffe557f6150
Bus error (core dumped)
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Matěj Cepl
In reply to this post by Luiz Henrique de Figueiredo
On 2020-06-29, 18:39 GMT, Luiz Henrique de Figueiredo wrote:
> Lua 5.4.0 has been frozen and is now the current version of Lua.

When trying to build Lua 5.4 for openSUSE (with running the test
suite from https://www.lua.org/tests/) we hit one failing test
(the full log is on https://is.gd/pFDvtp):

[   65s] ***** FILE 'files.lua'*****
[   65s] testing i/o
[   65s] /home/abuild/rpmbuild/BUILDROOT/lua54-5.4.0-134.1.x86_64/usr/bin/lua5.4: files.lua:84: assertion failed!
[   65s] stack traceback:
[   65s] [C]: in function 'assert'
[   65s] files.lua:84: in main chunk
[   65s] (...tail calls...)
[   65s] all.lua:205: in main chunk
[   65s] [C]: in ?
[   65s] .>>> closing state <<<

Anybody any idea, what’s going on? Also, how do I make one test
to be skipped?

Best,

Matěj

--
https://matej.ceplovi.cz/blog/, Jabber: [hidden email]
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
The truth is a beautiful and terrible thing, and should therefore
be treated with caution.
  -- Albus Dumbledore

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Roberto Ierusalimschy
In reply to this post by Pierre Chapuis
> > I am afraid I didn't ask what I wanted :-)  What I meant was to print
> > the value of 'numbuff' in 'addnum2buff' (not 'buff'); that is the value
> > that becomes 'buff' in 'tostringbuff'. Better still if you could print
> > both values ('numbuff' and 'buff' in 'addnum2buff').
>
> [lua-5.4.0 08:07] ./src/lua -e "tostring(1.0)"
> buff: 0x7ffe557f6140, numbuff: 0x7ffe557f6150
> Bus error (core dumped)

Thanks.

That is one more point in favor of a compiler bug. After this print,
numbuff is simply passed as an argument to tostringbuff, and suddenly
its value changes from 0x7ffe557f6150 (or 0x7fffffffd850, in the trace
you sent earlier) to 0x3ff0000000000000.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

François Perrad
In reply to this post by Luiz Henrique de Figueiredo


Le lun. 29 juin 2020 à 20:39, Luiz Henrique de Figueiredo <[hidden email]> a écrit :
Lua 5.4.0 has been frozen and is now the current version of Lua.

Lua 5.4.0 is available at
        http://www.lua.org/ftp/lua-5.4.0.tar.gz

The checksums are
        MD5     dbf155764e5d433fc55ae80ea7060b60  -
        SHA1    8cdbffa8a214a23d190d7c45f38c19518ae62e89  -

The reference manual is available at
        http://www.lua.org/manual/5.4/

For installation and building instructions, see
        http://www.lua.org/manual/5.4/readme.html

The complete source code of Lua 5.4.0 is available for browsing at
        http://www.lua.org/source/5.4/

We thank everyone for their feedback on Lua 5.4.

All feedback welcome. Thanks.

luaL_buffsub and luaL_pushfail are missing.

François
 
--lhf
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Luiz Henrique de Figueiredo
> could you regenerate https://www.lua.org/manual/contents.html,
> luaL_buffsub and luaL_pushfail are missing.

Done. Thanks for the report.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Joseph C. Sible
In reply to this post by Roberto Ierusalimschy
On Thu, Jul 2, 2020 at 1:35 PM Roberto Ierusalimschy
<[hidden email]> wrote:

>
> > > I am afraid I didn't ask what I wanted :-)  What I meant was to print
> > > the value of 'numbuff' in 'addnum2buff' (not 'buff'); that is the value
> > > that becomes 'buff' in 'tostringbuff'. Better still if you could print
> > > both values ('numbuff' and 'buff' in 'addnum2buff').
> >
> > [lua-5.4.0 08:07] ./src/lua -e "tostring(1.0)"
> > buff: 0x7ffe557f6140, numbuff: 0x7ffe557f6150
> > Bus error (core dumped)
>
> Thanks.
>
> That is one more point in favor of a compiler bug. After this print,
> numbuff is simply passed as an argument to tostringbuff, and suddenly
> its value changes from 0x7ffe557f6150 (or 0x7fffffffd850, in the trace
> you sent earlier) to 0x3ff0000000000000.
>
> -- Roberto

Looks like a compiler bug to me too. Here's a minimized example:
https://godbolt.org/z/RMc3RX

I reported it to GCC's bug tracker:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96040

Joseph C. Sible
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Andrew Gierth
>>>>> "Joseph" == Joseph C Sible <[hidden email]> writes:

 >> That is one more point in favor of a compiler bug. After this print,
 >> numbuff is simply passed as an argument to tostringbuff, and
 >> suddenly its value changes from 0x7ffe557f6150 (or 0x7fffffffd850,
 >> in the trace you sent earlier) to 0x3ff0000000000000.

 Joseph> Looks like a compiler bug to me too. Here's a minimized example:
 Joseph> https://godbolt.org/z/RMc3RX

 Joseph> I reported it to GCC's bug tracker:
 Joseph> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96040

I think I see what's happening here, but I don't think I have an account
on the gcc bug tracker to post it there (feel free to forward this).
It's not (I think) a confusion over how many arguments the specialized
tostringbuff.part.0.isra function has, but rather over the type, or
equivalently the register allocation, for the first parameter.

The callsite is putting num->value_.n into %rdi, and &space into %rsi,
as if the function were declared as taking (long long v, char *buf)
rather than (double v, char *buf) which would require that num->value_.n
be placed in %xmm0 and &space into %rdi.

But the code of the function itself is assuming that the incoming values
are in %xmm0 and %rdi - %xmm0 is not touched because it's already in the
right place for the snprintf call, while %rdi is left as the first arg
to snprintf. The value 0x3ff0000000000000 is of course 1.0 as a double,
which naturally does not work well as a pointer so it blows up.

--
Andrew.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Fontana Nicola
In reply to this post by Joseph C. Sible
Il giorno gio, 02/07/2020 alle 17.24 -0400, Joseph C. Sible ha scritto:
> ...
> Looks like a compiler bug to me too. Here's a minimized example:
> https://godbolt.org/z/RMc3RX
> ...

One can always define the argument as `volatile` to avoid optimization
blunders, e.g. the following change will make that code work again:

    static int tostringbuff (volatile struct TValue *num, char *str)

No idea if this is C89 compliant though.

Ciao.
--
Nicola

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Soni "They/Them" L.
In reply to this post by Luiz Henrique de Figueiredo


On 2020-06-29 3:39 p.m., Luiz Henrique de Figueiredo wrote:

> Lua 5.4.0 has been frozen and is now the current version of Lua.
>
> Lua 5.4.0 is available at
> http://www.lua.org/ftp/lua-5.4.0.tar.gz
>
> The checksums are
> MD5 dbf155764e5d433fc55ae80ea7060b60  -
> SHA1 8cdbffa8a214a23d190d7c45f38c19518ae62e89  -
>
> The reference manual is available at
> http://www.lua.org/manual/5.4/
>
> For installation and building instructions, see
> http://www.lua.org/manual/5.4/readme.html
>
> The complete source code of Lua 5.4.0 is available for browsing at
>          http://www.lua.org/source/5.4/
>
> We thank everyone for their feedback on Lua 5.4.
>
> All feedback welcome. Thanks.
> --lhf

Yay!
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Andrew Gierth
In reply to this post by Fontana Nicola
>>>>> "Fontana" == Fontana Nicola <[hidden email]> writes:

 Fontana> One can always define the argument as `volatile` to avoid
 Fontana> optimization blunders, e.g. the following change will make
 Fontana> that code work again:

But how many other places are likely to fall foul of the same
optimization? Not to mention the fact that you're then pessimizing the
code for compilers that _don't_ have the bug.

See aux_close in liolib.c for why this is a bad idea - a workaround for
a long-obsolete clang version has become perpetuated in the code for no
reason.

The option -fno-ipa-sra works around the bug if you have the broken GCC
version (the fix is already committed); better to do it that way.

--
Andrew.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Matěj Cepl
In reply to this post by Matěj Cepl
Matěj Cepl píše v Čt 02. 07. 2020 v 18:47 +0200:

> When trying to build Lua 5.4 for openSUSE (with running the test
> suite from https://www.lua.org/tests/) we hit one failing test
> (the full log is on https://is.gd/pFDvtp):
>
> [   65s] ***** FILE 'files.lua'*****
> [   65s] testing i/o
> [   65s] /home/abuild/rpmbuild/BUILDROOT/lua54-5.4.0-134.1.x86_64/usr/bin/lua5.4: files.lua:84: assertion failed!
> [   65s] stack traceback:
> [   65s] [C]: in function 'assert'
> [   65s] files.lua:84: in main chunk
> [   65s] (...tail calls...)
> [   65s] all.lua:205: in main chunk
> [   65s] [C]: in ?
> [   65s] .>>> closing state <<<
>
> Anybody any idea, what’s going on? Also, how do I make one test
> to be skipped?
OK, there is more than one test which seems like a problem.

1. In the file attrib.lua I had to apply this patch:

    --- a/lua-5.4.0-tests/attrib.lua
    +++ b/lua-5.4.0-tests/attrib.lua
    @@ -269,7 +269,7 @@ local p = ""   -- On Mac OS X, redefine
     local st, err, when = package.loadlib(DC"lib1", "*")
     if not st then
       local f, err, when = package.loadlib("donotexist", p.."xuxu")
    -  assert(not f and type(err) == "string" and when == "absent")
    +  assert(not f and type(err) == "string" and when == "open")
       ;(Message or print)('\n >>> cannot load dynamic library <<<\n')
       print(err, when)
     else

2. In files.lua (original error I have reported above), I add to
   comment out the assert line in this test (line 84):

   if not _port then   -- invalid seek
     local status, msg, code = io.stdin:seek("set", 1000)
     assert(not status and type(msg) == "string" and type(code) == "number")
   end

    First of all, according to
    https://www.lua.org/manual/5.4/manual.html#pdf-file:seek 
    I don't think seek method returns three values, just two
    (“If seek fails, it returns fail, plus a string describing
    the error.”) What is worse, in this case I get status ==
    0 and msg is nil. I had to comment out this assert line.

3. In the same file there is another test (on line 747):

    for _, v in ipairs(tests) do
        local x, y, z = io.popen(v[1]):close()
        local x1, y1, z1 = os.execute(v[1])
        assert(x == x1 and y == y1 and z == z1)
        if v[2] == "ok" then
          assert(x and y == 'exit' and z == 0)
        else
          print('y = ' .. y)
          print('v[2] = ' .. v[2])
          assert(not x and y == v[2])   -- correct status and 'what'
          -- correct code if known (but always different from 0)
          assert((v[3] == nil and z > 0) or v[3] == z)
        end
      end

Which prints to me this:

    [   41s] sh: not-to-be-found-command: command not found
    [   41s] sh: not-to-be-found-command: command not found
    [   41s] y = exit
    [   41s] v[1] = not-to-be-found-command
    [   41s] v[2] = exit
    [   41s] y = exit
    [   41s] v[1] = exit 3
    [   41s] v[2] = exit
    [   41s] y = exit
    [   41s] v[1] = exit 129
    [   41s] v[2] = exit
    [   41s] y = signal
    [   41s] v[1] = kill -s HUP $$
    [   41s] v[2] = signal
    [   41s] y = signal
    [   41s] v[1] = kill -s KILL $$
    [   41s] v[2] = signal
    [   41s] y = signal
    [   41s] v[1] = sh -c 'kill -s HUP $$'
    [   41s] v[2] = exit
    [   41s] /home/abuild/rpmbuild/BUILDROOT/lua54-5.4.0-0.x86_64/usr/bin/lua5.4: files.lua:748: assertion failed!
    [   41s] stack traceback:
    [   41s] [C]: in function 'assert'
    [   41s] files.lua:748: in main chunk
    [   41s] (...tail calls...)
    [   41s] all.lua:205: in main chunk
    [   41s] [C]: in ?
    [   41s] .>>> closing state <<<

    It seems to me that the when the test fails, it is really
    wrong: $$ in this situation should expand to the PID of the
    inferior process, shouldn’t it? When I comment this one line
    in the tests table, this tests passes.

Any comments?

Thank you very much for any reply,

Best,

Matěj

--
https://matej.ceplovi.cz/blog/, Jabber: [hidden email]
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
I know of no country in which there is so little independence of
mind and real freedom of discussion as in America.
    -- Alexis de Tocqueville


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Roberto Ierusalimschy
> When trying to build Lua 5.4 for openSUSE (with running the test
> suite from https://www.lua.org/tests/) we hit one failing test
> [...]
> Any comments?

Please, read the disclaimers in the page where you got the suite. In
particular:

  * The test suite is not a product; it is just a tool for our internal
    use. It is available here by popular demand but we cannot give any
    kind of support for it. You're on your own.

  * Note that, by its very nature, Lua is heavily dependent on the
    underlying standard C libraries. Sometimes the test suite fails
    because these underlying C libraries do not follow the ANSI
    standard. There is not much we can do about it.

  * The complete test suite (that is, without the _U option) tries
    to test every corner of the language, its libraries, and the C
    API, even corners that are system dependent. Unlike Lua itself,
    these tests do not aim at portability, small footprint, or easy of
    use. Their main goal is to try to crash Lua. They are not intended
    for general use. You are welcome to use them, but expect to get your
    hands dirty.

Thanks,

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 now available

Matěj Cepl
In reply to this post by Matěj Cepl
Matěj Cepl píše v Po 06. 07. 2020 v 18:58 +0200:
> Matěj Cepl píše v Čt 02. 07. 2020 v 18:47 +0200:
> > When trying to build Lua 5.4 for openSUSE (with running the test
> > suite from https://www.lua.org/tests/) we hit one failing test
> > (the full log is on https://is.gd/pFDvtp):

And one more:

on 32bit arch test checkDateTable(0x80000000) on line 794 of
files.lua overflows. I have added this:

@@ -784,6 +784,15 @@ local function checkDateTable (t)
   _G.D = nil
 end
 
+local function is64bit()
+  local arch = io.popen("uname -m"):read("*a")
+  if (arch or ""):match("64") then
+    return 64
+  else
+    return 32
+  end
+end
+
 checkDateTable(os.time())
 if not _port then
   -- assume that time_t can represent these values
@@ -791,7 +800,9 @@ if not _port then
   checkDateTable(1)
   checkDateTable(1000)
   checkDateTable(0x7fffffff)
-  checkDateTable(0x80000000)
+  if is64bit() == 64 then
+      checkDateTable(0x80000000)
+  end
 end
 
 checkerr("invalid conversion specifier", os.date, "%")

And now finally whole test suite passes on all openSUSE-supported
platforms.

Best,

Matěj

--
https://matej.ceplovi.cz/blog/, Jabber: [hidden email]
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
If trains stop at train stations, what happens at work stations?

signature.asc (849 bytes) Download Attachment
12