[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaTask needs your help
- From: Daniel Quintela <dq@...>
- Date: Sun, 08 Jul 2007 13:09:28 -0300
Thomas Lauer escribió
Yes, the problem arises from a illegal access to memory deallocated by
the old reallocation scheme.
This is too complicated, methinks. The old, simpler allocation scheme
was perfectly okay. The crashes resulted from invalid accesses, I think.
And I am not sure that these changes will solve all problems with that.
Following Kacper's clever analysis, I went through the ltask code step
by step. I finally changed just a few lines in taskthread(). This
produced a version that seems to run okay on my box. (I say "seems"
because the crashes I got were not strictly reproducible. I did
stress-test the code for a good while but with this sort of bug there's
always a small possibility that it's buggy but just refuses to crash.)
I didn't post these changes because I did other, unrelated changes as
well, so I couldn't just post a straightforward patch file. Also, I knew
you were already working on a fix anyway.
FWIW, the gist of my changes is the following. In the 1.6.1 version of
ltask.c, line 540, you initialise te:
te = aTask + ( ( long) vp);
The mutex is given up in line 554. After this line, the block aTask
points to can move at any time because of an realloc(). And if aTask
moves, then te is pointing nowhere.
However, in lines 558, 560, 567, 568, 571 ,573 and 583 te is still used.
(Getting the mutex back in 577 doesn't reinitialise te.)
I assume this is what produced the crashes I saw. When I changed the
code such that te is either not needed after line 554 or reinitialised
before accessing thread information everything seems to work fine (with
the caveat given).
Here is my current taskthread(). As I said, there are a few other
changes and I also compile this as C++ code. The three main changes are
It was my first solution, but I preferred to add the pointer indirection
to TASK_ENTRY blocks and keep its memory immutable.
Threads don't have to worry about its own memory.
Yes, it adds complexity and a level of indirection to access the task
list... ¿what is the better approach?.
Sorry, probably should have posted this earlier. Anyway, HTH.
Don't apologize, "candidate time" is right for your feedback.