Gdb Debugging Help !

[Chan Rasjid]

I am using Linux debian and my snailchess is generally bug free and clear most asserts. In release mode, it plays normally with xboard except, recently, it occasionally hangs.

For debugging, I have an autoplay loop. Snailchess would be started in a linux terminal with :
rasjid@debian:~$ ./snailchess

As moves are made, the console will have printout of "+-+-+- ... etc". I use gdb to attach to my process so that if an assert is triggered, it will stop and I could examine things through my IDE KDevelop.

Recently, there is a problem with autoplay in debug mode - it simply hangs somewhere but not due to asserts being triggered (this is the usual conditions that autoplay will stop). 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.

I did not use this gdb "continue" command in the past. I don't know why the debugging session hangs when there seems to be no bug with the codes.

Does anyone have any hint to offer.

Thanks,
Rasjid

[Gian-Carlo Pascutto]

What does the backtrace ("bt") say at the moment it hangs?

[Sven]

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

[Chan Rasjid]

What does the backtrace ("bt") say at the moment it hangs?

My apology. I don't understand backtrace too well. I attach gdb to my process and if it stops somehow, my KDevelop IDE enables me to know at which line of which function control hangs. I could trace back how the control started form main, autoplay, rootsearch(), src(),qssrc(), gen()... and the code below is an example of when it hangs within gen() at line:

Code: Select all

 
// my rotated bitboard macros - works well in //release mode
#define ROT_DIAG7(sq)    rotate_diag7[sq][(brdRotDiag7 >> shift_diag7[sq]) & mask_diag7[sq]]
#define ROT_DIAG9(sq)    rotate_diag9[sq][(brdRotDiag9 >> shift_diag9[sq]) & mask_diag9[sq]]
#define ROT_FILE(sq)       rotate_file[sq][(allBits >> (((sq) & 56) + 1)) & 63]
#define ROT_RANK(sq)     rotate_rank[sq][(brdRotRank >> ((RANK(sq) << 3) + 1)) & 63]

capt_mask = (ROT_DIAG7(from) | ROT_DIAG9(from) | ROT_RANK(from) | ROT_FILE(from)) & bits[xs][0]; 

Code: Select all

   /* gen Queen */
   for (mask = bits[s][Queen]; mask; mask &= mask - 1){
      assert(allBits & (mask & -mask));
      from = firstone(mask);
      //EG, HANGS AT THE LINE BELOW
      capt_mask = (ROT_DIAG7(from) | ROT_DIAG9(from) | ROT_RANK(from) | ROT_FILE(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[Queen][capture];
         if (capture < Queen) {
            if ((board[to]->pMap[s] & bits[xs][Pawn])
                  || (board[to]->nMap & bits[xs][Knight]));
            else if ((board[to]->bMap & bits[xs][Bishop]) &&
                     ((bits[xs][Bishop] & ROT_DIAG7(to)) || (bits[xs][Bishop] & ROT_DIAG9(to))));
            else if ((capture ^ Rook) && (board[to]->rMap & bits[xs][Rook]) &&
                     ((bits[xs][Rook] & ROT_FILE(to)) || (bits[xs][Rook] & ROT_RANK(to))));
            else goto PACK_Q;
            order = OrderBadCaptureQ;
         }
PACK_Q:
         max_qs_capture_pc = max(capture, max_qs_capture_pc);
         PACK_MOVE_CAPTURE(m++, from, to, Queen, capture, order);
         assert(board[FROM(* (m-1))]->bb & bits[s][Queen]);
         assert(board[TO(* (m-1))]->bb & bits[xs][capture]);
         assert(!(board[TO(* (m-1))]->bb & bits[xs][King]));
      }
   }

To Sven: I suspected polling too. I have commented out all polling as it is run in console without the xboard interface. Still hangs.

I am not sure if it is the signal hangup SIGHUP. I could receive a notice about aborted due to SIGHUP when I close my linux terminal in certain manner - I can't reproduce easily.

Rasjid

[Sven]

To Sven: I suspected polling too. I have commented out all polling as it is run in console without the xboard interface. Still hangs.

I am not sure if it is the signal hangup SIGHUP. I could receive a notice about aborted due to SIGHUP when I close my linux terminal in certain manner - I can't reproduce easily.

As to your gen() function above, I can't see any reason for hanging in that code provided none of the assert's fires. If you do not corrupt your memory then this code should not cause hanging.

The SIGHUP is sent to child processes of a shell running within a window if you close that window, that's normal behaviour. Since usually you do not handle that signal (except for the case where your program runs under debugger control, where the debugger may do that for you), your process just quits on receiving SIGHUP as it does for any other signal by default.

I have to ask again, just for better understanding (maybe you already mentioned some answers but it is not clear for me):

1) Does the problem occur in release mode?
2) Does it occur in debug mode (with assert enabled)?
3) Does it occur when running your program under xboard GUI?
4) Does it occur when running in console mode, started from a Linux shell?
5) Does it occur when starting your program directly from the debugger, instead of attaching to the process later on?
6) Do you have "feature sigint=0" set?

Sven

[Chan Rasjid]

[quote="Chan
1) Does the problem occur in release mode?
2) Does it occur in debug mode (with assert enabled)?
3) Does it occur when running your program under xboard GUI?
4) Does it occur when running in console mode, started from a Linux shell?
5) Does it occur when starting your program directly from the debugger, instead of attaching to the process later on?
6) Do you have "feature sigint=0" set?

Sven

Answers to:
1) This hanging is fairly recent. The bulk of my code has not changed and previously in release/with assert, there is not this hangs. Only fairly recently in release mode it may hang, ie just go till timeout w/o making a move. I think it has nothing to do with time management.
2) Yes. In my debug mode assert is always enabled. I could easily add an assert(0) to test or intentionally corrupt my code to trigger the next assert. it will stop at the appropriate assert.
3) Yes. I could play tscp-snalichess-debug(with assert) and there is another bug, broken pipe (I think cause by exit(-1) ?) - another issue. So snailchess does at most 1 move only.
4) Yes. I use linux graphical terminal == bash shell.
5) Yes. I could bypass using linux terminal/shell. From KDevelop IDE I could just run debug. It is the same. It may play 1/2 complete games with the usual many moves and in the 3rd game it just hang after some moves. I could know at which line of code it hangs thru "interrupt". I checked the variables, etc. and everything's fine.
6) I don't know but I have:
signal(SIGINT, SIG_IGN);
signal(SIGTERM, SIG_IGN);
These are needed in xboard mode. In auto play, it hangs whether with or without.

Best Regards,
Rasjid

[Gian-Carlo Pascutto]

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.

[Chan Rasjid]

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.

I run autoplay this way:
1) start snailchess in linux terminal and in IDE, attach gdb to snailchess. "attaching" will stop the process as the "+-+- .." stops. I use "continue" and the process proceeds.
2) Before it hangs, I could "interrupt" and it will stop and I can know where it stops. "continue" will again let the process proceed until it hangs.
3) when it hangs (the "+-+-..." stops), I need to "interrupt" to know where it hangs. It can hang at many different points in different functions. These (same) functions have been working properly in the past.

It is unlikely infinite loop. If I do '"interrupt/continue" enough number of times, eg it will leave gen() where it hangs an then hangs outside of gen().

Rasjid

[Chan Rasjid]

.... If you do not corrupt your memory then this code should not cause hanging.
...
Sven

About corrupting memory, I cannot be sure. I have never ever properly checked for array out of bound, etc. or use valgrind.

I do have tons of asserts though, more than any other chess programmers !

Rasjid.

[bob]

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...