I'm working on a biology simulator in Rust, on Windows. It works fine for a few minutes and then grinds to a halt, though it continues to use CPU. What sort of tools are available to me to figure out what's going on? I'm currently using IntelliJ IDEA with the Rust plugin.
I usually just press pause in the debugger to check what's going on. Unfortunately, lldb on Windows can't read the thread names, so it's a bit challenging to find the blocked thread out of 20+.
Hmm... "biology simulator... grinds to a halt"
You wouldn't happen to simulating some kind of reproduction of critters with an exponential growth rate that eventually consumes all your memory, threads, CPU performance, whatever?
Have you done a quick check of CPU / RAM usage with the task manager?
During a year of using Rust during which I have created some reasonably complex things I have never felt the need for a debugger. Unlike C/C++, programs in Rust do not randomly crash for hard to find memory error reasons or produce random results on occasion.
That leaves logic errors to cause problems, which I generally figure out with a few
println. Some carefully placed
println announcing when significant things happen, when threads start and end, and so on works wonders.
Recently I found using the "log" crate very helpful. Then instead of
println I use
debug! to issue messages. Then I can select the severity of message I want to see when I run the program and even select which modules will output messages.
Of course it helps to have tested functions/methods using Rust's great test facilities before trying to run and test the entire program.
Rust is compatible with C debuggers and profilers, so you can reduce the problem to finding what's taking time in a C program.
I'm unfamiliar with Windows tools. On macOS Xcode Instruments or Activity Monitor's spindump can help.
Thanks, everybody. IntelliJ Rust doesn't have a debugger, but I just learned that VS Code can debug Rust. I've only just started investigating with that, but it looks like something weird is happening. It's spending a lot of time in a simple sort function. I'm sorting a vector of about 5,000 items, which I pass into my sort function as a mutable slice. Inside the sort function, however, the slice shows as having trillions of items. This fits with what Task Manager shows, which is that during each simulation tick, memory consumption goes way up and then falls when the tick ends. Note that this happens only after thousands of ticks, and the population of simulated organisms (what's being sorted) has stabilized, though with constant births and deaths (they reuse slots in the vector, so it's not growing). The sort does no memory allocation, and I have written no unsafe code anywhere. I'll dig in further and report back.
Sounds a bit like an integer overflow?
Maybe you could try running a debug build and see if there is a overflow somewhere?
How are you doing that sort?
Are you using Rust's
From what you say there it sounds like you have rolled your own sort. Perhaps try Rust's sort and see what happens.
Run a debug build to see if it catches any integer overflows.
Are you certain that the slots in the vector are actually being reused? If you were mistakenly adding elements instead of reusing the allocated space, that would explain why the vector would grow to be massive after thousands of ticks and cause sorting to hang.
You can defensively check things whether they make sense. For example, if you expect sorted vector to be small, add:
debug_assert!(vec.len() < 1000); vec.sort();
Thanks again for the replies. I've figured it out. It turns out that my digital organisms had evolved a way to take advantage of a loophole I had left in the physics. This allowed them to proliferate in much larger numbers than I had realized. What I thought were single organisms were actually stacks of hundreds (it's a 2-D world). When I closed the loophole, things went back to normal.
As for the apparent trillions of items in the sorted slice, that must be an error in how the VSCode debugger displays the fields of slices. I added assertions, and there were no such vast numbers of items.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.