To start: I'm not sure what you mean by OS driver/control software. The two main (non-proprietary) flight controller platforms are PX4 and ArduPilot, which both basically act OS-like. Depending on which platform you're building for, they can use things like ChibiOS under the hood as well.

It's not memory overflows. These can fly for long periods of time, but sitting on the ground for a couple of minutes can be enough to require a reboot. What it is, best I can tell from the limited debugging I've done so far, is accumulated sensor bias. When the aircraft is in the air, you've got some sensors providing short-term data (accelerometers, gyros, magnetometers) and some sensors providing long-term data (GPS, optical stabilization if fitted); the short-term sensors are noisy, and an Extended Kalman Filter does sensor fusion to provide estimates that are the combined values from the fast sensors and the slow sensors. When a GPS update comes in, the EKF corrects for the biases in the sensors.

When you're sitting on the ground in a stationary position, you're only measuring noise. The accelerometers are saying you're accelerating a little bit this way and a little bit that way; the gyros are saying you've spun a bit; the GPS says you've moved around some. The GPS signal is nominally mean-zero motion, but the rest of the sensors give both bias and noise. The EKF tries to filter out the noise and correct for the bias, but because the GPS is also wobbling around, it seems that it doesn't do the bias estimation correctly. For example, this sample, the accelerometers say that you've accelerated south, but the GPS sample has moved 0.5m north. Also, GPS doesn't help correct everything unless the aircraft is in motion; if there's magnetometer drift and gyro bias in the same, the aircraft has no way of knowing that it hasn't rotated (when you're airborne, you can use the GPS signal to know which direction you're moving, even if the magnetometer says you're pointed off by a few degrees).