gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] Segmentation fault, dragon2 array appears to be corrup


From: Gunnar Farneback
Subject: Re: [gnugo-devel] Segmentation fault, dragon2 array appears to be corrupted
Date: Fri, 11 Jan 2002 18:01:24 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Arend wrote:
> I have to apologize for the Mac OS troubles one of my patches
> introduced in compute_surrounding_moyo_sizes. Not that I think I could
> have foreseen this strange problem; yet the crucial array moyo_segmentation
> is a lot bigger than needed, and I will send a patch to revise this
> soon. Thanks a lot to Allan Crossman and Marco Scheurer for tracking this
> bug down!

I have already sent (yesterday) a patch to reimplement this function
with much smaller memory usage, but the message has not been delivered
yet (at the time of writing this).

Clearly something is not working correctly with the mailing list. My
guess is that messages are not actually disappearing, but are severely
and rather randomly delayed. The last few days all messages I've seen
have arrived between about 3 and 48 hours after having been sent. If
you want to make sure that me, Dan, or someone else in particular see
the messages quickly you should add them as Cc recipients while this
goes on.

> However, at the moment I am trying to fix another bug of the current CVS,
> and I would very much appreciate to get a hint from some of the more
> experienced programmers. It occurrs when running
> 
>     gnugo-cvs -l Lazarus-gnugo-3.1.19-200201092246.sgf -L 10 -t -w
> 
> A segmentation fault occures at score.c:483, and the dragon2 array
> appears corrupted (according to gdb). To track down the bug, I compiled
> dragon.c without optimization. To my surprise, not even the initialization
> of the array seems to work. I set a breakpoint at dragon.c:714, and performed
> instructions step by step from there on, with very strange results.
> The member hostile_neighbors is missing from all dragon2[.] entries,
> and the other members behave like being shifted. E.g., dragon[1].origin
> seems to get corrupted from from them command
> dragon2[0].semeai_margin_of_safety = -1.
> 
> Is this just me having set up gdb incorrectly, or is this already evidence
> the bug? I append a copy/paste of the gdb output below. 

I can't reproduce this. From your description it sounds very much like
you have an inconsistent build where different parts of the code have
different opinions on the memory layout of the dragon2 array. I have
no idea how or why you have ended up in that state but I bet that

make clean
make

will solve the problem.

/Gunnar



reply via email to

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