lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Thomas Lauer escribió
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.
Yes, the problem arises from a illegal access to memory deallocated by the old reallocation scheme.
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

[snipped code]

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.