Crashes to crashes

[Henk]

Skipper crashed two times in last three days. Unfortunately it is difficult to reproduce for I already played a few tournaments and no crash happened.

Any (quick) methods to fix this ?

[I decided to test perft first. For instance compute Kiwipete(5). But no crash of course.]

[Henk]

Ok, I already have found some statements that should go wrong. So probably might be solved but it wil take another week to find out if bug is gone.

[abulmo]

Any (quick) methods to fix this ?

Use a debugger.

[hgm]

Skipper crashed two times in last three days. Unfortunately it is difficult to reproduce for I already played a few tournaments and no crash happened.

Any (quick) methods to fix this ?

[I decided to test perft first. For instance compute Kiwipete(5). But no crash of course.]

Clear the hash table before every move. Then the search should be completely reproducible. So you just wait for a crash, and then debug on the position where the crash happened.

[Michael Sherwin]

Any (quick) methods to fix this ?

Use a debugger.

I have MSVS 2005 and in debug mode RomiChess crashes. In fully optimised release mode it runs just fine! lol

[Daniel Anulliero]

Skipper crashed two times in last three days. Unfortunately it is difficult to reproduce for I already played a few tournaments and no crash happened.

Any (quick) methods to fix this ?

[I decided to test perft first. For instance compute Kiwipete(5). But no crash of course.]

Crashes to crashes ...
Mmm sure is a tribute to David Bowie ..😢

[abulmo]

I have MSVS 2005 and in debug mode RomiChess crashes.

Then you can fix the problem...

In fully optimised release mode it runs just fine! lol

More likely, it runs just accidentally.

It is more problematic when it is the other way around, the program runs fine in debug mode, but crashes in release mode.

Personally, I develop mostly under Linux, only rarely using a debug mode, but just keeping some debugging information into the fully optimized version of my software. I set my environment up so that it produces a core file when a crash happens. So when, a rare crash occurs, I feed up the debugger with the core file, and can get an idea of the cause of the crash.

[flok]

Skipper crashed two times in last three days. Unfortunately it is difficult to reproduce for I already played a few tournaments and no crash happened.

Any (quick) methods to fix this ?

[I decided to test perft first. For instance compute Kiwipete(5). But no crash of course.]

Simple: look in the log of svn/git at what revision things worked fine and then do a bisect (yes you can also bisect with svn) until you'll find the bug.
Or just look at the diffs, then it is most of the time rather obvious which change introduced the bug.

[Dann Corbit]

On windows (assuming the Microsoft compiler), you can create a crash dump easily enough.

Then, you load the crash dump in your debugger and it will take you right to the offending line.

_set_abort_behavior() is useful if you recognize the problem yourself via abort {e.g. malloc() failure}.

For everything else, install a structured exception handler.
Then install a minidump handler like this:
https://msdn.microsoft.com/en-us/library/ms680360.aspx

If you catch it in the crash, then you can also make them this way:
https://support.microsoft.com/en-us/kb/931673

[bob]

Skipper crashed two times in last three days. Unfortunately it is difficult to reproduce for I already played a few tournaments and no crash happened.

Any (quick) methods to fix this ?

[I decided to test perft first. For instance compute Kiwipete(5). But no crash of course.]

Clear the hash table before every move. Then the search should be completely reproducible. So you just wait for a crash, and then debug on the position where the crash happened.

That's not always good enough. History counters. Killer moves. Counter moves. etc all have an effect on move ordering, and hence GHI type problems.. Not to mention different moves will get reduced differently depending on where they appear in the move list.