Nabble - Gnu - Xboard - Bugs

[bug #28077] xboard needs to link against x11

2009-11-29T11:41:44Z

Update of bug #28077 (project xboard):

Status: Ready For Test => Fixed
Open/Closed: Open => Closed

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?28077>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #28077] xboard needs to link against x11

2009-11-29T02:57:42Z

Follow-up Comment #2, bug #28077 (project xboard):

It builds fine with the latest code in git.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?28077>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #28077] xboard needs to link against x11

2009-11-28T09:57:14Z

Update of bug #28077 (project xboard):

Status: None => Ready For Test
Assigned to: None => apersaud

_______________________________________________________

Follow-up Comment #1:

Hi

think I fixed it. Can you test the latest code in git (branch v4.4.x)? You
need to run ./autogen, ./configure and then make.

thanks for reporting

ARUN

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?28077>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #28077] xboard needs to link against x11

2009-11-22T19:32:38Z

URL:
<http://savannah.gnu.org/bugs/?28077>

Summary: xboard needs to link against x11
Project: XBoard
Submitted by: None
Submitted on: Mon 23 Nov 2009 03:32:37 AM UTC
Category: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

Hi,

xboard uses symbols from x11 but does not link to x11 explicitly. This leads
to a build failure while using binutils-gold, which defaults to
--no-add-needed.

Add -lX11, -lXt and -lXmu to xboard_LDADD fixes the problem.

For more explanations, see:
http://wiki.debian.org/qa.debian.org/FTBFS#A2009-11-02Packagesfailingbecausebinutils-gold.2BAC8-indirectlinking
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556691

Best Regards,
Vincent Legout

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?28077>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: What's Intrinsic? Did I fail to install something?

2009-11-07T15:09:26Z

Hi

Per Gunnarsson wrote:
> Script started on Sat Nov 7 23:07:56 2009
> /home/per/Desktop/xboard-4.4.1$ uname -a
> OpenBSD mustafejen.kicks-ass.org 4.6 GENERIC#58 i386
> /home/per/Desktop/xboard-4.4.1$ ./configure
>[...]
> checking for X11/Intrinsic.h... no
> Xt headers not found

seems like you missing some header files. Don't know how that's
organized on OpenBSD. I'm using openSUSE and there that file come with
the package xorg-x11-libXt-devel.

HTH

Arun

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

What's Intrinsic? Did I fail to install something?

2009-11-07T14:10:53Z

Script started on Sat Nov 7 23:07:56 2009
/home/per/Desktop/xboard-4.4.1$ uname -a
OpenBSD mustafejen.kicks-ass.org 4.6 GENERIC#58 i386
/home/per/Desktop/xboard-4.4.1$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for library containing strerror... none required
checking for a BSD-compatible install... /usr/bin/install -c
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking for remsh... no
checking for rsh... rsh
checking for makeinfo... makeinfo
checking for nroff... nroff -man
checking for awk... /usr/bin/awk
checking for perl... /usr/bin/perl
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking whether time.h and sys/time.h may both be included... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking return type of signal handlers... void
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking stropts.h usability... no
checking stropts.h presence... no
checking for stropts.h... no
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking sys/systeminfo.h usability... no
checking sys/systeminfo.h presence... no
checking for sys/systeminfo.h... no
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for _getpty... no
checking for grantpt... no
checking for setitimer... yes
checking for usleep... yes
checking for gettimeofday... yes
checking for random... yes
checking for gethostname... yes
checking for setlocale... yes
checking for getpseudotty in -lseq... no
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking whether -R must be followed by a space... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking X11/Intrinsic.h usability... no
checking X11/Intrinsic.h presence... no
checking for X11/Intrinsic.h... no
Xt headers not found
/home/per/Desktop/xboard-4.4.1$ make
make: no target to make.
/home/per/Desktop/xboard-4.4.1$ ./xboard -debug
/bin/ksh: ./xboard: not found
/home/per/Desktop/xboard-4.4.1$ exit

Script done on Sat Nov 7 23:09:03 2009

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27951] xboard-4.4.1 won't build on OS X

2009-11-05T19:05:52Z

Update of bug #27951 (project xboard):

Status: None => Ready For Test

_______________________________________________________

Follow-up Comment #1:

added -lXmu to the git version. Can you test it? Thanks for reporting.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27951>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27951] xboard-4.4.1 won't build on OS X

