Nmap Development 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:
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
Current thread:
- [Bug?] memory could not be read in liblua/ldo.c resume_error jah (Jun 21)
- Re: [Bug?] memory could not be read in liblua/ldo.c resume_error Patrick Donnelly (Jun 21)