Debugging crashes in the wild

[ZirconiumX]

So my chess program Dorpsgek crashes fairly often in games. To be expected, really - it's pretty new.

The problem is, despite my best efforts, I can't reproduce any of the crashes. They're all heisenbugs that disappear under GDB.

So what do people normally use as a method to debug problems that occur in games, but cannot be reproduced?

[Edsel Apostol]

Put a lot of asserts like Fruit that prints the filename and line. Output that into a file and let your engine play the games to discover the bugs. Make sure that all parameters are the expected value. Make sure also that all index to the array are within the range of that array and make sure that there is no possibility to divide by zero.

[Dann Corbit]

Load the core dump. If you have compiled with symbols, it will take you right to the offending line.

[Henk]

Use a binary search.

Go back to a very simple state where you don't have bugs. Then add each time some code and test it.

I think programming in C# is safer than C++. Translating to C# might not be much work if you have some knowledge of C#.

[velmarin]

Compilation in Visual Studio with Intel and Clang is possible, despite a few easy to fix warnings.

In sand in debugging my build not gives good result, you can see that output for example.
One possibility for this problem is to put an autoplay command how I've seen in some TSCP.

Code: Select all

30719 <first &#58; move e2e4
30719*1*Movimiento encontrado&#58;e2-e4
30797*2*Child Process Prio Adj&#58;  PID 21152 conhost.exe
30797*2*Start calc, move no&#58; 1
30860 >second &#58; level 0 1 0
30860 >second &#58; memory 160
30860 >second &#58; new
30860 >second &#58; level 0 1 0
30860 >second &#58; time 6000
30860 >second &#58; otim 5993
30860 >second &#58; usermove e2e4
30953 <second &#58; # Allocated 128 megabyte hash table of 8388608 elements.
31000 <second &#58; # never exceed&#58; 12240 no iteration&#58; 749
31000 <second &#58; Error &#40;invalid command&#41;&#58; otim 5993
31016 <second &#58; # never exceed&#58; 12240 no iteration&#58; 749
31032 <second &#58; 1 1 0 46 2 0 0	 c7c5
31032 <second &#58; 2 -73 1 408 3 0 0	 c7c5 g1f3
31032 <second &#58; 3 -2 1 1401 5 0 0	 d7d6 g1f3 g8f6
31047 <second &#58; 4 -39 1 5116 9 0 0	 g8f6 b1c3 c7c5 g1f3
31063 <second &#58; 5 -10 4 24585 11 0 0	 d7d6 d2d4 g8f6 e4e5 d6e5
31172 <second &#58; 6 -31 17 96383 15 0 0	 d7d5 e4d5 d8d5 g1e2 g8f6 c2c4
31328 <second &#58; 7 -33 34 183785 15 0 0	 d7d5 e4e5 c8e6 g1f3 b8c6 d2d4 g7g5
33032 <second &#58; 8 -35 203 1135894 18 567947 0	 c7c5 b2b3 b8c6 g1f3 e7e6 b1c3 g8f6 h2h3
33032 <second &#58; move e12c1
33032*moveerror* Rstart piece<0 and target piece<0, can't capture own piece !...!
33032*2*---------> Arena&#58;¡Jugada Ilegal!&#58; "e12c1" ()
33032****Tour**Partida finalizada&#58; 1-0 &#123;1-0 Adjudicación hecha por Arena. ¡Jugada Ilegal!&#125;

[ZirconiumX]

Put a lot of asserts like Fruit that prints the filename and line. Output that into a file and let your engine play the games to discover the bugs. Make sure that all parameters are the expected value. Make sure also that all index to the array are within the range of that array and make sure that there is no possibility to divide by zero.

Good idea. Even if it takes a while, it will hopefully be worth it.

Load the core dump. If you have compiled with symbols, it will take you right to the offending line.

Haven't figured out how to do that with MinGW yet. Though I do have an Ubuntu VM that may get put to use.

[Henk]

So my chess program Dorpsgek crashes fairly often in games. To be expected, really - it's pretty new.

The problem is, despite my best efforts, I can't reproduce any of the crashes. They're all heisenbugs that disappear under GDB.

So what do people normally use as a method to debug problems that occur in games, but cannot be reproduced?

By the way. How did you invent the name Dorpsgek ?

[Dann Corbit]

I love it. I believe it's "Village Idiot" in English.

[Evert]

I love it. I believe it's "Village Idiot" in English.

That I would find rather surprising.
In fact I'd be surprised if an English speaker can pronounce the word... maybe if they're Scottish.

[ZirconiumX]

I love it. I believe it's "Village Idiot" in English.

That I would find rather surprising.
In fact I'd be surprised if an English speaker can pronounce the word... maybe if they're Scottish.

The Dutch G makes an English H sound. So it's pronounced Dorps-heck. It's hard to wrap the tongue around though.

As for the origin, I have friends in Flanders, which is Dutch speaking.