Xboard crashes with feature option

Discussions about the WinBoard protocol. Here you can also report bugs and request new features.

Moderators: hgm, Andres Valverde

Xboard crashes with feature option

Postby Miguel A. Ballicora » 23 Sep 2009, 01:35

When I send this feature option (Ubuntu Linux)

3094 <first : feature option="Book -check 1"
3094 >first : accepted option

xboard crashes when I try to access the Engine #1 Settings in the pull down menu

Miguel
User avatar
Miguel A. Ballicora
 
Posts: 160
Joined: 03 Aug 2005, 02:24
Location: Chicago, IL, USA

Re: Xboard crashes with feature option

Postby H.G.Muller » 25 Sep 2009, 16:58

You are correct. At the end of the dialog popup routine I set focus to the last text-edit (-spin or -string). But if there is a dialog without any text edits at all, this tries to acces a widget with a random number, which makes XBoard crash.

The remedy would be to comment out the SetFocus call at the very end of SettingsPopUp() in xoptions.c. An alternative would be to declare edit at the beginning of that routine as initialized to NULL, and put "if(edit)" in front of the SetFocus call.

I am not sure if these SetFocus calls are still needed; I put them in at a time where we had big trouble giving keyboard focus to window elements, and even then it failed for people that were using "desktop effects". But this could later be traced to a wrong order of libraries in the linker command. Now that we corrected that, most of the SetFocus calls might actually not be needed at all, and controls might automatically get and retain focus when you click them. Anyway, I will make sure it will be fixed in the next release, which we will probably make very soon forced by the egtbpath bug.
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: Xboard crashes with feature option

Postby Michel » 25 Sep 2009, 18:28

the next release, which we will probably make very soon


I think there is also a problem using a GUI book in a tournament. It works fine the first game but in the next game one of the engines refuses to move until it loses on time. Then the book works again for one game etc....

I have not really tried to debug this but I have observed it will all pairs of engines I tried.

I think I saw it in both WinBoard and xboard.
Michel
 
Posts: 513
Joined: 01 Oct 2008, 12:15

Re: Xboard crashes with feature option

Postby H.G.Muller » 25 Sep 2009, 19:53

This is in a WinBoard match (-mg > 1) ?

I just got in a report from WinBoard 4.4-JAWS that white does not start to play when black's first move is out of book.I have not looked into that yet either (except confirm that a game playing black against Fairy-Max indeed reproducibly hangs after 1. e4 a6).

What I did notice is that in engine-engine games in Windows I sometimes get the error message "Polyglot Book not valid" This might be a problem with both engines trying to access the book file in too rapid succession. I open and close the book file for every probe, which might not have been a good idea.
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: Xboard crashes with feature option

Postby Michel » 25 Sep 2009, 20:18

This is in a WinBoard match (-mg > 1) ?


Yes I should have written match instead of tournament,

This might be a problem with both engines trying to access the book file in too rapid succession.


That's strange. In Linux many processes can have the same file open. Don't know about windows though. I would
assume it's the same.
Michel
 
Posts: 513
Joined: 01 Oct 2008, 12:15

Re: Xboard crashes with feature option

Postby Miguel A. Ballicora » 26 Sep 2009, 09:07

H.G.Muller wrote:You are correct. At the end of the dialog popup routine I set focus to the last text-edit (-spin or -string). But if there is a dialog without any text edits at all, this tries to acces a widget with a random number, which makes XBoard crash.

The remedy would be to comment out the SetFocus call at the very end of SettingsPopUp() in xoptions.c. An alternative would be to declare edit at the beginning of that routine as initialized to NULL, and put "if(edit)" in front of the SetFocus call.

I am not sure if these SetFocus calls are still needed; I put them in at a time where we had big trouble giving keyboard focus to window elements, and even then it failed for people that were using "desktop effects". But this could later be traced to a wrong order of libraries in the linker command. Now that we corrected that, most of the SetFocus calls might actually not be needed at all, and controls might automatically get and retain focus when you click them. Anyway, I will make sure it will be fixed in the next release, which we will probably make very soon forced by the egtbpath bug.


Thanks,

Adding edit = NULL at the beginning and if (edit) SettingsPopUp() seems to fix it.

Miguel
User avatar
Miguel A. Ballicora
 
Posts: 160
Joined: 03 Aug 2005, 02:24
Location: Chicago, IL, USA


Return to WinBoard development and bugfixing

Who is online

Users browsing this forum: No registered users and 9 guests