mailing list archives
Re: [Bug?] memory could not be read in liblua/ldo.c resume_error
From: "Patrick Donnelly" <batrick.donnelly () gmail com>
Date: Sat, 21 Jun 2008 12:54:59 -0600
On Sat, Jun 21, 2008 at 9:58 AM, jah <jah () zadkiel plus com> wrote:
In the current svn, I'm getting an unhandled exception when running
nmap.exe: The instruction at 0x63DCD2 referenced memory at
0xFEEEFEEE. The memory could not be read (0x0063DCD2 -> FEEEFEEE)
which happens in resume_error () in liblua/ldo.c:409:
L->top = L->ci->base;
L->ci has a value of 0xfeeefeee.
The code reaches resume_error() because in lua_resume:
if (L->status != LUA_YIELD && (L->status != 0 || L->ci != L->base_ci))
return resume_error(L, "cannot resume non-suspended coroutine");
L->status has a value of 238 (it's always the same value).
Somehow, the location of L contains garbage. I haven't been able to
determine what causes this with my limited understanding of the code.
I'm running the script for two targets in the same ip assignment.
The first thread does a mutex "lock", and does some stuff. Meanwhile,
the second thread starts and comes up against the lock.
The first thread then finishes doing its stuff, does a mutex "done" and
Once the first thread has returned, the second tries to resume and it is
at this point that the exception occurs.
I don't know for sure that it isn't caused by something in whois.nse
because the mutex stuff was written while working from r8260 in
Patrick's branch (where it works fine) and this is the first time I've
tried it anywhere other than there. My suspicion though, is that it's
something to do with the fact that when the second thread tries to
resume, the first thread has exited.
I've attached whois.nse.gz to aid reproduction of the issue (run it
against two or more targets in the same range and -d7 will help to
reveal the flow) and if there's anything else I can do to help, let me know.
I believe I've fixed this. I found a related bug (I couldn't reproduce
yours specifically). The problem was waiting2running was pushing
threads to the front of the running queue while mainloop was popping
the first running thread (assuming the thread that just yielded is at
the front). Please see if this still happens.
"One of the lessons of history is that nothing is often a good thing
to do and always a clever thing to say."
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org