Re: [gnugo-devel] Crash found in 3.4

[Dave Denholm]

Gunnar Farneback <address@hidden> writes:

> I wrote:
>> I've tracked the bug down. More details tomorrow. For now I'll just
>> say that the best fix is to rewrite the owl stack management to be
>> less fragile.
>
> At the bottom of the problem is the fact that the local owl data are
> so large that we don't want to allocate more of it than necessary and
> that we can't be sure beforehand how deep stack will be needed during
> the recursive owl reading. It's also too large for handling on the C
> stack on some platforms, which was what we once did. Thus we need to
> dynamically allocate memory for it.
>
> There are several plausible solutions to this problem, including:
>
> 1. Rewriting do_owl_attack() and do_owl_defend() to take a pointer to
>    the owl pointer.
> 2. Allocate all memory we may ever need for the owl stack at once.
> 3. Rewrite push_owl()/pop_owl() not to move memory around.
> 4. Redesign the owl data structures to be smaller or be incrementally
>    updated. (Possibly combined with 2.)
>

5. If overflow is rare, one possibly would be to grow the memory then
   to bail out of the search and start over (or even start move generation
   over again). setjmp/longjmp might help here.

   (One could view this as a very slow way of regenerating the data.)


dd
-- 
Dave Denholm              <address@hidden>       http://www.esmertec.com