Xboard issue

[bob]

HGM (or anyone).. I ran into a previously unknown bug in xboard this afternoon. I installed whatever macports has on my office iMac and I was running a test game using my current version, which has a Hsu-like singular extension. I went to class and when I came back xboard had crashed with a segmentation fault. When I looked at what Crafty's search window had, it was something pretty ridiculous in terms of a PV that was over-extended... And on top of that my path grafting added in it's $.02, so I assume there is some finite limit on either the size of when I should send for the pv (info I suppose) or else something in the engine output window stuff that can overflow something.

Is there a limit that I can check for? I think the PV was something like 200 plies (100 full moves) long so it was BIG.

[hgm]

This is very well possible. XBoard basically does no buffer overflow checking at all, it relies on buffer sizes being chosen very generously. I never got to doing anything about that. Perhaps when I get to doing a complete rewrite ('XBoard 5.0') I would address this as well.

I will try to test with an engine modified to print a ridicuously long PV, to see if I can make it crash.

[Evert]

This is very well possible. XBoard basically does no buffer overflow checking at all, it relies on buffer sizes being chosen very generously.

Well, 200 moves should be enough for everybody, right?

I had a few hard limits like that (for instance, no more than 250 or so moves in a position), but I think I've managed to hit most of them by now (and gotten rid of them).

I did run into another XBoard limit the other day: in a Shogi game that ran for 500 moves XBoard aborted the game because it was too long. It prompted me to increase some constant and recompile. The position had both kings in the other promotion zone, surrounded by a host of promoted pieces (what counts as "impasse" in the rule description on Wikipedia).

[hgm]

Indeed, they don't have special impasse rules in Shogi for nothing. It is like playing a KK end-game with engines that do not want to claim draw!

XBoard's game history is kept in a static array. I could of course put in in allocated memory instead, and reallocate when overflow occurs. That is a bit of a hassle, as there are several arrays indexed by the move number (rather than all info on a position being neatly packed in a struct), so I would either have to (re)allocate all of these, or completely rewrite.

And there seemed little point in doing it. If there was no limit to the number of moves, such impasse games would probably go on for ever, which would almost certainly be something you also don't want. There is an adjudication option to declare a game as draw after a certain number of total moves, which can be set to avoid XBoard exiting at the hard limit. Normally it is switched off, but I guess it would be more sensible to configure it as 499 or so.

[Joost Buijs]

Why don't you make the buffer a lot larger? Memory is very cheap nowadays.

Yesterday I installed Winboard 4.8.0b and now the engine output shows 'dep' instead of 'depth', this looks rather ugly. Did you change this in the new version of Polyglot to spare just 2 characters of output?

[hgm]

Well, I have no idea how large the buffers are now. I know there is a lot of juggling going on with PVs, copying them from one buffer to another. As long as no one complains about it I don't even bother to figure out how exactly it works.

It is not Polyglot that creates the headers. So if there is a difference it must have been a change in WinBoard. I don't remember anymore why I wrote 'dep'; there seems space enough to write 'depth'. Probably for symmetry reasons, because I also wrote 'seldep'.

The underlying problem is that the standard font in the Engine Output window is proportionally spaced. So I don't know any other way to align the columns than use Tabs; padding with spaces doesn't work. But if the header titles get longer than the size of a Tab, the width of that column immediately doubles. Which looks very ugly, and is also very undesirable because space is at a premium with so much data to print. (And 100-moves-long PVs also don't fit very well in there...) Added to that is that the ouput format should be reasonably robust to changes in font size.