Gdb Debugging Help !

Discussion of chess software programming and technical issues.

Moderator: Ras

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Gdb Debugging Help !

Post by bob »

Sven Schüle wrote:Could there be any interference between using a debugger and polling for input during search?

I recently encountered such a problem, just not with GDB but with the MSVC++ debugger, and therefore temporarily switched off input polling in the DEBUG version. In my case it seemed that the debugger and the polling function competed for receiving the input, although I did not understand exactly why. The symptoms (hanging) were similar to your case, at least.

Sven
I don't see why that would cause any hangs. I also poll in Crafty (using select()) and debug using gdb all the time with no problems.

Typical advice:

(1) do not optimize code as that confuses tracing it back to a specific source line.

(2) breakpoints are ok, but printf''s are better.

I'd bet that printf's stuck at several points in that procedure show it is not hanging, but is being called repeatedly by something that is hung in an infinite loop...
Chan Rasjid
Posts: 588
Joined: Thu Mar 09, 2006 4:47 pm
Location: Singapore

Re: Gdb Debugging Help !

Post by Chan Rasjid »

bob wrote:
Gian-Carlo Pascutto wrote:
Chan Rasjid wrote: I could "interrupt" the process through gdb and then restart it with "continue". The process will "continue" a little and it will stop at another point. This "interrupt/continue" could be repeated but the process will hang at another point.
How do you know it continues a little?

It sounds a bit like a logic error that causes the program to get into an infinite loop.
Are you certain you are hanging there? Or are you in a loop that calls the above code over and over so that each time you stop it, you show it to be at a different line in the procedure? Where it is not the procedure that is hung, but whatever is calling the procedure instead...
rasjid@debian:~/cowrie/debug/src$ ./cowrie

Cowrie Chess Version 1.0, 3rd Feb 2010

Auto Play Start
game 1 move e2e3
-+-+- pv +-+-+ 30 -+ pv -+-+ pv -+ pv -+ 30 -+- pv +-+-+-+ 28 -+- pv +- pv + pv -+- pv + 28 - pv +-+-+- pv +- pv + 25 -+-+- pv +-+- pv + pv 24 -+-+- pv +-+ pv -+ pv 21 - pv +-+ pv -+-+-+ pv 15 -+-+ pv -+ pv -+ pv -+ 13 -search_full failed / mate
score -7998
game 2 move e2e4
-+- pv + pv -+-+- pv + pv 29 -+-+-+- pv +-+ 24 - pv + pv -+-+-+-+ pv 23 -+- pv + pv -+-+

It hangs at game 2 as the "+-+_..." stops. I use time control of 60moves per 1min. So I could see the "+-+-..." about every second. When it stops, I could leave the computer alone for say 10 min and it still "hangs" there.

Code: Select all

   /* gen Bishop */
   for (mask = bits[s][Bishop]; mask; mask &= mask - 1){
      assert(allBits & (mask & -mask));
      from = firstone(mask);  /* from */
      // HANGS AT LINE BELOW 
      capt_mask = (ROT_DIAG7(from) | ROT_DIAG9(from)) & bits[xs][0];
      if (!(capt_mask & bits[xs][King]));
      else return NULL;
      for (; capt_mask; capt_mask &= capt_mask - 1){
         to = firstone(capt_mask);
         capture = pc_board[to];
         order = OrderCapture[Bishop][capture];
         if (capture ^ Pawn || !(board[to]->pMap[s] & bits[xs][Pawn]));
         else{
            order = OrderBadCaptureB;
         }
         max_qs_capture_pc = max(capture, max_qs_capture_pc);
         PACK_MOVE_CAPTURE(m++, from, to, Bishop, capture, order);
         assert(board[FROM(* (m-1))]->bb & bits[s][Bishop]);
         assert(board[TO(* (m-1))]->bb & bits[xs][capture]);
         assert(!(board[TO(* (m-1))]->bb & bits[xs][King]));
      }
   }
The process hangs in the block above in gen.

The frame stack is as follow:
home/rasjid/cowrie/src/gen.c
home/rasjid/cowrie/src/src.c
home/rasjid/cowrie/src/srcroot.c
home/rasjid/cowrie/src/auto.c
home/rasjid/cowrie/src/main.c

I now have some slight idea about what you mean. It could be an infinite loop within src.c that repeatedly calls a function within gen.c. Indeed I made some significant changes to src.c about partial generation of moves through 6 phases.

I have to check.

Best Regards,
Rasjid.
Chan Rasjid
Posts: 588
Joined: Thu Mar 09, 2006 4:47 pm
Location: Singapore

Re: Gdb Debugging Help !

Post by Chan Rasjid »

Bugs finally resolved!

As Bob suspected, the program hangs in rootsearch() that does not return a move.

Code: Select all

