aboutsummaryrefslogtreecommitdiff
path: root/BUGS
diff options
context:
space:
mode:
authorBenoit Germain <bnt.germain@gmail.com>2011-01-04 21:31:17 +0100
committerBenoit Germain <bnt.germain@gmail.com>2011-01-04 21:31:17 +0100
commit79e46938c5d8daf164ab2d934f668fa27b32e4cf (patch)
tree407761f25bbdc3d5b2066a705dcbcf8711690242 /BUGS
parented07b457b6b45ece85d367dc8b89bf3c040abd9a (diff)
downloadlanes-79e46938c5d8daf164ab2d934f668fa27b32e4cf.tar.gz
lanes-79e46938c5d8daf164ab2d934f668fa27b32e4cf.tar.bz2
lanes-79e46938c5d8daf164ab2d934f668fa27b32e4cf.zip
Take all code from Asko Kauppi's SVN server, and push it here so that the github repository becomes the official Lanes source codebase.
Note that Asko's SVN server holds version 2.0.9, whereas this is version 2.0.10, but I don't see any real need to update SVN if it is to become deprecated. Next steps: - upgrade the rockspec to the latest version - make the html help available online somewhere Signed-off-by: Benoit Germain <bnt.germain@gmail.com>
Diffstat (limited to 'BUGS')
-rw-r--r--BUGS111
1 files changed, 111 insertions, 0 deletions
diff --git a/BUGS b/BUGS
index d25cc0e..9ae6db5 100644
--- a/BUGS
+++ b/BUGS
@@ -1,6 +1,117 @@
1 1
2BUGS: 2BUGS:
3 3
4- Reported by Pierre LeMoine (Dec-2009:
5<<
6Hi!
7I think i've located an error in Lanes. When a finalizer is called, it
8receive two tables. The second one seems to be the table containing
9the finalizers. The attached test reproduces the error, and is tested
10on binaries built by myself and from the LfW project.
11The following line from run_finalizers in lanes.c seems to be wrong to me:
12
13 error_index= (lua_rc!=0) ? tbl_index-1 : 0; // absolute indices
14
15I think it should be -2 there, since the stack at this point should look like
16[-1] finalizer table <- tbl_index
17[-2] stack table
18[-3] error string
19
20Also, in some places, checks for valid returns from lua_toLinda are
21missing, leading to crashes. (for example, linda.get)
22
23Sometimes when i use lanes i get a "recursive use of upvalues"-error,
24i fail to see how upvalues can be recursive? =)
25
26/Pierre
27<<
28
29
30- Reported by Benoit Germain (Dec-2009):
31<<
32Doc says :
33
34The current execution state of a lane can be read via its status member, providing one of these values:
35
36
37"waiting" waiting at a Linda :receive() or :send()
38
39
40
41But code and test say otherwise : lane status remains « running » even when waiting on a Linda operation, which is quite understandable since nowhere in the code status is changed to WAITING. This is a problem for me because my lanes are consumers waiting for commands on a linda. « waiting » status is the only means I have to ensure that a command is not currently being processed. Therefore the fix, to make Lanes behave as the documentation states :
42
43LUAG_FUNC( linda_receive ) {
44 ...
45 // BBB HACK: fetch the lane object to update the status
46 {
47 struct s_lane *s;
48 enum e_status prev_status;
49 STACK_GROW(L,1);
50
51 STACK_CHECK(L)
52 lua_pushlightuserdata( L, CANCEL_TEST_KEY );
53 lua_rawget( L, LUA_REGISTRYINDEX );
54 s= lua_touserdata( L, -1 ); // lightuserdata (true 's_lane' pointer) / nil
55 lua_pop(L,1);
56 STACK_END(L,0)
57 if( s)
58 {
59 prev_status = s->status;
60 s->status = WAITING;
61 }
62 if (!SIGNAL_WAIT( &linda->write_happened, &K->lock_, timeout ))
63 {
64 if( s) s->status = prev_status;
65 break;
66 }
67 if( s) s->status = prev_status;
68 }
69
70Of course, the same has to be done in linda_send, and lane structure retrieval could be factorized with the cancel_test. Anyway, what I am concerned about now is whether I missed something or not. Can the lane status change while waiting, so that restoring the previous value could cause problems?
71<<
72
73
74- The use of 'static' and "one time" initialization of things is not suitable
75to a situation where a Lua state is run, using Lanes, then terminated. If
76another Lua state later is launched, the initializations will get cramped.
77
78Reported by Boris Ouretskey (25-Jun-09)
79
80
81- a 'require "lanes"' and speedy exit from the process causes a segfault
82 on ArchLinux (reported by kkndrox@gmail.com 1-Jun-2009).
83
84 This issue is not reproducible on Ubuntu (8.04 or 9.04) and has not therefore
85 been fixed. A patch is welcome. The issue is most likely caused by the
86 Linda thread not being properly launched when the process itself already
87 quits.
88
89<<
90With Lanes 2.0.3, the following code *always* gives me a segmentation
91fault:
92
93-- begin
94require("lanes")
95-- end
96
97But this:
98
99-- begin
100require("lanes")
101garbagecollect('collect')
102-- end
103
104always work.
105
106Based on this experimentation, if I require lanes and the program end
107without any garbage collecting, I receive a segmentation fault.
108I'm using Arch Linux (32bits), Lua 5.1.4 and it was compiled with gcc 4.3
109<<
110
111 Also simply waiting a bit ('os.execute("sleep 1")') avoids the crash.
112
113
4- tests/irayo_closure.lua fails (trouble with setting globals right 114- tests/irayo_closure.lua fails (trouble with setting globals right
5 for functions carried over to another Lua state) 115 for functions carried over to another Lua state)
6 116
117- "make appendud" causes a segfault on OS X PowerPC.