Linux port of newer versions of TogaII

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
krazyken

Re: Linux port of newer versions of TogaII

Post by krazyken » Mon Oct 20, 2008 11:05 pm

It didn't crash because it did not reuse info.
position startpos moves g1f3
...
bestmove d7d5 ponder d2d4
position startpos g1f3 g8f6 d2d4
If you start with a new position for every search it seems to work. The simplest case is to give the same move back. (and you missed the moves argument)
ucinewgame
go depth 1
best move xxxx ponder yyyy
position startpos moves xxxx
go depth 1
you should be able to pick any depth you want.

bob
Posts: 20923
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Linux port of newer versions of TogaII

Post by bob » Tue Oct 21, 2008 12:04 am

Zach Wegner wrote:
Michel wrote:It seems gdb is thoroughly confused. Presumably the segfault does not occur at the actual
memory access error
(this very often happens in my experience).
Really? I can't say I have ever seen it. This is just from BSD experience though, not Linux, and usually when I debug I have optimizations off.

To me it doesn't look like that is happening, but rather the board is corrupted and it's causing segfaults all over the place. Since it happens on the second move, and only on child threads, I'd imagine it is related to copying the board state to the children before starting the search. You can see in the last back trace a bunch of gibberish being passed around (from=102920, to=153, colour=-2, etc)
This has got to be a terminology issue rather than a programming one. "a segfault" happens when you generate a virtual address that is invalid. That crashes your program instantly. It sounds like perhaps he is talking about a bogus memory address being generated/used, but the address is still in the virtual address space of the process. This will corrupt something and cause an error at some point, but makes it difficult to identify the initial culprit.

Just a guess however, as otherwise an invalid memory address that produces a segfault is instantaneous death to any process under linux.

User avatar
Zach Wegner
Posts: 1922
Joined: Wed Mar 08, 2006 11:51 pm
Location: Earth
Contact:

Re: Linux port of newer versions of TogaII

Post by Zach Wegner » Tue Oct 21, 2008 1:02 am

bob wrote:This has got to be a terminology issue rather than a programming one. "a segfault" happens when you generate a virtual address that is invalid. That crashes your program instantly. It sounds like perhaps he is talking about a bogus memory address being generated/used, but the address is still in the virtual address space of the process. This will corrupt something and cause an error at some point, but makes it difficult to identify the initial culprit.

Just a guess however, as otherwise an invalid memory address that produces a segfault is instantaneous death to any process under linux.
OK, reading what he said again, I suppose that's plausible. I read it as the program makes an invalid memory access, but continues executing and only gets SIGSEGV later. AFAIK the signal gets delivered precisely whenever the invalid access is made on all POSIX systems. So I think what he was saying was that "bad" memory accesses that are still legal are occurring before the actual segfault.

But anyways, I downloaded the sources and compiled them. Only change I had to make was to take out -ldl from the Makefile. I have no idea what that is, but it didn't seem to need it. No problems though. I tried some of the scenarios posted here and they all work OK, no crashes.

krazyken

Re: Linux port of newer versions of TogaII

Post by krazyken » Tue Oct 21, 2008 1:32 am

Interesting, so that does mean it is specific to Darwin. I did quickly try building it with the intel compiler, and it segfaults the same way.

Michel
Posts: 2210
Joined: Sun Sep 28, 2008 11:50 pm

Re: Linux port of newer versions of TogaII

Post by Michel » Tue Oct 21, 2008 7:03 am

Another thing, one thread is always running at 100% of one core...... (this already starts when isready is entered).
That is very interesting. Are you saying that one of the threads starts running (searching presumably) right after "isready" and before any "go" commands? This is not supposed to happen. Perhaps there is something wrong with semaphores on MACOSX?

What is the minimal sequence of commands necessary to reproduce this?

Michel

Michel
Posts: 2210
Joined: Sun Sep 28, 2008 11:50 pm

Re: Linux port of newer versions of TogaII

Post by Michel » Tue Oct 21, 2008 8:31 am

Another thing, one thread is always running at 100% of one core...... (this already starts when isready is entered).
This would be very important if confirmed. isready creates the threads.
On windows they are created suspended but this in not possible with the pthread api.

Therefore I create for every thread a semaphore with value zero. The threads wait for these semaphores to be posted. See

Code: Select all

void start_suspend_threads()
void * search_thread (void *param)
void resume_threads()
in search.cpp.

Maybe there is some difference in the behaviour of semaphores on MACOX versus Linux/BSD? In that case we might try condition variables.

Regards,
Michel

krazyken

Re: Linux port of newer versions of TogaII

Post by krazyken » Tue Oct 21, 2008 8:41 am

I can confirm that. on issuing isready, cpu usage goes up without entering any other command.

Michel
Posts: 2210
Joined: Sun Sep 28, 2008 11:50 pm

Re: Linux port of newer versions of TogaII

Post by Michel » Tue Oct 21, 2008 9:02 am

I can confirm that. on issuing isready, cpu usage goes up without entering any other command.
Ok then perhaps we have found the problem. The semaphore api

Code: Select all

sem_init
sem_wait
sem_post
might not be doing its job on MACOSX.

If that is the case an alternative to try would be to use the pthread_cond_*** family of calls.

Any Mac people here care to comment?

krazyken

Re: Linux port of newer versions of TogaII

Post by krazyken » Tue Oct 21, 2008 9:07 am

I don't fully understand thread programming, but perhaps what this guy is talking about may be relevent: counting semaphores

Michel
Posts: 2210
Joined: Sun Sep 28, 2008 11:50 pm

Re: Linux port of newer versions of TogaII

Post by Michel » Tue Oct 21, 2008 9:25 am

Yeah it seems OSX does not support unnamed semaphores. Here is another link

http://software.intel.com/en-us/forums/ ... opic/54260
MAC OS doesn't support unnamed semaphores. Even if the code compiles
correctly using sem_init and sem_destroy, these functions have no effect
under MAC OS X
Bummer....

I will reimplement the semaphores using pthread condition variables. That should work.

Regards,
Michel

Post Reply