Eschecs FreeBASIC (UCI chess GUI)

[fxm]

Indeed sGUI uses screen locking. But it seems that the problem doesn't come from that: I tried to remove all screenlock-screenunlock from the project (including sGUI), and the problem is still here.

Do not conclude too quickly, there may be several issues that could lead to the crash.
Try to continue debugging with the version without screen locking and with sleep x, 1.

[fxm]

Could the problem come from here?

Code: Select all

' sgui_systemevents.bas
function GetSysEvents(XButton as integer) as integer  
  ' ...
  KEY=inkey
  
  ScreenEventExists=1
  do
    if (ScreenEvent(@SEvent)) then

No problem here if you don't have an input conflict (keyboard or mouse) with another thread.

[Roland Chastain]

Do not conclude too quickly, there may be several issues that could lead to the crash.
Try to continue debugging with the version without screen locking and with sleep x, 1.

Thank you for the advice. I did like you suggested.

I still haven't found the cause of the problem. I made important modifications in the graphical functions. Now all operations are done in a buffer, which is drawn to the screen only when the main program ask for it. It doesn't solve the bug, but I think the code is better like this.

I tried many other things, without success. Sometimes I can play several games without problem! It's very weird.

For now I give up. Here is the current version of the source code: eschecs.zip

[Roland Chastain]

I see in the task manager that the program, even when it is supposed not to do anything, uses 18% of the processor. I wonder what it does...

[fxm]

I just took a very quick look at "chesss.bas" and found that a mutex destruction was missing in the main loop:
(341) threadwait(listener->handle) : mutexdestroy(listener->sync)
(342) delete listener

[fxm]

I see in the task manager that the program, even when it is supposed not to do anything, uses 18% of the processor. I wonder what it does...

On the other hand, there is no SLEEP in the main loop:
(356) end if
(357) sleep(x, 1) : loop until event->EXITEVENT

[Roland Chastain]

I just took a very quick look at "eschecs.bas" and found that a mutex destruction was missing in the main loop:
(341) threadwait(listener->handle) : mutexdestroy(listener->sync)

Thank you, correction done.

I see in the task manager that the program, even when it is supposed not to do anything, uses 18% of the processor. I wonder what it does...

On the other hand, there is no SLEEP in the main loop:
(357) sleep(x, 1) : loop until event->EXITEVENT

There is

Code: Select all

do
  event->xSleep(1)

at the beginning. (With parameter 1 the loop executes only if there is an event. With parameter 0 it executes continuously.)

I still tried to add a sleep at the end. The occupation of the processor is still the same...

[fxm]

Inside sub EventHandle.xSleep (eventmode as integer,XButton as integer=1), maybe try:
if eventmode>-1 then sleep 1, 1

[Roland Chastain]

Inside sub EventHandle.xSleep (eventmode as integer,XButton as integer=1), maybe try:
if eventmode>-1 then sleep 1, 1

Ah yes, I had forgotten that one. Correction done. But it doesn't solve the problem...

[Roland Chastain]

It seems that I found the origin of the problem. I tried to remove this line:

Code: Select all

' sgui_systemevents.bas
function GetSysEvents(XButton as integer) as integer  
  ' ...
  KEY=inkey ' <---

Since I did that, I can't make the application crash anymore.

Please test the new code: eschecs.zip

(Don't pay attention to the colors. I introduced a new chess pieces set, and it isn't finished.)

[Roland Chastain]

A new pieces set is available. Start the application with the following parameter: --squareWidth=48



The pictures come from the Warlord chess program by William H. Rogers.

[badidea]

I still have fbsound issues. I compared with freebasic-miner (using fbsound). There the 32-bit version work fine. miner64 also crashes here with "error: lib fbsound-64 not loaded ! Segmentation fault (core dumped)". The 32-bit fbsound files form eschecs and freebasic-miner are different sizes, so probably different versions.
I'll compare with my 'own' versions of fbsound. That worked, all my .so files are different. I think it has to do with a different glibc version. I forgot the details. The fbsound .so files I have, were probably compiled on my machine.

BTW: Where is the 'undo move' button :-)

So far no freezes here. I played (and lost) a few games 32 and 64 bit (with debug).

I looked into the fbsound libraries a bit more. libfbsound-32.so form eschess is 744492 bytes, the version that works for me 661068 bytes.

'my'-version, ldd libfbsound-32.so:

Code: Select all

	linux-gate.so.1 (0xf7fae000)
	libgtk3-nocsd.so.0 => /usr/lib/i386-linux-gnu/libgtk3-nocsd.so.0 (0xf7e95000)
	libncurses.so.5 => /lib/i386-linux-gnu/libncurses.so.5 (0xf7e6f000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7d6d000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7d68000)
	libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7d49000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7b6d000)
	libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xf7b4a000)
	/lib/ld-linux.so.2 (0xf7fb0000)

'eschess'-version, ldd libfbsound-32.so:

Code: Select all

./libfbsound-32.so: /lib/i386-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./libfbsound-32.so)
./libfbsound-32.so: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by ./libfbsound-32.so)
	linux-gate.so.1 (0xf7ede000)
	libgtk3-nocsd.so.0 => /usr/lib/i386-linux-gnu/libgtk3-nocsd.so.0 (0xf7dc1000)
	libtinfo.so.6 => not found
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7cbf000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7cba000)
	libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7c9b000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7abf000)
	/lib/ld-linux.so.2 (0xf7ee0000)

I don't know what above means exactly, but it looks interesting :-)

[Roland Chastain]

I still have fbsound issues.

Thank you for the feedback. I replaced FBSound binaries (in eschecs.zip and also on freebasic-miner repository), with a copy taken in Joshy's package.

So far no freezes here. I played (and lost) a few games 32 and 64 bit (with debug).

Good new. So, I have to find now how to restore the line that I removed (and also the screenlocking eveywhere in sGUI).

@fxm
If you have time, could you please take a look? What is your opinion?
viewtopic.php?p=276613#p276613

BTW: Where is the 'undo move' button :-)

OK, I will do it, as soon as the currents problems are solved. :)

[fxm]

It seems that I found the origin of the problem. I tried to remove this line:

Code: Select all

' sgui_systemevents.bas
function GetSysEvents(XButton as integer) as integer  
  ' ...
  KEY=inkey ' <---

Since I did that, I can't make the application crash anymore.

I'm not sure what can conflict with this 'Inkey'.
I did not find other 'Inkey' in the code (neither 'Screenlock'), but on the other hand I found at least one 'Sleep(x)' not fixed in 'Sleep(x, 1)'.
(I stopped at the first one found)

[Roland Chastain]

I did not find other 'Inkey' in the code (neither 'Screenlock'), but on the other hand I found at least one 'Sleep(x)' not fixed in 'Sleep(x, 1)'.
(I stopped at the first one found)

Thank you for your answer. Yes, I see there is a Sleep 10 in wconnect.bas. It's fixed now. But the file is only used in the Windows version. So it can't be the cause of the crash under Linux (I am using Linux). I see no other Sleep x in the project.