Segfault when issued "quit" during a search about laser-chess-engine

[jeffreyan11]

You can send a "stop" before a "quit" to fix this. I will also fix it soon, I've just put it off because I haven't seen a GUI have problems with it yet.

[noobpwnftw]

The hanging issue is not resolved by the recent commit.

[jeffreyan11]

Hm, so the problem is not what I thought. It happens when cutechess cancels the match while a search is running? Does cutechess send stop before quit? Do you have logs?

[AndyGrant]

So I ran a set with logging. No output from cutechess about stop/quit here.

In this case I ran with concurrency=1, after the server tells cutechess to quit, half or all copies of master are left running. AND they are running at 100% CPU.

Running your engine normally, so long as not searching, CPU usage is hardly enough to even make its way to the top view. This means after cutechess exits, you have a searching thread still running, despite the main input reader being dead.

I have done ps -T -p <pid> on the "dead" copies of Laser. I can clearly see only one thread running. When running your engine normally, sending go infinite, I can then of course see the 2 threads using ps -T -p <pid>

I'm not familiar with c++ threading, but you need to have your threads connected back to the main one in some way.

[AndyGrant]

Assuming that cutechess is ACTUALLY sending a quit command to Laser (and not reporting it), all you might need to do is ensure that the search thread is joined before termination.

[AndyGrant]

See https://stackoverflow.com/questions/3756882/detached-vs-joinable-posix-threads and https://stackoverflow.com/questions/25655706/how-to-terminate-or-stop-a-detached-thread-in-c

[AndyGrant]

Have you looked any further into this? I tried a few things which in some cases suggested progress, other cases nothing.

[laldon]

bump @jeffreyan11 @AndyGrant