Possible Bug when clicking Engine #1 Settings

[John Cheetham]

I have noticed that xboard sometimes crashes (segfault) when I select Engine #1 settings. It does this for example on the crafty, jazz and neg03d engines.
I am using xboard 4.5.2a with Fedora 14 64 bit.
I tried with xboard 4.5.1 and this didn't crash but displayed no settings.
I think maybe there are no settings that can be changed on these engines and xboard 4.5.2 doesn't cope with that.

[H.G.Muller]

Yes, you are right, this is exactly the reason. I ran into this bug ust before we released 4.5.2a in the development branch, and fixed it there. But when I tried it out in the v4.5.x branch, it already seemed to work, (I got a nice popup with ust the OK and cancel button with Crafty), so I dit not apply the patch there. I thought it had to do with displaying the OK and cancelbutton on the same line as theprevious control elements, which involved an out-of-bounds array access if there were no previous elements. Later I discovered that the 'fix' did not work in the development branch either, and that it could still crash with Crafty. But not always. When I tried to debug it by putting in print statements to locate the point of the crash, it turned out the print statements could make the crash disappear.

I now solved the problem in the development branch by popping up a message box in stead of the settings dialog, when the engine has no options.

I think we are plagued by a bug in the Athena widget-set library here, for auto-sizing buttons. I just discovered the size of buttons is quite unpredictable (if you don't specify it yourself, which is difficult in case of the engine-settings dialog, where there could be any text on it). In the Tags and Comment popups they were sometimes ridiculously wide, more than doubling the total width of the dialogs.Also in the settings dialog of glaurung, below, you can see there is something badly wrong with the sizing of the Clear Hash button. It is like the library at some point uses an uninitialized variable when determining button size, and that whatever happens to be on the stack left rom previous actions is then used. This would explain how a preceding printf could make the crash go away.

[John Cheetham]

Also in the settings dialog of glaurung, below, you can see there is something badly wrong with the sizing of the Clear Hash button.

I have fiddled with this on xbxoard 4.5.2a and think I have a fix.

I changed line 1493 in xoptions.c from:
if(option[i].max) XtSetArg(args[j], XtNwidth, option[i].max); j++;

to:
if(option[i].max) {XtSetArg(args[j], XtNwidth, option[i].max); j++;}

i.e. I have added some braces around the if. I think the problem was the j index to the arglist was being incremented when the XtSetArg wasn't performed.
Anyway I tried this with Glaurung 2.0.1 and the button went from squashed to normal size.

[H.G.Muller]

Oh, thanks very much! This must indeed be it; by incrementing j even when option[i].max is zero (which is the normal situation, for auto-sized buttons), it will incorporate an argument from the previous control element rendered in the dialog. This could be a an height or width spec,depending on the type of element and the layout of its Args. I completely overlooked that there still is a j++ as a separate statement, so that we need braces.

I guess this cannot have anything to do then with the crash of Crafty Engine Settings, as this code is only used when there are button options, and OK and cancel are made by different code.

This 4.5.2 really is a disaster version. I put some new stuff in it compared to 4.5.1, and one just can't do that in a stable version. But the need for the menu dialogs was so great I decided it was worth the risk. Gambled and lost, as they say. Another thing we broke, (which I just discovered) is the engine-output window: because the new dialogs code puts the cursor at the end of the text in a text-edit when the edit is clicked, clicking the engine-output window now causes a v-scroll to the bottom before the click is interpreted. So as soon as the engine output no longer fits vertically in its pane, it becomes impossible to view or select lines near the top (where all the interesting stuff is...). And in multi-pv analysis mode,it is virtually impossible to make the window large enough to contain the entire search.

[John Cheetham]

I guess this cannot have anything to do then with the crash of Crafty Engine Settings, as this code is only used when there are button options, and OK and cancel are made by different code.

I tried looking at the crafty crash with the DDD debugger and that reckons it is failing on line 1604 XtRealizeWidget(popup). The problem probably lies with some of the commands before that. In 4.5.1 it checks first if there are any options present (!cps->nrOptions) and if not it returns so it doesn't get the same problem.

[H.G.Muller]

I guess I stopped making that check when I converted the routine to not only handle engine options, but XBoard options from predefined lists. For those there isn't an equivalent of cps->nrOptions, bt the end of the list is marked by a sentinel of option type 'EndMark'. This to make it easier to add options without worrying about correctly counting them. But in the final fix that is now in the GNU master branch, I put it back, in the form "if(cps && cps->nrOptions == 0)". And then I don't just return, but do a DisplayNote to inform the user the engine has no options.