Now I'm wondering if there's ever been emulated software that crashed because it tried to calculate a data transfer rate, but the emulator transferred the data faster than the delta in the time measuring in the emulated machine, so it divided by zero.
The original Macintosh ROM does some floppy drive calibration routines on startup to measure jitter in the spin rate. A common source of errors when writing a Macintosh emulator is emulating a "perfect" floppy drive. If the spin rate jitter is zero, the ROM attempts to a divide by zero and crashes.
“The timing calibration code in the Network Driver Interface Specification (NDIS) driver causes a divide by zero if the CPU runs at 2.2 GHz or faster. This problem does not occur with CPUs that run at 2.1 GHz or slower.”
Well, certainly a lot of people running older software have had the joy of their disk size being larger than the software can handle. There's plenty of software that expects the disk size in bytes to fit into an signed or unsigned 32-bit int.
I also don't know about data transfer rates but if you want to emulate the really old stuff in DOSBox, you'll need to carefully examine pages like https://www.dosbox.com/wiki/Performance because there are plenty of games that do a divide-by-zero crash when they're trying to time the CPU for running at the desired speed.
Emulated or not, old Turbo Pascal programs would crash on any computer faster than about 200MHz. The initialization code for the CRT module would try to calibrate timing for the Delay function and the division would overflow if the processor was too fast. See https://retrocomputing.stackexchange.com/questions/12111/
Not emulated as such, but I seem to remember certain old computers having problems with compact flash adapters replacing the hard drive because they were too fast.
