DRD Team

As posted on Doomworld, I have an issue with sudden crashing, The error message states "Integer Overflow" and generally happens when there are Revenants around. It might not be Revenant exclusive, but I notice it happens frequently on Revenant heavy maps. Mephisto's Mausoleum from the Master Levels is particularly guilty of causing this crash, with the many Revenants. I can get the bug to happen 100% of the time in a TNT2 Devilution beta map, a horde of Revenants rises from a blood sea in the opening room, and once they start shooting projectiles en masse, a crash is inevitable.

I use Doom Expanded and this seems to be the cause, as I cant remember whether its done the same crash without Expanded.

This happened with 1.7 as well. Ive updated my graphics drivers as far as possible without causing system crashes.

Hm...

It crashes while trying to divide -25266 by 1.
Normally this should never, ever be possible to trigger an exception. I have absolutely no idea why it happens anyway.

It happens in a part of the movement code that's executed everytime any actor moves. So, whatever it is, it seems to be particular to your system. If this crashed constantly Doom would not be playable.

Actor movement..huh. Could that be the monsters, missiles and me? I use an Xbox 360 controller if that helps. The Revenants in Expanded shoot two missiles at once as well.

Well, all I can add is that I have failed to get the crash. I loaded Doom Expanded, warped to map18 of Doom2, put on freeze mode, summoned well over 200 revenants into the courtyard area and some friendly cyberdemons to help me out, unfroze the game and played until all the revenants were dead. No problems detected at all.

Ragnor wrote:Actor movement..huh. Could that be the monsters, missiles and me? I use an Xbox 360 controller if that helps. The Revenants in Expanded shoot two missiles at once as well.

I don't know what causes it. The crash happens in a line that gets executed each tic for nearly each moving actor in the game. It occurs during a signed integer division (idiv instruction) - strangely enough with values that should never ever produce an exception. Integer divisions can cause an overflow exception but only if a 64 bit value divided by a 32 bit value produces a value that cannot be represented in 32 bit. But that's clearly not the case here unless something in your CPU goes wrong. C compilers don't even produce code that can cause such an overflow. As soon as there's a chance the values are too large it switches to a more complex subroutine to safely perform the division.

It's the first time I hear about a problem caused by dividing by 1. An identity operation cannot cause an overflow. Doesn't make sense.


What would make more sense to me is that the crash is weird enough that the crash report is inaccurate; but then that makes it hard to debug. Another possibility is that your CPU is malfunctioning.

The crash location looks legit.

The values in the registers are perfectly fine for having reached that piece of code.

Oh dear, looks like I have an Integer Anomaly..

If the CPU is malfunctioning, how would I detct that? *nowhere near knowledgeable about this kind of thing*

Easiest way would probably be to write some assembly code that increments a 32-bit value and divides it by one every loop, until the value hits 0xFFFFFFFF. At worst, it should momentarily freeze your system while it counts the values; mind you with modern computers even that value is pretty big but it is doable, the routine should be done within 30 seconds if not sooner, accounting for interrupts and other things which may distract it. If there is a problem, then the code itself would crash. That would indicate a CPU error.

Optionally, the code could probably include system calls to allow the operating system to retain control and do other tasks, but that would cause the test execution to take much longer. Mind you I've never done anything like this before, the most complex work I've ever done in assembly language was to emulate SVGA chipsets in DOS, and that was nothing more than simple interrupt interceptions and translations.