Crush after adding patterns.spat.xz

[emdio]

I ran "michi gtp" and said $ ./michi gtp Warning: michi cannot load pattern files, It will be much weaker. Consider lowering EXPAND_VISITS 8->2

I downloaded and uncompressed patterns.spat.xz from http://pachi.or.cz/michi-pat/ to the dir in which michi is compiled and now I get the error $ ./michi gtp Segmentation fault

[db3108]

Hi Emilio.

Thank you for your feedback. But your report of a potential bug in michi-c2 is "a little bit scarse". Could you please provide me some more information, so I can maybe understand what happened ? (see my questions at the end of this post)

For now, this is what I've been able to do from the information you gave me. I assume that you put the large pattern files in the directory you run michi (i.e. the directory where you compiled it) as this is stated in the INSTALL.md file from michi-c2.

In the last hour, I just did exactly what you did with the current version of michi (commit 7608a12eab2b3548486a731fdb00477cc6f5a5a1) and after download of the last versions of michi large patterns from http://pachi.or.cz/michi-pat/ (they didn't change since I downloaded them before).

Everything works fine on my computer (Linux Ubuntu 12.04): ./michi gtp version = 1.4

name = michi-c

quit

My questions:

• have you rebuild completely the code after downloading the last version ? (make veryclean; make)
• what is your system (windows, mac, linux) ? and version ?
• what C compiler version ?
• If the problem persists, could you please post the michi.log you have got from the run (this will provide me information about length of integers on your system and so on)?
• potentially, if it is possible for you to recompile the code with debugging information, run it under a debugger and tell me in what function the seg fault occurs ?

I hope we will be able to solve this issue with your help.

Best, Denis

[emdio]

So sorry; I just didn't realize that both pattern files had to be downloaded ^^''

[db3108]

Hi Emilio,

Thank's. It's good to see that this is not a real problem. Testing by real users is the only way to get every bugs out of the code (and I am quite sure that there are still some of them "sleeping" in the code ... I would like to find them all and correct them) Your experiment shows me that I did (incorrectly) assume in the code that the xxx.prob and xxx.spat are all present and consistent. I should improve the code on that point in order to make it more robust.