RNG崩溃的C ++程序

Question

I am currently coding a roguelike, and naturally am using a lot of random number generation.

The problem I'm running up on is that if I "overheat" rand(); my program will crash.

If i'm only generating 20 or so ints per frame, it's fine... but when the amount of random numbers goes into the hundreds, the program crashes. The more I'm producing every frame, the sooner it crashes... which leads me to believe there is some pileup going on.

I've done tests, and at 20 rand(); calls per frame, it will run for 24 hours straight at max speed without crashing. Triple that and it doesn't make it ten minutes.

If I put srand(); in the initialization, i can churn out thousands of random numbers before it locks up - but if I put srand(); within the frame itself, i make it about 2-8 frames. If it matters, I'm using time(null) to seed.

the more frequently i call rand(); the sooner it crashes.

Help?

Answer 1

The function rand() is not reentrant or thread-safe, since it uses hidden state that is modified on each call. This might just be the seed value to be used by the next call, or it might be something more elaborate. In order to get reproducible behavior in a threaded application, this state must be made explicit. The function rand_r() is supplied with a pointer to an unsigned int, to be used as state. This is a very small amount of state, so this function will be a weak pseudo-random generator. Try drand48_r(3) instead.

Answer 2

Try running it under a debugger

$ gdb myprog
(gdb) break main
(gdb) run
(gdb) record

eg

(gdb) break abort
(gdb) break exit

since it is c++:

(gdb) catch throw
(gdb) catch exception

and finally (gdb) continue

When it stops, reverse-continue until you find the culprit

---

Option 2:

valgrind --tool=massif --massif-out-file="massif.out.%p" myprog
ms_print massif.out.*

to examine heap profiling. Not unlikely you have a memory leak

Answer 3

It's possible the high number of calls to rand are coming up with a number in a relatively small range which your code cannot handle. Try replacing your calls to rand with a function that just increments a number and returns it, and see if it eventually fails.

Answer 4

1. You probable shouldn't be using rand(). There are far better PRNGs out there. Have a look at Boost.Random.
2. You should only srand() once, not every frame.
3. Find out where your code crashes. Using a debugger that's fairly easy, just start the program with the debugger attached and wait until it crashes.
4. After you have found out where it crashes, find out why it crashes.
5. After you have found out why, fix it. It probably doesn't have anything to do with rand().

Answer 5

A few comments and ideas on how to narrow down the source of the issue:

• It almost certainly is not the srand() or rand() functions causing the crash/lock up. Chances are that one, or more, combinations of random numbers is getting your engine into a state where something bad happens.
• The first step should be to duplicate the issue such that it always happens at the time/place. Instead of using a srand(NULL) try using a constant seed like srand(12345) . Depending on what other factors your engine uses (like user input) this may be enough to get it to crash in the same spot each time.
• If using the debugger is having issues (which is suspect, perhaps a buffer overflow is corrupting the stack) use the tried and true method of outputting messages to a text log file. I would suggest outputting all the random numbers generated and perhaps you may see a pattern on when it crashes (ie, it crashes whenever a "42" is generated). Another option is to start adding a few log message in various functions (start with high level functions like your game update loop). After a crash check the log and begin adding more log messages until you narrow it down to one line/function. This is not as quick as using the debugger can be but is sometimes a better choice, especially if you don't really know where to start looking.
• Once you are able to reliably replicate the crash start removing things until the crash point changes or disappears. This may involve #ifdef s, commenting out code, setting application options, or even creating a temporary copy of the project so you can simply delete code, compile, and test. This may be difficult if the project is large/complex.
• More information on the type of "crash" would be helpful. Usually programs don't just crash generically but have a certain exception occur, lock-up, etc.... Exception details can help you narrow down the source of the issue with some effort.