Linux port of newer versions of TogaII

[krazyken]

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]

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.

[Zach Wegner]

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]

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]

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]

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]

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

[Michel]

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]

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

[Michel]

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