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.
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard
