Bug in Lua 5.0.2

I've been experiencing some random crashes within the Lua interpreter
in code that makes heavy use of coroutines.  I've distilled the
offending code down to the following:

-----------------------------------------------------------------
local thread_id = 0
local threads = {}

function fn(thread)
    thread_id = thread_id + 1
    threads[thread_id] = function()
			     thread = nil
			 end
    coroutine.yield()
end

while true do
    local thread = coroutine.create(fn)
    coroutine.resume(thread, thread)
end
-----------------------------------------------------------------

I've run this code under Windows, using builds from several compilers,
and also under Solaris; the code produces a segfault in under a
second.

Enabling lua assertions shows several failed assertions.  The exact
assertions are sensitive to small changes in the above code; however,
one consistent assertion failure happens at lgc.c, line 222.

Re: Lua 5.1 (work4) now available

On my tests a 10 fold performance difference.

As Mike points out

  #elif defined(_MSC_VER) && defined(_M_IX86)

is better.

Re: Bug in Lua 5.0.2

this executes OK on lua-5.1-work4.

On Fri, 31 Dec 2004 18:07:24 -0700, Spencer Schumann
<gauchopuro <at> gmail.com> wrote:
> I've been experiencing some random crashes within the Lua interpreter
> in code that makes heavy use of coroutines.  I've distilled the
> offending code down to the following:
> 
> -----------------------------------------------------------------
> local thread_id = 0
> local threads = {}
> 
> function fn(thread)
>     thread_id = thread_id + 1
>     threads[thread_id] = function()
>                              thread = nil
>                          end
>     coroutine.yield()
> end
> 
> while true do
>     local thread = coroutine.create(fn)
>     coroutine.resume(thread, thread)
> end
> -----------------------------------------------------------------
> 
> I've run this code under Windows, using builds from several compilers,
> and also under Solaris; the code produces a segfault in under a
> second.
> 

Re: Bug in Lua 5.0.2

I was wondering if it would work on 5.1-work4.  Thanks for checking
that out.  It seems to me that this is a garbage collection bug; my
best theory right now is that the chain of references generated via
upvalues in the code I posted can cause threads to be collected while
references remain.  The other frequent assertion I have seen was in
lfunc.c, line 69, in the function luaF_close.  This function is called
by the garbage collector to clean up a thread.  It appears that the
"openupval" list would sometimes contain corrupted values.

On Sat, 1 Jan 2005 12:23:13 +1000, David Burgess <dburgess <at> gmail.com> wrote:
> this executes OK on lua-5.1-work4.
> 
> On Fri, 31 Dec 2004 18:07:24 -0700, Spencer Schumann
> <gauchopuro <at> gmail.com> wrote:
> > I've been experiencing some random crashes within the Lua interpreter
> > in code that makes heavy use of coroutines.  I've distilled the
> > offending code down to the following:
> >
> > -----------------------------------------------------------------
> > local thread_id = 0
> > local threads = {}
> >
> > function fn(thread)
> >     thread_id = thread_id + 1
> >     threads[thread_id] = function()
> >                              thread = nil
> >                          end
> >     coroutine.yield()
> > end
> >

Re: comparing Lua with other languages

Happy new year to everyone!

I'll try to write simpler code in 2005... so here's a new version of my 
tokens implementation for APLC!  

If no-one complains I'll submit it shortly, it seems to function OK.

--
Wim

-- display short description if no filename is provided
if not arg[1] then
	print("usage: " .. arg[0] .. [[ filename

count the number of tokens in a Lua script file.]])
	return
end

-- total number of tokens
local tokens = 0

-- forward declaration of lexer states
local main, num, multi, quot

-- forward declaration of main token patterns
local patterns

function main(str, index)

Re: comparing Lua with other languages

Wim Couwenberg wrote:
> Happy new year to everyone!

 From me too :-D

Here is my contribution (I should write with plural...) to the Type 
"file" test case.

I give three versions, from the shortest I could make to one more 
respectful of the requirements (splitting too long lines).

