I am extremely excited because we're testing a new system to detect #Firefox crashes caused by bad memory.
We're currently finding a very high correlation between potential bit-flips detected by this system and crashes we thought were caused by bad hardware.
This will help us in two ways: we'll be able to avoid spending time looking at those crashes and we might also inform users that their memory went bad and they need to have their machines checked.
This would be a good idea, can the same feature be built in to all Linux based systems, as bad hardware has all sorts of odd effects, or can do.
Ah ok, I will run a check on my system at some point to see if there are any issues.
But thanks
@gabrielesvelto @zleap my first thought was that the OS could do the mapping check locally on every crash (and possibly even do an isolated memory test if there’s a match), no need for collection, just warn the user about the failing hardware. Would that not work?
@ShadSterling @zleap that's harder for the OS to do. From the OS point of view the program encountered an exception/signal of some kind, which it delivered to the application. What the application does with it is up to the application. It might crash or it might process the signal/exception and proceed.
It wouldn't be impossible, just harder, and naturally it would involve a user-space component to surface the issues that had been detected.
@gabrielesvelto @zleap doesn’t the OS define the default exception handlers for e.g. page faults? This isn’t an internal error, it’s an attempt to access an address that’s not mapped into the process address space, the OS has to check for possible page swaps before it can tell it’s an error. Seems to me it could even queue the memory check before returning control to the app’s exception handler
@zleap we can do this because we collect crashes. Most other applications don't. What Linux distros could do though is ship Memtest86+ by default as a boot option, so users can check their machines if they experience hard-to-explain instability.