[Top][All Lists]

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

Re: [gnugo-devel] Access violation in 3.3.18 compiled with Visual C

From: Arend Bayer
Subject: Re: [gnugo-devel] Access violation in 3.3.18 compiled with Visual C
Date: Mon, 28 Apr 2003 15:26:15 +0200 (CEST)

Gunnar wrote:
> SP Lee wrote:
> > I have compiled GNUGO 3.3.18 using Visual C and played with it and found it
> > often stopped due to "access violation", which is generated in windows 98.
> > In windows XP this becomes "signature error". In the attached example, the
> > GNUGO stopped at MEMCPY.ASM (some instructions further from the label
> > CopyUp) after 16 time calls of do_owl_analyze_semeai. GNUGO plays black in
> > this example.
> >
> > I'm not sure if this also happens in unix environment.
> I cannot reproduce this on linux.

It should be highly unreproducable. Some memory pressure usually

> Teun wrote:
> > I can confirm this for the mingw versions. The cygwin version gives
> > S7 as move.
> > [...]
> > #0  0x78001637 in memcpy () from /dev/c/WINDOWS/SYSTEM/MSVCRT.DLL
> > #1  0x00469fd8 in do_owl_analyze_semeai (apos=255, bpos=154, owla=0xf0460c, 
> > owlb=0xf0d1f4, komaster=0, kom_pos=0, resulta=0xe016f8, resultb=0xe016fc, 
> > move=0xe00fe8, pass=0, owl_phase=1) at ../../engine/owl.c:828
> This seem to indicate a problem with the "under certain circumstances,
> store only the goal array" optimization. Thinking about it the

I am very unhappy about the nasty problems with regards to moving
the owl stack. (I've definitely had to debug this too often.) They show
that The interface to push_owl and pop_owl after my rewrite some time
early 3.3 is crap. Maybe I can fix this some time.

I agree with your patch, but we should additionally use Nando's
workaround of increasing the stack size we begin with, as realloc() is
not something we want to do to often with this huge array.


reply via email to

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