I have put all three versions in the same file, to avoid sending too 
much files... Just change the first assignment to "S", "SC" or "L".

--

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --

#!Lua-5.0.exe
-- APLC Type File.
-- http://www.kochandreas.com/home/language/tests/TYPE.HTM
-- by Philippe Lhoste <PhiLho(a)GMX.net> http://Phi.Lho.free.fr
-- v. 1.0 -- 2005/01/01

local choice = 'L' -- Three programs in one, to avoid sending three files...

if choice == 'S' then

Compiling wxLua with wxWidgets 2.5.3

Hi!

I'm trying to compile this binding under Mingw32 (GCC 3.3.1) (using own 
makefile) and got an error:

wxLuaSplitTree.cpp
../../lib/wx/wxWidgets-2.5.3/include/wx/msw/dc.h: In member function 
`virtual
    void wxRemotelyScrolledTreeCtrl::PrepareDC(wxDC&)':
../../lib/wx/wxWidgets-2.5.3/include/wx/msw/dc.h:256: error: `wxDC&
    wxDC::operator=(const wxDC&)' is private
wxLua26.253/wxLua/wxLua/Library/wxLuaSplitTree.cpp:224: error: within this
    context
make[1]: *** [obj/wxLuaSplitTree.o] Error 1

In the other hand when I use original makefile provided by authors of 
wxLua I got error in wxLuaDebug.cpp:62:

definition of static data member 'wxClassInfo 
wxLuaDebugEvent::ms_classInfo' of dllimport'd class.

How to compile this binding? I want wxLua.dll linked dynamically with 
lua.dll and wxWidgets 2.5.3 libraries which I can load with loadlib() 
through require(). It is workable?

--

-- 
Regards,
Adam Dziendziel, Poland

[ANN] KurmiDlg - First version released

Hi:

After thinking for a while, I decided to make the Wizard GUI a 
independent thing.

Now, kurmidlg.[dll|so] implements the GUI part in a "lua style", and 
Kurmi+KurmiBuilder will be modified to make use of it.
Before KurmiDlg the Wizard logic was inside the GUI DLL/SO, now the 
logic is written in Lua.

KurmiDlg is a standard extension library, and you can use it for what 
you want: it not depends on Kurmi Installer.

This is the first release of the version for Windows.  It must be 
considered "alpha code" but I think it will become beta in a short time.

Your comments, if you decide to send them to me, will be appreciated 
very much.

Regards,
Daniel Quintela

Re: [ANN] KurmiDlg - First version released

Sorry, I forgot the link:   
http://luaforge.net/download.php/408/kdlg-1.0a-win.tgz

--DQ

Re: Compiling wxLua with wxWidgets 2.5.3

Hi,

I've other problems trying to do the same, just w/ the Visual Studio 2003 Toolkit. When compiling many
errors come, mainly 

- unallowed conversions, e.g. WXHANDLE, void* now, seems to be long before
- missing functions, e.g. wxWindow.Clear(), or changed function declarations
- missing constants, e.g. various wxSTC_SCRIPTOL_*, which really do not exist in the wx sources

Nevertheless the wxLua homepage states that it should be compilable w/ 2.5.3 and there is also a 2.5.3
binary available, so it should work somehow.

Any idea?

Regards, Frank

Lua list <lua <at> bazar2.conectiva.com.br> schrieb am 01.01.05 15:50:45:
> 
> Hi!
> 
> I'm trying to compile this binding under Mingw32 (GCC 3.3.1) (using own 
> makefile) and got an error:
> 
> wxLuaSplitTree.cpp
> ../../lib/wx/wxWidgets-2.5.3/include/wx/msw/dc.h: In member function 
> `virtual
> void wxRemotelyScrolledTreeCtrl::PrepareDC(wxDC&)':
> ../../lib/wx/wxWidgets-2.5.3/include/wx/msw/dc.h:256: error: `wxDC&
> wxDC::operator=(const wxDC&)' is private
> wxLua26.253/wxLua/wxLua/Library/wxLuaSplitTree.cpp:224: error: within this