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

[Dave Denholm]

Daniel Bump <address@hidden> writes:

> > 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...
> 
> How does making this array static increase the minimum
> footprint to run? After all, if the array is not static,
> then when the function is called, the space for it will
> have to be allocated then. 
> 
> (I think I see but let me ask the question anyway.)


If it's declared static, that memory is reserved permanently
for the use of that function, even when it is not being used.

If it's on the stack, then yes, we still need at least that
much memory for the stack while that function is running.
But then if there is another function which also has
a large, temporary array, or if there is some recursive
reading happening elsewhere, the same virtual memory is
used.

Simple example :

void f()
{
   AUTO int f_workspace[1024];
   ...
}


void g()
{
   AUTO int g_workspace[512];
   ...
}

int main()
{
   f();
   g();
}



if AUTO = static, this program needs at least (1024+512) words
of memory to run. f_workspace[] exists (but is not in scope)
even while g() is running.


if AUTO = /*nothing*/, this program needs at least 1024 words
of stack to run. g_workspace[] and f_workspace[] share the
same virtual memory, and each exists only while the
other is running.


And since gnugo has lots of recursive reading code, it
needs a lot of stack anyway, and the workspace will
get reused for that too.


> 
> I don't think anyone is running GNU Go 3.x on a handheld. However
> people are running 2.6.
> 
> > 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.)
> 
> This does look pretty useful. I wouldn't mind seeing that
> happen, though it looks like a lot and our source tree is
> constantly changing.  (Still, these comments apply also
> to the Linux kernel, and they are maintaining an lxr tree
> for that.)

I also use an lxr tree for the code at work.

> 
> I use tags to find function definitions and if I want to
> find all function calls I accomplish this in a low tech
> way with this shell script:
> 
> #!/bin/bash
> if (! $2)
> then
>         $2 = "."
> fi
> find $2|grep "\.[ch]$"|xargs grep $1
> 


FWIW, that's same as

 find ${2:-.} -name '*.[ch]' | xargs grep $1

since ${2:-.}  means $2 if it exists, otherwise '.'



I think emacs does have a mechanism for finding uses of
tagged strings. I don't use it myself. Ah : looks like
"tags-search" ?  Or just grep-find


I actually have a set of emacs scripts which hook
into the lxr thing. In emacs, I do
  lxr-ident fred
and then it connects to the lxr web server, retrieves the
output, mangles it a bit, then presents it in an emacs
*grep* window. Then I can just click on the entry in
that window and emacs will load up the referenced
source file. This is actually how I tend to navigate
source files at work...

But I do use a web browser when I am just looking
through the sources.


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