Re: [Bug-XBoard] xboard crashes with engine

[h.g. muller]

> After getting the resources solved enough to start xboard w/out the engine 
> output window, I can confirm this window is the problem.
>
> Starting w/out the window works fine until I bring it up.
>
> Again, I tried your other suggestion about changes to xengineoutput.c 
> w/out effect.

Just to make sure we are compiling the same version, I downloaded the 
tar-ball for the
current master branch on Savannah, and compiled it. On my Ubuntu 8.04, this 
produces
a binarythat works without problems when I launch it with "./xboard -fcp 
fruit -fUCI", and
the EngineOutput window is open at startup (as described in the settings file).

So I think it must be due to a difference between the X-tools llibrary we 
link with.
The suspect part of the code has the following calling scheme:

The backend calls SetProgramStats, in engineoutput.c
Now I already see some suspicious code there: at the beginning there is the 
if(stats = 0),
which makes it call SetEngineState, which uses handles / widgets that are 
not defined
if the EngineOutput window is not open. But I don't think SetProgramStats 
can ever be
called with stats==0, so the whole code seems redundant. (I found only one 
call in
backend.c, where stats is the address of a locally-declared struct variable.)

The remainder of the SetProgramStats routine is only executed when the 
EngineOutput
window has been realized, and must thus be responsible for the crash. It calls
DoClearMemo() and UpdateControls() to mess with the window. The first ste 
would be
to figure out if the (simple) DoClearMemo is responsible, by commenting out the
if(clearMemo) statement. If the crash stays, it must be caused deeper down, in

UpdateControls() in engineoutput.c
I understand tht you experienced crashes in the cases that are handled by
if(gameMode = AnalyeMode || ...
This does a SetEngineState(), which accesses a widget to display an icon.
So this should be commented out first. Then, in all cases it does a
SoSetWindowText(), to alter the text in the widget that displays the NPS.
That call can be commented out too. Then the actual PV line is printed by
caling InsertIntoMemo(), while finally SetEngineColorIcon will alter the icon
displayed in a widget. After these calls have been commented out too,
the whole thing has pretty much become a no-op, as far s calling X is 
concerned,
and the crash should certainly have disappeared.

We can then one by one try to activate them again. Most of the calls to display
something are independent, and overall operation is not jeopardized by 
having them
on or off. The only calls that cooperate are DoClearMemo and InsertIntoMemo:
if you would insert into the text widgets without ever clearing, in the 
long run,
there might be overflow problems. But as the crash seems to happen on the
very first attempt to print a PV line, even that should not matter much.
But the proper procedure would probably to first enable DoClearMemo, and
when that seems to work without problems, enable InsertIntoMemo.

In theory this should reveal the location of the crash.