2009-11-05T08:34:44Z

URL:
<http://savannah.gnu.org/bugs/?27951>

Summary: xboard-4.4.1 won't build on OS X
Project: XBoard
Submitted by: None
Submitted on: Thu 05 Nov 2009 04:34:43 PM UTC
Category: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

Tried the usual

./configure
make

Got

gcc -o xboard backend.o book.o childio.o gamelist.o lists.o moves.o
parser.o pgntags.o uci.o xboard.o xedittags.o xengineoutput.o xgamelist.o
xhistory.o xoptions.o zippy.o -lm -lXpm -lSM -lICE -lXaw -L/usr/X11/lib
-R/usr/X11/lib -lX11 -lXt
Undefined symbols:
"__XA_UTF8_STRING", referenced from:
__XA_UTF8_STRING$non_lazy_ptr in xboard.o
"__XA_TARGETS", referenced from:
__XA_TARGETS$non_lazy_ptr in xboard.o
"_XmuInternAtom", referenced from:
_SendPositionSelection in xboard.o
_SendPositionSelection in xboard.o
_SendPositionSelection in xboard.o
_CopyPositionProc in xboard.o
_PastePositionProc in xboard.o
_SendGameSelection in xboard.o
_SendGameSelection in xboard.o
_SendGameSelection in xboard.o
_CopyGameProc in xboard.o
_PasteGameProc in xboard.o
"__XA_CLIPBOARD", referenced from:
__XA_CLIPBOARD$non_lazy_ptr in xboard.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [xboard] Error 1
make: *** [all] Error 2

The fix was to add -lXmu to

xboard_LDADD = -lm -lXpm -lSM -lICE -lXaw -lXmu -L/usr/X11/lib
-R/usr/X11/lib -lX11 -lXt

in the Makefile.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27951>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27901] Incorrect error message when in double chess and trying to capture one of the attacking pieces

2009-11-03T18:23:06Z

Update of bug #27901 (project xboard):

Status: None => Fixed
Open/Closed: Open => Closed

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27901>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27901] Incorrect error message when in double chess and trying to capture one of the attacking pieces

2009-11-03T08:56:56Z

Follow-up Comment #4, bug #27901 (project xboard):

I retested with 4.4.1 today, and the bug is gone. Thanks.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27901>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: xboard: Error: second chess program exited unexpectedly

2009-11-02T09:29:15Z

HG, thanks for letting us know what you found out there.

One small comment: I'm not sure why you say "A move coming in from an
opponent of an already dead engine should not be added to the PGN." Is
it because you've already added something like "0-1 {Engine crashed}"
to the PGN? If so, it seems similar to the case of an engine resigning
when not on move, or for that matter the human resigning when not on
move -- one more move might come in from the opposing engine. Do we
handle that now?

--
Tim Mann tim@... http://tim-mann.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: xboard: Error: second chess program exited unexpectedly

2009-11-02T00:47:45Z

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

[bug #27901] Incorrect error message when in double chess and trying to capture one of the attacking pieces

2009-11-01T08:08:28Z

Follow-up Comment #3, bug #27901 (project xboard):

OK, thanks. I tested it in 4.4.0, and it is indeed as you say, even without
engine in edit-game mode. But the mouse handler was completely re-written for
4.4.1, in conection with premove and the promotion popup fix, and I guess that
also fixed this problem.

H.G. Muller

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27901>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27901] Incorrect error message when in double chess and trying to capture one of the attacking pieces

2009-11-01T07:57:29Z

Follow-up Comment #2, bug #27901 (project xboard):

Winboard 4.4.0
I can try Winboard 4.4.1 when the binaries are out.
Legality test on.

I originally got it in a Fics game, but reproduced it setting up a position
playing again Fairy-Max.

Retrying it now I see that:

Dragging the Queen to capture the rock or the bishop will give me the correct
error message.

But clicking on the Queen and then clicking on the Rock or Bishop (as I tend
to move) will give me the confusing error message. Most probably because
Winboard think I'll try to move the black piece.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27901>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27857] "Draw move" on FICS

2009-11-01T07:25:16Z

Follow-up Comment #1, bug #27857 (project xboard):

Thanks for the suggestion. I was not aware of this special treatment of the
draw command by FICS. It seems to me XBoard should definitely support it. An
alternative to the UI you propose would be to hit F6 when it is your move, and
then move. This would work on ICC, where the "draw" command is initially
considered a draw offer, and sent to your opponent, but after your move will
automatically grant you a draw if one becomes claimable.

