New XBoard alpha version. Please test!

[hgm]

I have a new alpha version of XBoard, and I hope some of you guys are willing to test it. There were several major changes, so it will really need extensive testing.

* I have taken the file selector from Ghostview and put it in XBoard
* The EvalGraph window is now iplemented
* It remembers its settings on a file. What the name of this file is, is configurable in a master settings file /etc/xboard/xboard.conf. The one that comes with the install uses ~/.xboardrc for this, (where settings would also be saved), but you can change that by editing it.
* Polyglot is invoked (with -fUCI / -sUCI) through the -adapterCommand line, without making temporary polyglot_1st.ini files. (So it only works with Polyglot 1.4.46b or newer).

At the moment it only available as a binary Debian package for i386 architecture at:
http://home.hccnet.nl/h.g.muller/xboard ... 1_i386.deb

[zamar]

I installed the package on my debian testing machine.

I type 'xboard' in console.

I get a message: "Failed to start first chess program fairymax on localhost."

Then tens of windows start popping up saying: "error writing to first chess program: broken pipe", but program doesn't quit until I close it.

If fairymax is needed for xboard to work properly, you need to add it on depends.

Joona

[hgm]

Hmm, the dozens of error boxes should not happen. I will look into that. It should exit after the first.

Debian is very reluctant with dependencies. Previously XBoard used GNU Chess as default engine, but they did not want to list a dependency on GNU Chess, because XBoard can also be used without an engine (as ICS client or PGN viewer).

In the future we will do away with the concept of a default engine, and make it possible to select an engine after startup. (Essentially something like the WB startup dialog, but which can be invoked at any time through the menu.) Then we can simply have XBoard start in -ncp mode when no engine was given, and, like WinBoard, XBoard will present a list of default engines from which you can select.

We already stumbled on another bug as well: it seems that XBoard only scales the clock font to the board size if there was not an explicit -clockFont argument. So it was a bad idea to save the -clockFont in the settings file: it always seems to use the font specified in the file now, even if you change board size.

[michiguel]

I have a new alpha version of XBoard, and I hope some of you guys are willing to test it. There were several major changes, so it will really need extensive testing.

* I have taken the file selector from Ghostview and put it in XBoard
* The EvalGraph window is now iplemented
* It remembers its settings on a file. What the name of this file is, is configurable in a master settings file /etc/xboard/xboard.conf. The one that comes with the install uses ~/.xboardrc for this, (where settings would also be saved), but you can change that by editing it.
* Polyglot is invoked (with -fUCI / -sUCI) through the -adapterCommand line, without making temporary polyglot_1st.ini files. (So it only works with Polyglot 1.4.46b or newer).

At the moment it only available as a binary Debian package for i386 architecture at:
http://home.hccnet.nl/h.g.muller/xboard ... 1_i386.deb

I could not install it
Miguel

Code: Select all

