[Top][All Lists]

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

Re: [gnugo-devel] Crash found in 3.4

From: Dave Denholm
Subject: Re: [gnugo-devel] Crash found in 3.4
Date: Tue, 23 Dec 2003 12:56:25 +0000
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (usg-unix-v)

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.)

Dave Denholm              <address@hidden>

reply via email to

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