Page 1 of 3
Debugging crashes in the wild
Posted: Tue Jun 28, 2016 9:25 am
by 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?
Re: Debugging crashes in the wild
Posted: Tue Jun 28, 2016 10:26 am
by 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.
Re: Debugging crashes in the wild
Posted: Tue Jun 28, 2016 11:06 am
by Dann Corbit
Load the core dump. If you have compiled with symbols, it will take you right to the offending line.
Re: Debugging crashes in the wild
Posted: Tue Jun 28, 2016 11:09 am
by 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#.
Re: Debugging crashes in the wild
Posted: Tue Jun 28, 2016 11:25 am
by 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 : move e2e4
30719*1*Movimiento encontrado:e2-e4
30797*2*Child Process Prio Adj: PID 21152 conhost.exe
30797*2*Start calc, move no: 1
30860 >second : level 0 1 0
30860 >second : memory 160
30860 >second : new
30860 >second : level 0 1 0
30860 >second : time 6000
30860 >second : otim 5993
30860 >second : usermove e2e4
30953 <second : # Allocated 128 megabyte hash table of 8388608 elements.
31000 <second : # never exceed: 12240 no iteration: 749
31000 <second : Error (invalid command): otim 5993
31016 <second : # never exceed: 12240 no iteration: 749
31032 <second : 1 1 0 46 2 0 0 c7c5
31032 <second : 2 -73 1 408 3 0 0 c7c5 g1f3
31032 <second : 3 -2 1 1401 5 0 0 d7d6 g1f3 g8f6
31047 <second : 4 -39 1 5116 9 0 0 g8f6 b1c3 c7c5 g1f3
31063 <second : 5 -10 4 24585 11 0 0 d7d6 d2d4 g8f6 e4e5 d6e5
31172 <second : 6 -31 17 96383 15 0 0 d7d5 e4d5 d8d5 g1e2 g8f6 c2c4
31328 <second : 7 -33 34 183785 15 0 0 d7d5 e4e5 c8e6 g1f3 b8c6 d2d4 g7g5
33032 <second : 8 -35 203 1135894 18 567947 0 c7c5 b2b3 b8c6 g1f3 e7e6 b1c3 g8f6 h2h3
33032 <second : move e12c1
33032*moveerror* Rstart piece<0 and target piece<0, can't capture own piece !...!
33032*2*---------> Arena:¡Jugada Ilegal!: "e12c1" ()
33032****Tour**Partida finalizada: 1-0 {1-0 Adjudicación hecha por Arena. ¡Jugada Ilegal!}
Re: Debugging crashes in the wild
Posted: Tue Jun 28, 2016 11:45 am
by ZirconiumX
Edsel Apostol wrote: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.
Dann Corbit wrote: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.
Re: Debugging crashes in the wild
Posted: Tue Jun 28, 2016 11:54 am
by Henk
ZirconiumX wrote: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 ?
Re: Debugging crashes in the wild
Posted: Tue Jun 28, 2016 12:32 pm
by Dann Corbit
I love it. I believe it's "Village Idiot" in English.
Re: Debugging crashes in the wild
Posted: Tue Jun 28, 2016 1:25 pm
by Evert
Dann Corbit wrote: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.
Re: Debugging crashes in the wild
Posted: Tue Jun 28, 2016 1:36 pm
by ZirconiumX
Evert wrote:Dann Corbit wrote: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.