Re: [Bug-gnubg] Compiling on Linux without GTK

[Jim Segrave]

On Tue 04 Mar 2003 (20:49 +0100), Nis wrote:
> --On Monday, March 03, 2003 20:01 +0100 Jim Segrave <address@hidden> 
> wrote:
> 
> >> Yes, but please do a diff -u or diff -c, and if it's a huge patch please
> >> compress it :-) And if it's possible it would like these changes
> >> separate from the half-ply changes :-)
> >
> > diff -u is really the only way to go in my opinion.
> 
> Thanks - that was the info I needed.
> 
> > The problems were:
> >
> > gnubg.c - CommandSetGUIDragTargetHelp only gets created if USE_GTK is
> >           true
> >           fGUISetWindowPos is only defined if USE_GTK is true (moved
> >           the #if USE_GTK up to remove the save of window positions
> 
> Exactly the two changes I made to that file ...
> 
> > renderprefs.c - SetColourX() has a parameter of type gdouble - #if'ed
> >           out this function, as it's static
> >           #if'ed out the call to SetColourX() later on
> >           #if'ed out the SetColourSSF() function - again gdouble
> > parameters           #if'ed out the body of RenderPreferencesParam() to
> > avoid the            call to SetColourSSF()
> 
> Here I did a little "heuristic" editing - changing gdouble and gfloat to
> double and float (so they "looked" like the functions not causing errors) -
> and only commented out the parts of RenderPreferencesParam() causing 
> problems.
> 
> It now compiles nicely - including my additions ... can anybody tell me how 
> to debug Segfaults?

I've a lot of experience with this.

I'd suggest:

1) try and get as simple a way to cause the segfault as possible. I'd
guess you're testing the 'fractional ply' code. If you can find a
position where hint causes a repeatable segfault, that helps a
lot. You can then test with a simple command file which sets a match
and board position, runs the hint command and crashes. 

Since you're using Linux, info gdb will give you a guide to using the
debugger (although the documentation is not for the faint hearted).

If you use emacs, then gdb is even easier to use:

change to your gnubg source directory and start emacs
Esc x gdb
prompts with:
run gdb (likethis): gdb
enter ./gnubg <core file path>
eg:
run gdb (likethis): gdb ./gnubg /home/jes/gnubg.core

The advantage to this is that emacs will open a source file (if it's
available) in one window while the debugger's in the other. The source
file will be positioned to the line which the debugger is on.

If you aren't an emacs person (which makes the info command less
friendly), then simply starting gdb from the command line works as
well:

$ cd /source/dir/for/gnubg
$ gdb ./gbubg <core file path>

At any rate, the first command you need to use is 'bt' - backtrace.
This gives a list of all the functions which have been called but
haven't completed at the point the seg fault occurred. The first entry
in the list is the function where it happened, the second is the
function that called the function where it happened, etc.

The next valuable command is the frame command. This basically moves
the debugger to the function in the above list -

f 0 goes to the top of the list, and points to the line of code which
    caused the seg fault
f 1 goes to the line of code in the function which called the function
  where the seg fault happened, etc.

If you are lucky, the seg fault happens in a function within gnubg
itself, so f 0 will take you to a line of code in gnubg. More often,
the seg fault happens within some library routine - say strcpy or
strcmp or some such. In that case, you keep stepping up the list of
frames with f 1, f 2, etc. until you hit a point in gnubg's code
itself. For example, a call to strcpy where the target is a null
pointer would have f 0 perhaps be some internal library routine like
__mem_copy, f 1 being something like the strcpy function itself and f
2 being the call to strcpy from gnubg itself.

Whenever you are in a frame for which source exists, gdb can print
most of the variables as they were at the time of the call. (sometimes
this doesn't work, the more optimised the code the more often there
are problems). If variables are in registers, gdb may not be able to
display them or may give very strange values.

The worst problem you can have is when the seg fault results from
mishandling of dynamic (malloced) memory. In this case, the bug -
overwriting malloced memory or re-using it after calling free() -
takes place some time before the seg fault occurs. Debgging this can
sometimes be *very* difficult, particularly with a program like gnubg
which allocates and frees memory so often.

I am willing to try to help. But I don't run Linux, so I can't debug a
core file myself. I am willing to look at a gdb bt output and the code
for the routines you've changed (or try building a copy with the same
code if you have a test case which causes the fault so I can debug it
locally).

If it is a dynamic memory issue, I know how to debug it, but I don't
think I could easily explain the techniques required - you either have
to run gnubg a about 1/1000 normal speed or you have to find the
memory being corrupted, wait until it has been allocated, then set a
watchpoint and wait for it to be corrupted. I hope this won't be the
problem. 
-- 
Jim Segrave           address@hidden