[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] backtrace
From: |
Gunnar Farnebäck |
Subject: |
Re: [gnugo-devel] backtrace |
Date: |
Thu, 29 Jul 2004 00:15:13 +0200 |
User-agent: |
EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.9) MULE/5.0 (SAKAKI) |
Arend wrote:
> I agree. However, I have one crash report (happened repeatedly) from
> Matthias pending. I will forward as soon as we have a backtrace.
> (Probably a segmentation fault, i.e. a silent crash.)
Any chance to get a gtp dump (--gtp-dump-commands <filename>)?
> As promised the backtrace from a crash. After a short look, it leaves me
> confused. Unfortunately, we don't have the .sgf file.
I guess the binary is compiled with optimization. An unoptimized
backtrace may be clearer to read.
> (gdb) backtrace
> #0 0x080ab62e in do_find_more_owl_attack_and_defense_moves (color=2,
> pos=25,
> move_reason_type=54, what=140714336) at value_moves.c:364
Line 364 in 3.5.9 (and I suppose CVS) is
add_loss_move(pos, dd, kworm);
It doesn't really make sense to crash here, but either the compiler
has done some kind of inlining of add_loss_move() or it has moved some
previous piece of code to this line. In any case it's almost certain
that the problem is "what=140714336" in the call, which gets
propagated to the dd variable and is used to index e.g. the dragon[]
array. A segmentation violation would be reasonable if the addressing
is that badly off.
> #1 0x080ac2b5 in find_more_owl_attack_and_defense_moves (color=2)
> at value_moves.c:619
The bad value apparently comes from the find_eye_dragons() call on
line 614. My guess is that find_eye_dragons() simply didn't find any
dragon adjacent to the eye. Not that this makes any sense but it is
the least implausible scenario I can come up with. It may be useful to
add assertions that the return value from find_eye_dragons() is at
least one and that dr ends up on the board.
/Gunnar