int rootsearch(....){
...

/* Infinite loop bug from goto RESEARCH when search returns x = -INFI; 
I use aspiration window and search returns -INFI if the move is invalid when the next gen() has a capture of the king.  
*/

RESEARCH:
            canExtend = (move_done <= 2);
            x = -search_full(i, -beta, -alpha, xside, side, 1, check_s);
/*            
        bugs cleared if line is change to :
            if (((best ^ -INFI) || (x > alpha) || (x == -INFI)));
    */    
                
            if (((best ^ -INFI) || (x > alpha)));// line with bug
            else{
               /* research to get an exact score above aspiration alpha */
               alpha = -INFI;
               goto RESEARCH;
            }

..
return result;
}
Thanks to All,
Rasjid.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Gdb Debugging Help !

Post by bob »

Chan Rasjid wrote:Bugs finally resolved!

As Bob suspected, the program hangs in rootsearch() that does not return a move.

Code: Select all

int rootsearch(....){
...

/* Infinite loop bug from goto RESEARCH when search returns x = -INFI; 
I use aspiration window and search returns -INFI if the move is invalid when the next gen() has a capture of the king.  
*/

RESEARCH:
            canExtend = (move_done <= 2);
            x = -search_full(i, -beta, -alpha, xside, side, 1, check_s);
/*            
        bugs cleared if line is change to :
            if (((best ^ -INFI) || (x > alpha) || (x == -INFI)));
    */    
                
            if (((best ^ -INFI) || (x > alpha)));// line with bug
            else{
               /* research to get an exact score above aspiration alpha */
               alpha = -INFI;
               goto RESEARCH;
            }

..
return result;
}
Thanks to All,
Rasjid.
Nothing like a little "experience". :) It does come with time. Once you teach long enough, there are very few bugs that don't jump out right away.
Chan Rasjid
Posts: 588
Joined: Thu Mar 09, 2006 4:47 pm
Location: Singapore

Re: Gdb Debugging Help !

Post by Chan Rasjid »

bob wrote:
Chan Rasjid wrote:Bugs finally resolved!

As Bob suspected, the program hangs in rootsearch() that does not return a move.

Code: Select all

int rootsearch(....){
...

/* Infinite loop bug from goto RESEARCH when search returns x = -INFI; 
I use aspiration window and search returns -INFI if the move is invalid when the next gen() has a capture of the king.  
*/

RESEARCH:
            canExtend = (move_done <= 2);
            x = -search_full(i, -beta, -alpha, xside, side, 1, check_s);
/*            
        bugs cleared if line is change to :
            if (((best ^ -INFI) || (x > alpha) || (x == -INFI)));
    */    
                
            if (((best ^ -INFI) || (x > alpha)));// line with bug
            else{
               /* research to get an exact score above aspiration alpha */
               alpha = -INFI;
               goto RESEARCH;
            }

..
return result;
}
Thanks to All,
Rasjid.
Nothing like a little "experience". :) It does come with time. Once you teach long enough, there are very few bugs that don't jump out right away.
I was sort of laughing at my own self or at stupidity - I am rather forgiving :)

It just illustrate a simple principle - that one can sometimes be just forgetful (stupid / a dumb moment). If a move is not found (hangs) it simply means an infinite loop higher up somewhere.

Thanks,
Rasjid
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Gdb Debugging Help !

Post by bob »

Chan Rasjid wrote:
bob wrote:
Chan Rasjid wrote:Bugs finally resolved!

As Bob suspected, the program hangs in rootsearch() that does not return a move.

Code: Select all

int rootsearch(....){
...

/* Infinite loop bug from goto RESEARCH when search returns x = -INFI; 
I use aspiration window and search returns -INFI if the move is invalid when the next gen() has a capture of the king.  
*/

RESEARCH:
            canExtend = (move_done <= 2);
            x = -search_full(i, -beta, -alpha, xside, side, 1, check_s);
/*            
        bugs cleared if line is change to :
            if (((best ^ -INFI) || (x > alpha) || (x == -INFI)));
    */    
                
            if (((best ^ -INFI) || (x > alpha)));// line with bug
            else{
               /* research to get an exact score above aspiration alpha */
               alpha = -INFI;
               goto RESEARCH;
            }

..
return result;
}
Thanks to All,
Rasjid.
Nothing like a little "experience". :) It does come with time. Once you teach long enough, there are very few bugs that don't jump out right away.
I was sort of laughing at my own self or at stupidity - I am rather forgiving :)

It just illustrate a simple principle - that one can sometimes be just forgetful (stupid / a dumb moment). If a move is not found (hangs) it simply means an infinite loop higher up somewhere.

Thanks,
Rasjid
All I can say is that if someone (myself in this case) spots a bug instantly, it most likely means they have seen it before. I won't say whether it was in my code or not, however. :)

That is a good reason to use printf's to debug, however, as that would show that the function is getting re-entered over and over and over, which the debug stack traceback doesn't show.