WvDynBuf's maxungettable variable can wrap around and assert.

[GoogleCodeExporter]

Will noticed an internal NITI bug that discovered that the "maxungettable"
member variable of WvDynBuf can wrap around if a buffer is used enough. 
The patch developed internally didn't seem very robust though, so I had a
fresh look.

First I had to reproduce the problem.  I found one reproduction case
(included in unget-test.patch) that showed the problem, but was extremely
slow to run and consumed a lot of RAM.  I then narrowed it down a bit to a
new test (included in maxunget-overflow.patch) that ran much faster, but
didn't quite stress the code as much.

I also found a preliminary solution, which is to just keep maxungettable
from overflowing.  This isn't very satisfying though, it'd be much nicer to
keep it from rocketing so high in the first place.  Another option would be
to set maxungettable to 0 at various points, either in put() or in alloc(),
but (a) that feels hacky, and (b) NITI's patch tried to do something like
that, and it still fails with my first slow test case.

Basically, WvDynBuf needs a good hard looking at, but I don't quite have
the time for it right now.

Original issue reported on code.google.com by peter.mc...@gmail.com on 7 Mar 2008 at 10:26

Attachments:

• unget-test.patch
• maxunget-overflow.patch

[GoogleCodeExporter]

When I mentioned my first unit test (in unget-test.patch) was slow, I really 
wasn't
kidding.  Even without valgrind, it still takes 5 minutes or so on my machine 
(and
really clobbers my disk cache).  To run it, after applying the patch I run: 

make wvtestmain && WVTEST_DISABLE_TIMEOUT=1 ./wvtestmain dynbuf

Or whatever your favourite incantation is to keep Valgrind from running.  
Valgrind is
just too slow to contemplate.  I think even the "fast" unit test in the second 
patch
is still too slow for the WvTest timeout, so you still may need the
WVTEST_DISABLE_TIMEOUT=1 and/or the Valgrind disabling.

Original comment by peter.mc...@gmail.com on 7 Mar 2008 at 10:30