Re: [Bug?] memory could not be read in liblua/ldo.c resume_error

["Patrick Donnelly" <batrick.donnelly () gmail com>]

On Sat, Jun 21, 2008 at 9:58 AM, jah <jah () zadkiel plus com> wrote:
> Hi,
>
> In the current svn, I'm getting an unhandled exception when running
> whois.nse:
>
>    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
> then returns.
> 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.
>
> Regards,
>
> jah

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.

Thanks,

-- 
-Patrick Donnelly

"One of the lessons of history is that nothing is often a good thing
to do and always a clever thing to say."

-Will Durant

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org