I guess XBoard in ICS play should check if a draw offer has been made before
the user's move, and if it is, send "draw MOVE" to the ICS to make the claim
work on FICS. ICC would probably ignore that, so for the benefit of ICC you
would still have to send the move as well. This combination:

<user hits F6>
draw
<user moves to 3rd repeat>
draw MOVE
MOVE

should have the desired effect on both FICS and ICC. It would draw a
(different) error message on both, though. Of course smarter code might decide
which of the two latter commands to send, but I am not sure how reliable this
can be made. (Would going on ics_type be sufficient?)

Engines in zippy mode send "offer draw" to XBoard, which in the above
sequence takes over the role of hitting F6.

H.G. Muller

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27857>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27901] Incorrect error message when in double chess and trying to capture one of the attacking pieces

2009-11-01T07:03:33Z

Follow-up Comment #1, bug #27901 (project xboard):

In which version are you getting this, and is this WinBoard or Xboard? And in
which mode (local engine, ICS, game viewer; Edit Game or Machine White /
Black). And is legality testing on/off?

I cannot reproduce it with WinBoard 4.4.1 and any combination of w/wo engine,
EditGame/Machine Plays or legality testing on/off. It always says "Illegal
move" or "Illegal move (rejected by first Chess Program) for me when it does
not accept it.

H.G. Muller

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27901>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27901] Incorrect error message when in double chess and trying to capture one of the attacking pieces

2009-11-01T06:43:39Z

URL:
<http://savannah.gnu.org/bugs/?27901>

Summary: Incorrect error message when in double chess and
trying to capture one of the attacking pieces
Project: XBoard
Submitted by: None
Submitted on: Sun 01 Nov 2009 14:43:38 UTC
Category: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

If you are in double check and tries to capture one of the attacking
pieces(and thus still be in chess from one of the pieces) you will get the
error message "It is white's turn" it should be "Illegal move".

Example FEN:

4r2k/8/2Q5/8/8/2b5/8/4K3 w - - 1 2

Qxc3 or Qxe8 will give the error message "It is white's turn" it should be
"Illegal move".

Qe6 (or any other Queen move) will give the correct error message "Illegal
move".

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27901>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27889] Initial board not drawn in match mode

2009-11-01T01:49:52Z

Follow-up Comment #7, bug #27889 (project xboard):

That depends on your setting of -matchPause. I usually set the pause to the
shortest possible value 10 (msec) when both engines support ping. The pause is
only needed to make sure the engine that is thinking gets the time to make its
move when the opponent resigns. Because otherwise that move might come in
after the next game has started, where it is illegal, or will lead to a later
move being illegal. When the engine supports ping you don't hae that problem.

H.G. Muller

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27889>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27889] Initial board not drawn in match mode

2009-11-01T00:38:35Z

Follow-up Comment #6, bug #27889 (project xboard):

I don't understand "the pause can be very short". Even with my fix the end
position is visible for 10 seconds. It just doesn't extend into the next game
anymore.

However, thanks for repairing the other about 15 points I reported in the
last month.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27889>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27889] Initial board not drawn in match mode

2009-10-31T14:10:41Z

Follow-up Comment #5, bug #27889 (project xboard):

Well, as far as I know it has always behaved like that, and I like it that
way. The pause between games can be very short when you use engines that
support ping, and the last moves of a game are usually instantaneous as well.
So intended or not, I will leave it like it is.

H.G. Muller

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27889>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27889] Initial board not drawn in match mode

2009-10-31T13:25:10Z

Follow-up Comment #4, bug #27889 (project xboard):

Sure, there is a delay but when the delay is over and clocks start new and
thinking output is displayed for the new game also the board should change to
the new one.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27889>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27889] Initial board not drawn in match mode

2009-10-31T13:21:52Z

Follow-up Comment #3, bug #27889 (project xboard):

It's in 4.4.1 (and older) and I could fix it for me by changing
Reset(FALSE, TRUE);
to
Reset(TRUE, TRUE);

in function NextMatchGame() in backend.c.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27889>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27889] Initial board not drawn in match mode

2009-10-31T13:17:46Z

Follow-up Comment #2, bug #27889 (project xboard):

