Re: [gnugo-devel] Memory corruption?

[Dave Denholm]

Daniel Bump <address@hidden> writes:

> Here is a problem that is mysterious to me. To see the
> problem you need the current snapshot of the semeai code
> which I put up as a patch called semeai_1_17.1 linked
> from devel.html. This is not in the cvs.


 
> You see that all is well at this point. We are about to execute:
> 
> wormsa = catalog_goal(owla, goal_wormsa);
> 
> After stepping over this command, we find that owlb is
> corrupted, even though the command that was just executed
> should have nothing to do with owlb.
> 
> (gdb) p owlb.goal[21]
> Cannot access memory at address 0x11a.
> 
> The next command,
> 
> wormsb = catalog_goal(owlb, goal_wormsb);
> 
> causes a segmentation fault.  There looks to be nothing in
> catalog_goal that would cause a problem here.
> 
> 
> Since the function which causes owlb to mysteriously change does not 
> look suspicious, we may be faced with a problem of this type. There
> are a couple of programs that might help us. One is called purify,
> which is a commercial program. The other is called Checker and it
> is free software. It is available in the alpha directory at
> ftp.gnu.org but so far I've been unable to compile it.

purify is pretty good. Unfortunately, I don't access to a copy
here.

hadn't heard of checker, but it looks like it is looking at
malloc-ed memory : does gnugo use much of this ?
[there's also electic fence]


I once heard about a modified gcc which would generate
code which included bounds checks. arrays and pointers carried with
them an indication of size, and all accesses through them
were checked. So that worked for static and automatic
arrays as well as malloc-ed memory.



For doing a one-off problem : if it is completely reproducible
(to the extent that the same variable gets clobbered), you
can set a gdb watchpoint on it. It will run very slowly,
but it will stop as soon as it attempts to change that memory.



dd
-- 
address@hidden          http://www.insignia.com