miguel@avefenix:~$ sudo dpkg -i xboard_4.devel~hgm-1_i386.deb 
[sudo] password for miguel: 
(Reading database ... 147070 files and directories currently installed.)
Preparing to replace xboard 4.2.7-7.1ubuntu2 (using xboard_4.devel~hgm-1_i386.deb) ...
Unpacking replacement xboard ...
dpkg-deb (subprocess): short read in buffer_copy (failed to write to pipe in copy)
dpkg-deb: subprocess paste returned error exit status 2
dpkg: error processing xboard_4.devel~hgm-1_i386.deb (--install):
 short read in buffer_copy (backend dpkg-deb during `./usr/share/man/man6/xboard.6.gz')
Processing triggers for menu ...
Processing triggers for man-db ...
Errors were encountered while processing:
 xboard_4.devel~hgm-1_i386.deb

[Michel]

I managed to get a segfault with the following (invalid) command line

Code: Select all

/usr/games/xboard ./gnuchess -lpf nice.fen

Backtrace:

Code: Select all

#0  0x080758f9 in GameListBuild ()
#1  0x08065929 in LoadGameFromFile ()
#2  0x0804d9c4 in InitBackEnd3 ()
#3  0x08093a89 in FireDelayedEvent ()
#4  0xb7b91107 in ?? () from /usr/lib/libXt.so.6
#5  0xb7b9123d in XtAppNextEvent () from /usr/lib/libXt.so.6
#6  0xb7b835d4 in XtAppMainLoop () from /usr/lib/libXt.so.6
#7  0x08088a60 in main ()

[Michel]

I noticed some other issues.

xboard.debug contains almost no useable information anymore, even if you start
xboard with -engineDebugOutput 1

The parsing of FEN's has changed. xboard now sends

setboard 2QN4/5pk1/1q2p2p/5p2/Pb3P1P/6PK/8/8 b

instead of the previous (and correct IMHO)

setboard 2QN4/5pk1/1q2p2p/5p2/Pb3P1P/6PK/8/8 b - - 0 1

[hgm]

I could not install it
Miguel

Initially the package I uploaded to my website was truncated (without warning), because I exceeded my disk quota on the server.

Check if what you have is 717278 bytes. If not, you will have to download it again.

[hgm]

I managed to get a segfault with the following (invalid) command line

Code: Select all

/usr/games/xboard ./gnuchess -lpf nice.fen

Well, it seems that WinBoard recognizes what is called "positional arguments": when it encounters an argument that is not an option name, it considers it a loadGameFile name. So that it starts to read the binarey ./gnuchess as if it contained games is intended behavior.

Of course that it crashes during this attempt is a bad thing, but understandable considering the contents of an executable file. It is likely caused by some buffer overflow because the 'lines' in the binary are too long; XBoard is almost completely naive w.r.t. buffer overflows, the only protection coming from the fact that most buffers are declared with a generous size. (Like 512 bytes for holding a chess move.) So I don't think this has anything to do with the modifications I made for this version.

[Michel]

So I don't think this has anything to do with the modifications I made for this version.

Well the previous versions of xboard certainly didn't crash in the case of invalid arguments.
They showed some kind of (impossibly long) help message.

There is already an argument for loading game files (-lgf). If xboard can not handle
gracefully the "positional arguments" of winboard (which I had never heard off, and never needed) then this feature should be disabled.

EDIT: I tried

xboard -fcp ./gnuchess -lgf ./gnuchess

on a prior version of xboard. xboard has some difficulty digesting the "gamefile" ./gnuchess,
but it does not crash.

The same command on this new version of xboard immediately leads to a hard crash.

[hgm]

Well, the problem is that it cannot handle the gnuchess binary as a game file. Not that it cannot handle the positional arguments. If you would have given

xboard mygames.pgn

with a regular PGN file it should have normally loaded the file, and I see no reason to disable that.

Apparently the tolerance for garbage input is lower in this version, but that does not necessarily mean a new bug was introduced. (I did not touch the game loading code at all.) Buffer overflows can have different effects due to unrelated chages, depending on what they happen to overwrite. The layout of global variables in memory of this version is very different from what it was. (I eliminated some large arrays.)

Of course I will try to locate the exact cause of the problem and try to cure it, but curing a crash on feeding it an executable in stead of a game file is not top priority: people should not do that in the first place.

The other bugs you reported are much worse, and I'll fix those first. The corrupted FEN I already traced to a wrong default value for the -first(second)NeedsNoncompliantFEN option: this should have been not an empty string, but a NULL pointer. (All option default values are now coming from a table shared by XBoard and WinBoard, where in previous WinBoards they were assigned at run time by dedicated code, so bugs in this area are likely.) This accidentally exposed a second, pre-existing bug, which was that an empty string here cuts the move numbers from the FEN as well. (While according to specs it should only have replaced the castling and e.p. field.) So actually we caught two for the price of one here!

I had not noticed this, because I had been testing with Fairy-Max, which does not support setboard, but uses the edit command, and thus never sees any FEN. Of course I also tested with Fruit to see if the new adapterCommand was working, but not with a setup position.