Well, I just compiled 4.4.1 under Ubuntu 8.04, and the board appears for me,
before the first game of the match

The other behavior you describe is intended. It is more interesting to look
at the final position of the previous game, than to the initial position
(which you probably know...).

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27889>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: xboard: Error: second chess program exited unexpectedly

2009-10-31T11:45:58Z

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.

> >Warning: XtRemoveGrab asked to remove a widget not on the list
> >xboard: Error: second chess program (polyglot
> >/home/matrix/.polyglot/toga2.ini) exited unexpectedly
> >*** glibc detected *** xboard: double free or corruption (out):
> >0x00007fff12a1af40 ***

--
Tim Mann tim@... http://tim-mann.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: xboard: Error: second chess program exited unexpectedly

2009-10-31T11:32:52Z

At 18:21 31-10-2009 +0200, matrix one wrote:

>Hi,
>
>Is happend only with toga2
>
>
>
>Linux s3 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009
>x86_64 GNU/Linux
>
>xboard -debug -size huge -coords -scp 'polyglot
>/home/matrix/.polyglot/toga2.ini' -fcp 'polyglot
>/home/matrix/.polyglot/stockfish.ini'
>StartChildProcess (dir=".") polyglot /home/matrix/.polyglot/stockfish.ini
>StartChildProcess (dir=".") polyglot /home/matrix/.polyglot/toga2.ini
>Warning: XtRemoveGrab asked to remove a widget not on the list
>xboard: Error: second chess program (polyglot
>/home/matrix/.polyglot/toga2.ini) exited unexpectedly
>*** glibc detected *** xboard: double free or corruption (out):
>0x00007fff12a1af40 ***

Hmm, the RemoveGrab warning makes it a bit suspect. I could find only one
call to XtRemoveGrab()
in the entire source, and this is in ThawUI(). Apparently XBoard uses the
kludge to let a deaf-and-dumb
widget (the messageWidget) grab focus while waiting for the engine to
complete initialization.

I am not sure if we are dealing here with a bug in the error exit procedure
triggered by toga2 crashing,
or that something is badly wrong in XBoard that makes it unjustly believe
toga2 exits. I suspect
the former, as that would explain why this only happens with toga2, and not
with other engines.
Is this a reproducible error? If so, it would help to see the Polyglot log
file (which can be obtained
by setting PolyglotLog=true in the toga2.ini file), which mght indicate if
the trouble starts there.

H.G.

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27889] Initial board not drawn in match mode

2009-10-31T11:32:39Z

Follow-up Comment #1, bug #27889 (project xboard):

Thanks. Is this with today's new 4.4.1 release or something older? (I'm not
saying it's fixed in 4.4.1 -- haven't tried to reproduce it as yet.)

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27889>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27889] Initial board not drawn in match mode

2009-10-31T11:17:00Z

URL:
<http://savannah.gnu.org/bugs/?27889>

Summary: Initial board not drawn in match mode
Project: XBoard
Submitted by: None
Submitted on: Sat 31 Oct 2009 06:16:59 PM UTC
Category: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

Start Xboard in match mode -mg. When the 2nd game begins, the board is only
drawn after white's first move. This is particularly ugly, if the white engine
doesn't use a book and has to think on its 1st move. Then you can see the
clocks and thinking output already from game 2, but still see the old end
position until white moves.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27889>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

xboard: Error: second chess program exited unexpectedly

2009-10-31T09:21:13Z

Hi,

Is happend only with toga2

Linux s3 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux

