Bug in xboard 4.4.4; banned for ICC rated play!

[hgm]

Hmm, it seems to work on myICS. At least every time I try to include a ";" inside a tell, the tell is cut short.

Multiple-string options is something XBoard does not have. I still think the \n ought to work in this situation, or in fact in any string variable. I recallI added something to make "new\nrandom" work as -initString long ago, by writing an Escape() function that recognizes \n, \t, \r. Apparently I did not apply that in a completely general way. I will have a look at it tomorrow.

[bob]

I could not find -xrm amongst the XBoard options, and have no idea what it is supposed to do. Why don't you simply say

-zippyGameEnd "seek 5\nseek 15\n"

I played with this and similar for a while and no luck because the embedded newlines are never translated into real newlines.

The best I was able to do was a simple:

Code: Select all

-zippyGameEnd "seek 5"

Looking at the source, xboard always supplies a final newline for the option, so the "\n" is not needed and in fact will cause a failure if present.

I think that the "-xrm" option is something specific to X Windows and for some reason no longer works with the latest xboard.

Server side macros aren't too much help as they may expand into a maximum of a single command.

In any case, I now have Symbolic connected to FICS and ICC, both using xboard 4.5.2a. But in both cases, there is only a single seek ad posted at the end of a game.

I think what you want is something like this, if my memory is correct (on ICC at least):

"multi seek 5 3 r; seek 25 25 r; seek 0 1 r"

[sje]

I think what you want is something like this, if my memory is correct (on ICC at least):

"multi seek 5 3 r; seek 25 25 r; seek 0 1 r"

This works on ICC. Yay! Alas, FICS has no clue about "multi".

And the modify-after-free bug has reappeared under Mac OS/X 10.7, this time on FICS:

Code: Select all

fics% xboard(57486) malloc: *** error for object 0x7fbde849de00: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
./AutoFICS: line 20: 57486 Abort trap: 6           /usr/local/bin/xboard -autocomm -autoflag -fcp "./Symbolic -c xboard" -fd $HOME/Arena/Symbolic -hideThinkingFromHuman false -ics -icshost freechess.org -icslogon $HOME/Arena/Symbolic/ficslogon -sgf $HOME/Arena/Symbolic/fics.pgn -size Medium -thinking -xalarm -xanimate -xbuttons -xzab -xzadj -zippyMaxGames 4 -zippyGameEnd "seek 5" -zp

[sje]

I removed the autocomm option from the xboard invocation and restarted the program both on FICS and ICC. The idea is to see if this will make the modify-after-free bug hide in shame.

[hgm]

I checked the XBoard source, and it seems I only apply the EscapeExpand routine to -first/secondInitString and -first/scecondComputerString.

Would it be preferable to systematically subject all XBoard string options to such escape expansion? On first glance I don't see much objection to that. (I am less sure about WinBoard, where \ is a quite common character in path names.)

WinBoard / XBoard makes a distinction between file-name options and other string options, so in principle it could be possible to only subject plain text strings to escape expansion, and leave all file names alone. This is probably preferable even in XBoard; there seems little reason to ever use CR, LF or TAB in filenames. (And TABs could be simply typed anyway.)

Note about the malloc problem, that also here applies there is only a chance of fixing it when I have the xboard.debug file of a crash. When all else fails, I could make a special version that logs info on every malloc and free call in the debug file, but for now I assume it would be enugh for deducing the cause if I can see what event triggers it, and what was the input history at that point.

[sje]

I would not have xboard do any escape character processing for any option values. Instead, have the appropriate options take zero or more strings and have these handled as if each had a trailing newline as needed.

Example:

Code: Select all

-zippyGameEnd "seek 1 1" "seek 5 0" "seek 15 0" 

It is probably a good idea to have xboard and winboard operate the same as much as possible. However, I don't use winboard, so I can't test it.

I suspect that the modify-after-free bug may not be easily trappable under Windows or Linux because of a possible lack of runtime checking. I will continue to test without autocomm to see if it happens again under Mac OS/X (which is really OpenBSD).

The unexpected-undo bug just happened again on FICS. This is somewhat annoying particularly when all games are run with the server notakeback option active.

And now, a feature request: It would be useful to add a capability feature called connected to the protocol. The command connected would be sent once to an engine immediately after xboard establishes a connection with the ICS. This would allow the program to send various one-time commands to the ICS, like setting notes, formula, etc.

[sje]

On second thought, there could be some deeper ambiguity problems with the multiple string parameter approach. A better idea would be to allow multiple instances of the same option, each with a single string parameter.

Example:

Code: Select all

-zippyGameEnd "seek 5" -zippyGameEnd "seek 15"

[hgm]

Unfortunately this would be totally at odds with the current way XBoard processes options, which basically leads to all options being processed multiple times: first from the master settings file to redefine defaults, then from the file with the saved user settings, then from the command line, then possibly from the engine install line. If each time the option was processed it wouldbe appended, rather than replaced, a disastrous multiplication ofall string options would occur.

To have bare strings without a preceeding option name is also a bit problematic, as in the current version such options default to a game file.

Wy are you so against recognizing and expanding the standard escape sequences in the options? To me that seems an ideal and intuitive solution. Especially since in some of the options (such as -initString) it is already done anyway.

[sje]

Wy are you so against recognizing and expanding the standard escape sequences in the options? To me that seems an ideal and intuitive solution. Especially since in some of the options (such as -initString) it is already done anyway.

One reason is that the use of the backslash character would either confuse winboard users or would require different handling for winboard escape processing, all due to the prevalence of said character in Windows file names.

The second reason is that from a Unix standpoint, only the shell should be doing escape processing for option values.

I suppose the least objectionable technique would to be to designate a character specifically for internal string separation. I suggest using a semicolon as this has some Unix heritage in this context. So,

Code: Select all

-zippyGameEnd "seek 1 1;seek 5 0;seek 15 0"

[hgm]

This seems the worst of all: basically you are now defining your own, non-standard escape for linefeed, namely ';'. And what would happen when people really want a semicolon in their string?

I don't think that \n would confuse Windows users any more than Linux user. It might confuse non-(C-)programmers. But ctually the '\n'escape has been part of WinBoard since pre-historic times, in the default value for the -initString ("new\nrandom"). It is in XBoard that this is comparatively new, as Tim never saw any need to add this, as the Linux shell, unlike the Windows command prompt, does allow you to include real linfeeds in strings, provided you preceed them with a backslash. Not knowing that this was possible, and receiving complaints from people that also didn't know, I ported this escape expansion for -initString to XBoard.

If the philosophy is that we should leave escape expanding to the shell, I think we should draw the logical conclusion that we should conform to the shell syntax, which is

-zippyGameEnd "seek 5\
seek 15"

Never mind if that is ugly; it is up to the shell developers to fix that, and not our responsibility.

Note that originally, when this -xrm option was still understood, you also were using a \n in the string. Apparently the X-server does perform escape expanding on its options that the shell doesn't do.