¶It's good to know I'm not crazy
Going through my weekly backlog of email, I found a crash report on this assembly code:
004e19f3: 0f73d430 psrlq mm4, 30h
004e19f7: 0f7ee0 movd eax, mm4
004e19fa: 0fe504c5d89f5c pmulhw mm0, [eax*8+005c9fd8] <-- FAULT
00
This is the division approximation code for the temporal smoother filter in VirtualDub. It essentially computes:
result.rgb = color.rgb * div_table[sum >> 48];
The crash was an access violation, indicating a bad pointer. Problem number one is that, the way the code's structured, the table index never exceeds 128. Problem number two:
EAX = 00800000
Extracting the top 16 bits of a 64-bit unsigned quantity gave a value bigger than 0x10000. That's... not possible.
I couldn't figure out how this could happen, so I wrote back the user asking if the crash was reproducible. As it turned out, he'd already diagnosed the problem: bad RAM. My guess is that the OS had done a context switch in the middle of these instructions, giving the opportunity for EAX to be dumped to memory and be corrupted. Sometimes the impossible does actually happen... well, at least when hardware failure is involved.