xboard -debug -size huge -coords -scp 'polyglot /home/matrix/.polyglot/toga2.ini' -fcp 'polyglot /home/matrix/.polyglot/stockfish.ini'
StartChildProcess (dir=".") polyglot /home/matrix/.polyglot/stockfish.ini
StartChildProcess (dir=".") polyglot /home/matrix/.polyglot/toga2.ini
Warning: XtRemoveGrab asked to remove a widget not on the list
xboard: Error: second chess program (polyglot /home/matrix/.polyglot/toga2.ini) exited unexpectedly
*** glibc detected *** xboard: double free or corruption (out): 0x00007fff12a1af40 ***
======= Backtrace: =========
/lib/libc.so.6[0x7ff4684c1dd6]
/lib/libc.so.6(cfree+0x6c)[0x7ff4684c670c]
xboard[0x4157ea]
xboard[0x418762]
xboard[0x41bf5b]
xboard[0x43ad1f]
/usr/lib/libXt.so.6[0x7ff4682164bd]
/usr/lib/libXt.so.6(XtAppNextEvent+0xa9)[0x7ff4682166e9]
/usr/lib/libXt.so.6(XtAppMainLoop+0x43)[0x7ff468208bd3]
xboard[0x446b90]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7ff46846aabd]
xboard[0x404d89]
======= Memory map: ========
00400000-00513000 r-xp 00000000 08:01 57408                              /usr/games/xboard
00712000-00713000 r--p 00112000 08:01 57408                              /usr/games/xboard
00713000-00780000 rw-p 00113000 08:01 57408                              /usr/games/xboard
00780000-008dc000 rw-p 00000000 00:00 0
009b3000-00ac2000 rw-p 00000000 00:00 0                                  [heap]
7ff460000000-7ff460021000 rw-p 00000000 00:00 0
7ff460021000-7ff464000000 ---p 00000000 00:00 0
7ff4661f2000-7ff466208000 r-xp 00000000 08:01 17561                      /lib/libgcc_s.so.1
7ff466208000-7ff466407000 ---p 00016000 08:01 17561                      /lib/libgcc_s.so.1
7ff466407000-7ff466408000 r--p 00015000 08:01 17561                      /lib/libgcc_s.so.1
7ff466408000-7ff466409000 rw-p 00016000 08:01 17561                      /lib/libgcc_s.so.1
7ff466409000-7ff46640e000 r-xp 00000000 08:01 51838                      /usr/lib/libXfixes.so.3.1.0
7ff46640e000-7ff46660d000 ---p 00005000 08:01 51838                      /usr/lib/libXfixes.so.3.1.0
7ff46660d000-7ff46660e000 r--p 00004000 08:01 51838                      /usr/lib/libXfixes.so.3.1.0
7ff46660e000-7ff46660f000 rw-p 00005000 08:01 51838                      /usr/lib/libXfixes.so.3.1.0
7ff46660f000-7ff466618000 r-xp 00000000 08:01 23600                      /usr/lib/libXrender.so.1.3.0
7ff466618000-7ff466817000 ---p 00009000 08:01 23600                      /usr/lib/libXrender.so.1.3.0
7ff466817000-7ff466818000 r--p 00008000 08:01 23600                      /usr/lib/libXrender.so.1.3.0
7ff466818000-7ff466819000 rw-p 00009000 08:01 23600                      /usr/lib/libXrender.so.1.3.0
7ff466819000-7ff466822000 r-xp 00000000 08:01 30110                      /usr/lib/libXcursor.so.1.0.2
7ff466822000-7ff466a21000 ---p 00009000 08:01 30110                      /usr/lib/libXcursor.so.1.0.2
7ff466a21000-7ff466a22000 r--p 00008000 08:01 30110                      /usr/lib/libXcursor.so.1.0.2
7ff466a22000-7ff466a23000 rw-p 00009000 08:01 30110                      /usr/lib/libXcursor.so.1.0.2
7ff466a23000-7ff466a28000 r-xp 00000000 08:01 9083                       /usr/lib/libXdmcp.so.6.0.0
7ff466a28000-7ff466c27000 ---p 00005000 08:01 9083                       /usr/lib/libXdmcp.so.6.0.0
7ff466c27000-7ff466c28000 rw-p 00004000 08:01 9083                       /usr/lib/libXdmcp.so.6.0.0
7ff466c28000-7ff466c2a000 r-xp 00000000 08:01 82015                      /usr/lib/libXau.so.6.0.0
7ff466c2a000-7ff466e29000 ---p 00002000 08:01 82015                      /usr/lib/libXau.so.6.0.0
7ff466e29000-7ff466e2a000 r--p 00001000 08:01 82015                      /usr/lib/libXau.so.6.0.0
7ff466e2a000-7ff466e2b000 rw-p 00002000 08:01 82015                      /usr/lib/libXau.so.6.0.0
7ff466e2b000-7ff466e2e000 r-xp 00000000 08:01 82059                      /lib/libuuid.so.1.3.0
7ff466e2e000-7ff46702e000 ---p 00003000 08:01 82059                      /lib/libuuid.so.1.3.0
7ff46702e000-7ff46702f000 r--p 00003000 08:01 82059                      /lib/libuuid.so.1.3.0
7ff46702f000-7ff467030000 rw-p 00004000 08:01 82059                      /lib/libuuid.so.1.3.0
7ff467030000-7ff467032000 r-xp 00000000 08:01 8764                       /lib/libdl-2.10.1.so
7ff467032000-7ff467232000 ---p 00002000 08:01 8764                       /lib/libdl-2.10.1.so
7ff467232000-7ff467233000 r--p 00002000 08:01 8764                       /lib/libdl-2.10.1.so
7ff467233000-7ff467234000 rw-p 00003000 08:01 8764                       /lib/libdl-2.10.1.so
7ff467234000-7ff46724f000 r-xp 00000000 08:01 86399                      /usr/lib/libxcb.so.1.1.0
7ff46724f000-7ff46744e000 ---p 0001b000 08:01 86399                      /usr/lib/libxcb.so.1.1.0
7ff46744e000-7ff46744f000 r--p 0001a000 08:01 86399                      /usr/lib/libxcb.so.1.1.0
7ff46744f000-7ff467450000 rw-p 0001b000 08:01 86399                      /usr/lib/libxcb.so.1.1.0
7ff467450000-7ff467461000 r-xp 00000000 08:01 76673                      /usr/lib/libXext.so.6.4.0
7ff467461000-7ff467660000 ---p 00011000 08:01 76673                      /usr/lib/libXext.so.6.4.0
7ff467660000-7ff467661000 r--p 00010000 08:01 76673                      /usr/lib/libXext.so.6.4.0
7ff467661000-7ff467662000 rw-p 00011000 08:01 76673                      /usr/lib/libXext.so.6.4.0
7ff467662000-7ff467679000 r-xp 00000000 08:01 108551                     /usr/lib/libICE.so.6.3.0
7ff467679000-7ff467878000 ---p 00017000 08:01 108551                     /usr/lib/libICE.so.6.3.0
7ff467878000-7ff467879000 r--p 00016000 08:01 108551                     /usr/lib/libICE.so.6.3.0
7ff467879000-7ff46787a000 rw-p 00017000 08:01 108551                     /usr/lib/libICE.so.6.3.0
7ff46787a000-7ff46787d000 rw-p 00000000 00:00 0
7ff46787d000-7ff467885000 r-xp 00000000 08:01 23011                      /usr/lib/libSM.so.6.0.0
7ff467885000-7ff467a84000 ---p 00008000 08:01 23011                      /usr/lib/libSM.so.6.0.0
7ff467a84000-7ff467a85000 r--p 00007000 08:01 23011                      /usr/lib/libSM.so.6.0.0
7ff467a85000-7ff467a86000 rw-p 00008000 08:01 23011                      /usr/lib/libSM.so.6.0.0
7ff467a86000-7ff467a9e000 r-xp 00000000 08:01 36174                      /usr/lib/libXmu.so.6.2.0
7ff467a9e000-7ff467c9d000 ---p 00018000 08:01 36174                      /usr/lib/libXmu.so.6.2.0
7ff467c9d000-7ff467c9e000 r--p 00017000 08:01 36174                      /usr/lib/libXmu.so.6.2.0
7ff467c9e000-7ff467c9f000 rw-p 00018000 08:01 36174                      /usr/lib/libXmu.so.6.2.0
7ff467c9f000-7ff467caf000 r-xp 00000000 08:01 37388                      /usr/lib/libXpm.so.4.11.0Aborted (core dumped)
_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27790] Variant switch not detected

