Re: [gnugo-devel] Crash report for OS X Segmentation fault

[Dave Denholm]

Marco Scheurer <address@hidden> writes:

> On Tuesday, January 8, 2002, at 07:25  pm, Gunnar Farneback wrote:
> 
> > Teun wrote:
> >> I think then this is a problem with stack overflow.
> >> We have seen something similar earlier on with
> >> the owl stack, which was much larger though.
> >
> > Or heap overflow. I think it's odd that the compiler or linker can't
> > warn about this.
> 
> Yes, in 10 years of development on NeXTSTEP, OPENSTEP, now Mac OS X, 
> I've never seen this. I don't know enough about compilers or gcc to 
> decide if this a bug though.


The compiler can't detect it because stack overflow depends as
much on the context of the function call as the call itself.
(eg a recursive function using only one local variable will
 fill the stack if it recurses far enough)


The compiler may have an option to insert stack checks.
That may be what gcc -fstack-check does.



Traditionally (on single-threaded programs on virtual memory systems,
at least), the heap and stack start at either end of the unused virtual memory,
and grow towards each other, mapping pages as required. It is almost
impossible to run out of virtual space for the stack. (More likely to run
out of physical memory or swap space for the committed pages.)

However, with the advent of multi-threaded programs,
there are multiple stacks, and so each stack has to be
have an upper bound on virtual size, set at startup.

I don't know much about OS X, but maybe all processes are
multithreaded, with internal housekeeping threads..?

There may be an option (linker/loader option ?) to set the default
thread stack size.


> 
> If anyone cares, cc -v gives:
> Apple Computer, Inc. version gcc-934.3, based on gcc version 2.95.2 
> 19991024 (release)
> 
> >> I bet declaring this array as static or allocating
> >> it with malloc should also fix
> >> this problem.
> >
> > I also think that's very likely. Allocating it as static would be
> > easiest and probably good enough.


Hmm... I'm afraid I've rather lost touch with the current goals
of gnugo. But "wasting" lots of memory as static does increase
the minimum footprint required to run, and there are some people
trying to run it on handhelds...



One option is to do a test at configure time to see if the
stack is limited, and export a symbol LARGE_AUTO which is either
'static' or ''. Then systems with no stack limits can
leave it as automatic.


One other thought is to take advantage of gcc's feature to
allocate dynamically-sized arrays. The declaration was
something like

  int moyo_is_adjacent[MAX_BOARD*MAX_BOARD][MAX_MOYO+1];

gcc will let you declare it as

  int moyo_is_adjacent[board*board][MAX_MOYO+1];
  
to take up closer to the actual space required.
(Might be able to make the second index variable too,
 but the generated code will be better if it is fixed.
)



Oh, one final thought : I'm well out of date with the
sources these days. I was browsing the code on the
savanah, but didn't find this function.

Do you know about lxr ?

  http://lxr.linux.no/
  http://lxr.mozilla.org/


It's a little like using tags, but it makes it easy
to find all the uses of symbols as well as where
they are defined.

I for one would find it really useful if some machine
could serve such a cross-reference. It takes a little bit
of setting up, but I'm happy to help out there. (I don't
have any access to a web server myself, I'm afraid.)


> 
> Yes, declaring it static fixes the problem. I'm not familiar with 
> contributing code or patches to gnugo, so could please one of you guys 
> fix it? Thanks.
> 
> marco
> 
> Marco Scheurer
> Sen:te, Lausanne, Switzerland   http://www.sente.ch
> 
> 
> _______________________________________________
> gnugo-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnugo-devel

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