bug-zile
[Top][All Lists]
Advanced

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

Re: [Bug-zile] Incremental search is dog slow in moderately-sized files


From: Reuben Thomas
Subject: Re: [Bug-zile] Incremental search is dog slow in moderately-sized files
Date: Mon, 20 Jan 2014 23:10:51 +0000

On 20 January 2014 23:07, Gary V. Vaughan <address@hidden> wrote:
Hi Reuben,

Thanks for taking a look at this.

On Jan 21, 2014, at 4:07 AM, Reuben Thomas <address@hidden> wrote:
>
> I've run out of time for [[debugging the alien.default.memrchr crashes on glib]] for now. However, I have an idea: how about adding asserts to your Lua memrchr to check for out-of-bound accesses? I can't see anything wrong with memrchr itself now, so I suspect bad arguments which merely result in nil results in the Lua version.

I've noticed that about half the time, a random one out of the 100+ run-lisp-tests.lua checks (`make tests-check-local`) crashes zmacs using my Lua memrchr too.  Instrumenting shows that my memrchr returns the location of EOL prior to the one returned by find_substr().  Naïvely changing memrchr to start the search one byte higher in memory breaks everything though, so I need to spend some time understanding the details of find_substr, and either fix that and whatever changes ripple out from there, or make sure memrchr is interface compatible before swapping it out.  At least I have a way of pinning it down now... and then I can make the same changes in the alien.default.memrchr wrapper and hope that works too.

When I was translating all this stuff from C to Lua it was almost always an off-by-one bug in these cases. It's possible I may have left some in the Zile code myself!

--
http://rrt.sc3d.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]