2009-10-31T02:23:23Z

Follow-up Comment #5, bug #27790 (project xboard):

The points mentioned in "original submission" & "comment #2" are working now.

I haven't tested the follow-up points mentioned in the commit messages
regarding "Variant Switch"

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27790>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27790] Variant switch not detected

2009-10-30T20:11:14Z

Update of bug #27790 (project xboard):

Status: None => Ready For Test

_______________________________________________________

Follow-up Comment #4:

Is this completely fixed now?

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27790>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #8847] Moving backward while examining on FICS not reported to engine

2009-10-30T20:10:12Z

Update of bug #8847 (project xboard):

Status: Ready For Test => Fixed
Open/Closed: Open => Closed

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?8847>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27857] "Draw move" on FICS

2009-10-30T02:34:39Z

URL:
<http://savannah.gnu.org/bugs/?27857>

Summary: "Draw move" on FICS
Project: XBoard
Submitted by: None
Submitted on: Fri 30 Oct 2009 09:34:38 AM UTC
Category: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

This is not a bug, just a suggestion.
On FICS the only secure way to claim a draw (3fold/50moves) with your next
move is prefixing your move with "draw ". Typing that is painful. Hitting "d"
right after your move gives the opponent the chance the premove out of the
drawn position. Unlike ICC, FICS doesn't take a draw offer before your move
into account.

