Debugging crashes in the wild

[CRoberson]

I thought it was village drunk spelled backwards - Kegs Prod (somebody that can't resist a keg).

Crashes in the wild - I thought you were discussing crashes on other peoples machines that you can't reproduce. If you are not at that stage, be happy. If you are at that stage, be happy.

So, I deal with those things using log files. The log file mechanism that I encoded has multiple levels of verbosity. For tournaments, it is at a minimum.
For the early stage of testing which is with test positions, it is at max. For the next level (early games), it is at a medium level or higher depending on ...
Then for more serious strength testing, it is lower.

[ZirconiumX]

I think you can make them from the CODE::Blocks GUI, (IIRC) in order to get gcc to create them on windows.

Or you can get the free MS compiler and it will make them because I do it all the time.

I've got MSVC, so I decided to port the code over.

It's currently crashing in a debug function.

Looks like I have a long day ahead of me.

[ZirconiumX]

For reference, I should state that I use Bruce Moreland's "PV on the stack" approach to PV gathering.

Part of his code invokes memcpy to copy moves across. The core dumps state that this call is causing Bad Things to happen (possibly uninitialised variable).

Maybe I should try a different approach. TT extraction, perhaps?

[bob]

For reference, I should state that I use Bruce Moreland's "PV on the stack" approach to PV gathering.

Part of his code invokes memcpy to copy moves across. The core dumps state that this call is causing Bad Things to happen (possibly uninitialised variable).

Maybe I should try a different approach. TT extraction, perhaps?

Why not just fix this as extracting from TT is inaccurate anyway. I've used memcpy() to copy the PV back up the tree since forever. You just can't pass memcpy() bad addresses of course.

You should be able to add a couple of asserts to verify that the source and destination addresses are inside the array you intend to use, and that the # of bytes is reasonable.

[ZirconiumX]

For reference, I should state that I use Bruce Moreland's "PV on the stack" approach to PV gathering.

Part of his code invokes memcpy to copy moves across. The core dumps state that this call is causing Bad Things to happen (possibly uninitialised variable).

Maybe I should try a different approach. TT extraction, perhaps?

Why not just fix this as extracting from TT is inaccurate anyway. I've used memcpy() to copy the PV back up the tree since forever. You just can't pass memcpy() bad addresses of course.

You should be able to add a couple of asserts to verify that the source and destination addresses are inside the array you intend to use, and that the # of bytes is reasonable.

I'm currently running a soak test on a one-line fix that unconditionally sets pv->count to 0 at the start of the node (which is probably good practice anyway). It hasn't triggered that bug yet, which is a good sign.

Cutechess is reporting connection stalls though. More bugs to fix, oh well.

[hgm]

The Dutch G makes an English H sound.

Not at all. It is a deep guttural rasping sound, which Anglophones cannot make, and replace by an 'h' for lack of anything close to it. As they also do in Spanish words that have this sound(but where it is spelled with the letter 'j').

[Henk]

https://www.youtube.com/watch?v=YrI2-bZ7wpc

We just sound like pigs.

[ZirconiumX]

I'm going to dig this up even though it's not strictly a crash in the name of not spamming threads.

I seem to have a search bug which makes no sense. As an example, I added an implementation of SEE pruning captures at leaf nodes in my search, which should logically make the search faster at the very least, right?

No SEE pruning depth 10 result:

# Depth Score Time Nodes Seldepth NPS TBHits PV
10 29 634 4070876 23 678479 0 e2e4 d7d5 e4d5 d8d5 d2d4 g8f6 b2b4 c8f5 b1c3 d5c6

SEE pruning depth 10 result:

# Depth Score Time Nodes Seldepth NPS TBHits PV
10 33 901 5162504 22 573611 0 e2e4 c7c5 g1f3 b8c6 h2h3 e7e6 c2c4 f7f5 e4e5 g8e7

Yes, this bug makes the search search 25% more nodes with pruning. I've also encountered this bug when testing whether it's better to SEE prune checks in quiescence or not. Plus, my engine tests as being weaker when I use multi-cut or even null-move pruning, and searches more nodes with a larger than default transposition table.

I'm confused and annoyed.