Stockfish-1.9 Segmentation Fault

[mcostalba]

So I don't construe this post as a bug report.

I think it is instead because is not the intended behaviour. It is a bug that works by luck...but still a bug

Thanks for pointing out this.

[UncombedCoconut]

You're welcome. I am sorry that this (with near-certainty) does nothing to resolve the problem with the icc compile. Louis: Can you try running under gdb?
gdb stockfish
> set args bench 32 1 10 default depth
> run
[wait for the KABOOM]
> bt full
> quit

(If the # of threads were not equal to 1, "thread apply all bt full" would be preferred over "bt full".)

[edit]: The info to include would be the output of gdb after the "bt full" command. It will probably be verbose due to printing the value of large arrays, so it's probably a good idea to use a pastebin.

[zullil]

http://zullil.lafayette.edu/temp/gdb_bt.txt

[Sven]

Hi,

function ScalingFunction<KPsK>::apply() (endgame.cpp) uses a utility function in_front_bb() (bitboard.h) which takes a rank as second argument and indexes into a [2][8] array, but the apply() function passes a square to it (ksq) which is 0..63. That might be responsible for the crash.

The type of ksq is 'Square' and in_front_bb() requires a 'Rank'. Both are different enums (square.h) but the compiler seems to accept this (maybe with a warning?).

I looked at 1.9.1 sources, of course I do not know whether this problem was already present in 1.9, but if it was then it is quite likely that it causes the effect seen by Louis.

Sven

[mcostalba]

I looked at 1.9.1 sources, of course I do not know whether this problem was already present in 1.9, but if it was then it is quite likely that it causes the effect seen by Louis.

I don' t have access to my PC now, but I am quite confident that does exist an overload (another function with the same name) that takes a square, otherwise compiler should have risen an error (a warning is not enough)....

[zullil]

Hi,

function ScalingFunction<KPsK>::apply() (endgame.cpp) uses a utility function in_front_bb() (bitboard.h) which takes a rank as second argument and indexes into a [2][8] array, but the apply() function passes a square to it (ksq) which is 0..63. That might be responsible for the crash.

The type of ksq is 'Square' and in_front_bb() requires a 'Rank'. Both are different enums (square.h) but the compiler seems to accept this (maybe with a warning?).

I looked at 1.9.1 sources, of course I do not know whether this problem was already present in 1.9, but if it was then it is quite likely that it causes the effect seen by Louis.

Sven

Thanks for your work on this.

In bitboard.h in the 1.9 sources, I find

Code: Select all

/// in_front_bb() takes a color and a rank or square as input, and returns a
/// bitboard representing all the squares on all ranks in front of the rank
/// (or square), from the given color's point of view.  For instance,
/// in_front_bb(WHITE, RANK_5) will give all squares on ranks 6, 7 and 8, while
/// in_front_bb(BLACK, SQ_D3) will give all squares on ranks 1 and 2.

inline Bitboard in_front_bb(Color c, Rank r) {
  return InFrontBB[c][r];
}

inline Bitboard in_front_bb(Color c, Square s) {
  return InFrontBB[c][square_rank(s)];
}

I'm not much of a programmer, but which definition of in_front_bb will the compiler use? Or will it choose based on the type of the second argument?

Let me recompile and this time look at all warnings.

[Sven]

I looked at 1.9.1 sources, of course I do not know whether this problem was already present in 1.9, but if it was then it is quite likely that it causes the effect seen by Louis.

I don' t have access to my PC now, but I am quite confident that does exist an overload (another function with the same name) that takes a square, otherwise compiler should have risen an error (a warning is not enough)....

Right, missed that. But then the in_front_bb(Color, Rank) version seems to be unused.

Can you exclude that the compiler has mixed up the two overloaded versions?

Sven

[zullil]

As a test, I modified bitboard.h to include a function named Bitboard in_front_bb_sq

Code: Select all

/// in_front_bb() takes a color and a rank or square as input, and returns a
/// bitboard representing all the squares on all ranks in front of the rank
/// (or square), from the given color's point of view.  For instance,
/// in_front_bb(WHITE, RANK_5) will give all squares on ranks 6, 7 and 8, while
/// in_front_bb(BLACK, SQ_D3) will give all squares on ranks 1 and 2.

inline Bitboard in_front_bb(Color c, Rank r) {
  return InFrontBB[c][r];
}

inline Bitboard in_front_bb(Color c, Square s) {
  return InFrontBB[c][square_rank(s)];
}

inline Bitboard in_front_bb_sq(Color c, Square s) {
	return InFrontBB[c][square_rank(s)];
}

I then modified endgame.cpp to call this new function:

Code: Select all

/// KPsKScalingFunction scales endgames with king and two or more pawns
/// against king. There is just a single rule here: If all pawns are on
/// the same rook file and are blocked by the defending king, it's a draw.
template<>
ScaleFactor ScalingFunction<KPsK>&#58;&#58;apply&#40;const Position& pos&#41; const &#123;

  assert&#40;pos.non_pawn_material&#40;strongerSide&#41; == VALUE_ZERO&#41;;
  assert&#40;pos.piece_count&#40;strongerSide, PAWN&#41; >= 2&#41;;
  assert&#40;pos.non_pawn_material&#40;weakerSide&#41; == VALUE_ZERO&#41;;
  assert&#40;pos.piece_count&#40;weakerSide, PAWN&#41; == 0&#41;;

  Square ksq = pos.king_square&#40;weakerSide&#41;;
  Bitboard pawns = pos.pieces&#40;PAWN, strongerSide&#41;;

  // Are all pawns on the 'a' file?
  if (&#40;pawns & ~FileABB&#41; == EmptyBoardBB&#41;
  &#123;
      // Does the defending king block the pawns?
      if (   square_distance&#40;ksq, relative_square&#40;strongerSide, SQ_A8&#41;) <= 1
          || (   square_file&#40;ksq&#41; == FILE_A
              && &#40;in_front_bb_sq&#40;strongerSide, ksq&#41; & pawns&#41; == EmptyBoardBB&#41;)
          return SCALE_FACTOR_ZERO;
  &#125;
  // Are all pawns on the 'h' file?
  else if (&#40;pawns & ~FileHBB&#41; == EmptyBoardBB&#41;
  &#123;
    // Does the defending king block the pawns?
    if (   square_distance&#40;ksq, relative_square&#40;strongerSide, SQ_H8&#41;) <= 1
        || (   square_file&#40;ksq&#41; == FILE_H
            && &#40;in_front_bb_sq&#40;strongerSide, ksq&#41; & pawns&#41; == EmptyBoardBB&#41;)
        return SCALE_FACTOR_ZERO;
  &#125;
  return SCALE_FACTOR_NONE;
&#125;

I did make clean and recompiled. The binary crashes as before. Thus I conclude that Marco is correct that this isn't the problem. Thanks anyway.

Louis

[bob]

You're welcome. I am sorry that this (with near-certainty) does nothing to resolve the problem with the icc compile. Louis: Can you try running under gdb?
gdb stockfish
> set args bench 32 1 10 default depth
> run
[wait for the KABOOM]
> bt full
> quit

(If the # of threads were not equal to 1, "thread apply all bt full" would be preferred over "bt full".)

[edit]: The info to include would be the output of gdb after the "bt full" command. It will probably be verbose due to printing the value of large arrays, so it's probably a good idea to use a pastebin.

Just so you know, you don't have to do that "set args" thing. Just "run arg1 arg2 ... argn" will work just fine... That's the only way I have ever done this, in fact...

[mcostalba]

Can you exclude that the compiler has mixed up the two overloaded versions?

Yes I do

Otherwise it would be pretty serious, strict type checking is one of the pillars of C++ (this does not mean that do not exsist some obscure and tricky corner case, but for sure not this one, this is a mainstream case and it must work even in the worst compiler you can imagine).

IOW if this basic function overload would suddendly not be correctly compiled you would see an almost istant crash in little C++ toys like Firefox, Chrome, Word, Excel, Oracle DB and so on....