For me I added AltDown/AltUp Actions (for the left Alt key) that just change
one variable. Depending on that var SendMoveToICS() prefixes the move with
"draw ".
Holding down Alt while moving sends "draw move" then.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27857>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27844] Escape sequences in popup messages

2009-10-29T10:17:36Z

Follow-up Comment #2, bug #27844 (project xboard):

OK, thanks fo the clarification. I tried to get in LINEFEEDS in my Ubuntu, by
escaping them with backslash, but it did not seem to work. But I am a Linux
newbie, so I might have done something wrong (Perhaps leaving out quoting
makes the difference?) Anyway, 4.4.x supports the escapes in the InitString.

It sounds good to have the "auto-close" feature available. We should mention
it in the specs then, though, so that authors know what they will get. I will
check how things currently work. I think the mouse handler currently starts
with ErrorPopDown()...

There is no need to _force_ an engine to exit after using "tellusererror".
Just that it can reserve the right to do so. (A right with it normally has
only after receiving "quit".) Some people complained about geting double error
popups on a fatal engine error. So I just want to suppress the "exited
unexpectedly" fatal-error popup of the GUI in this case. If the engine does
not exit, that would not appear anyway, and everything is fine.

H.G.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27844>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27844] Escape sequences in popup messages

2009-10-29T09:44:22Z

Follow-up Comment #1, bug #27844 (project xboard):

WinBoard converts n to a real newline in command-line arguments because there
is no way to put a real newline in a command-line argument under Windows,
whereas under Unix/Linux it's possible. However it probably makes sense to
backport that feature to xboard for convenience, because putting a real
newline into the command line is something people may not realize is
possible.

I can see that it makes sense in telluser, etc., too.

I think the idea was that telluser should give you a non-modal popup that
dismisses automatically if you click on the board (actually at one time I
think it just showed the message in the line where moves are shown, but that's
too easy to miss), while tellusererror should give a modal popup that would
have to be dismissed by clicking its [OK] button before you could do anything
else.

I don't remember if that distinction is observed in both xboard and WinBoard
4.2.7 and haven't checked 4.4.x. It might not be consistent between xboard
and WinBoard -- at one point I remember that at least one of them did the
wrong thing because I hadn't figured out how to make both modal and non-modal
popups under both X and Windows. I don't remember which case was missing or
if I fixed it later.

tellusererror wasn't meant to be a fatal error that would make the engine
exit, but it might be OK to redefine it that way. You'd have to check if
engine authors are using it for nonfatal errors.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27844>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[bug #27844] Escape sequences in popup messages

2009-10-29T00:58:15Z

URL:
<http://savannah.gnu.org/bugs/?27844>

Summary: Escape sequences in popup messages
Project: XBoard
Submitted by: None
Submitted on: Thu Oct 29 07:58:14 2009
Category: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

Currently escape sequences in the messages an engine gives with commads like
'telluser' or 'tellusererror' are not recognized, and printed litteraly. As a
consequence, engine authors are now dmanding new tell-like commands for
popping up multi-line message boxes.

Is there any reason not to recognize escape sequences for LF and TAB in such
messages? I would highly prefer that solution over adding (and implementing)
new tell*** commands. I recently noted that XBoard, unlke WinBoard did not
even recognize '\n' as LF in a user-supplied InitString, so that xboard
-firstInitString "new\nrandom\n" actually failed to start the engine! This is
fixed now, but it would be easy to make the same routine that expands the
escapes act on the messages passed by 'telluser' and 'tellusererror' before
displaying them.

H.G. Muller

P.S. what is the intended difference between 'telluser' and 'tellusererror'
anyway? Would it be safe to say (and put it in the protocol specs) that using
'tellusererror' allows the engine then to exit without waiting for 'quit'?
Currently the user gets a double error popup if that happens, one from the
engine, which is then eclipsed by a more cryptic one from XBoard (like "engine
xxx exited unexpectedly: broken pipe").

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?27844>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard