Re: [Bug-XBoard] xboard: Error: second chess program exited unexpectedly

[h.g. muller]

At 11:45 31-10-2009 -0700, Tim Mann wrote:
> The double free worries me more than the XtRemoveGrab error.  Of course
> they could be related, and it would be best to fix both even if they aren't.

OK, for the record: I had some more e-mail exchanges with the reporter of 
this bug,
and it turned out we were dealing with a combination of problems here. For 
one, he
was using 4.4.0~beta1, and what he showed was not the debug file but the 
console
output. The 'StartChildProcess' messages thus go to the wrong output 
channel, I think.
This made me misunderstand when the crash actually happened; in fact it did 
not occur
at startup of the engines at all, but after a game, when the user was 
trying to open the
Engine #N Settings dialog. The unlisted-widget problem was an already-fixed bug
(sept 30 commit) that tried to set focus to a text-edit in the dialog while 
there were none.
(And there were none for Toga2, because the user was using an obsolete 
Polyglot that
did not transmit any engine options.)

Now the third problem was that the bitbase implemetation of Toga2 is buggy, 
and that
the user was using it with bitbases, so we were also dealing with genuine 
Toga2 crashes
during the game. This of course cannot be blamed on XBoard, but the error 
exit seemed
to be unclean, and kept printing the free() complaint and stack trace in 
the console. I could
trace that to the second engine dying while the first is thinking. The 
dying engine causes an
immediate read error, which triggers a fatal-error popup. But as long as 
the user does not
close the popup, the second engine keeps thinking, and sooner or later 
spits out a move.
This now hit a bug from my hand: The dying engine had set 
gameInfo.resultDetails to point
to a local buffer, and a move coming in tries to free() the resultDetails 
and set result to "*",
because the game is obviously still continuing. This crashed XBoard; 
resultDetails
must only be assigned through strdup, or the free() chokes, and I did not 
know it...

If I assign "engine exited unexpectedly" to resultDetails using strdup, 
XBoard no longer
crashes. But then the behavior is not really the desired behavior anymore. 
(In fact a
crash was close to the desired behavior; we were working on an error exit, 
after all...)

In stead of automatically terminating, XBoard now pops up a _second_ fatal 
error:
After receiving the move from the opponent it tries to send it to the dead 
engine,
which leads to a broken-pipe error. XBoard hangs until the user closes both
error popups. The double error is undesirable, and in fact now messes up proper
error reporting in the PGN. This will have to be re-thought a little bit. A 
move coming
in from an opponent of an already dead engine should not be added to the PGN,
so some form of flagging the alive status of engines must be implemented.