Hi,

ah, I see, a race. Well, if it fixes it for now, we can let it go...

-hwh

2013/2/6 {Qingping,Dave} Hou <notifications@github.com>

> In unireader.lua:
>
> > @@ -1147,6 +1151,8 @@ function UniReader:drawOrCache(no, preCache)
> >  			return pagehash,
> >  				offset_x_in_page - self.cache[pagehash].x,
> >  				offset_y_in_page - self.cache[pagehash].y
> > +		else
> > +			self:cacheFreeItem(pagehash)
>
> It was too late last night, so I did not dig into the problem. Not sure
> whether I am right. Following is what I observed:
>
> In two column mode, firstly, part of page 2 is cached, which roughly took
> more then half of the whole cache. Then when the user request the other
> part, and it turns out that the cached part does not contain the requested
> area. So unireader render the new part and put it into cache and increases
> the current cache size.
>
> Here is how things went wrong, since these two parts are in the same page,
> their related cache item have the same hash value. So when the second cache
> item is put into the cache pool, it overwrite the first one using the same
> hash key. Then we end up with a cache pool with only one cache item but the
> current cache size is the sum of first and second cache item. This caused a
> endless loop in the cacheClaim function's while loop.
>
> So in sum, the not used part is actually overwritten instead of being
> evicted.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/hwhw/kindlepdfviewer/pull/737/files#r2914465>.
>
>