HandBrake found me a defective RAM module on my PC: it freezed in the middle of video conversion - every single time on exactly the same video position. After further investigation I found the "bug" in my RAM...
One possibility is that he didn't restart the program between retries, and the memory in question was already allocated. Another possibility is that he only ran handbrake and nothing else, and the OS was in more or less the same state both times. It could be that the problem was triggered by stack allocations rather than heap allocations and the video block in question caused a large-ish recursion that hit the problem, and would be likely to hit the problem no matter what was running since it's somewhat rare to have large stack allocations.
Chances are it was actually none of those things, but they're real possibilities anyway.
What with Windows Update and the variety of other similar OS- and application-level auto-updaters, is getting the computer into a very similar state likely? I'm not sure but my gut says no.
That said, at first I was imagining a desktop computer with 4 or 8 memory modules, but given a machine with just 2 modules, maybe it follows that one module usually gets filled with "core stuff" and the second, defective module somewhat infrequently sees "big user stuff" after the first module is filled, and I guess that isn't too much of a head-scratcher when it comes to identifying the source of the problem.
Actually, it does. It's possible to calculate WCET involving ram accesses, as the behaviour is deterministic; there's a set latency.
It's not possible whenever SWAP is involved, which is why most of the realtime world simply avoids swap. This is mentioned in the Genode handbook, if you're willing to dig into it more.
I assumed that swap wasn't involved, and I was even going to mention it but decided against. While it is remotely possible, there's not much reason to suspect swap, Handbrake was actively running, doesn't normally use enough memory to start swapping, and people ripping DVDs usually know not to be doing other things and/or using all their memory while ripping.
That said, are you saying swap in the OS really is non-deterministic by design, or just hard to predict? And what does Genode have to do with this, assuming he wasn't using Genode?
2. "Clean" mmap(2)ed pages count as "cache" in the above.
3. Memory allocations are usually physically contiguous—when you mmap(2) something, and then read every byte of that thing in order, that thing usually ends up in a contiguous run of physical memory as clean page-cache entries. This will be true to the extent that you have no other memory pressure forcing the page cache to fragment, evict other caches, or overwrite itself.
4. ASLR just juggled virtual-memory, not physical memory. IIRC (not a kernel dev), Linux at least has an allocation strategy that will effectively allocate physical memory serially if there's no contention.
Put 1-4 together, and you get a system where a big mmap(2)ed file that takes up all the physical memory of an otherwise-idle system, will end up putting that thing into the same places each time (because that's the only place such a large allocation will fit.)
If Handbrake fails, it's only because your hardware is broken.
Since I used this machine to backup my data on DVDs I got many errors in my data on backup. But since I had a copy of everything on another HDD I throw the DVDs away and backed up everything again (after replacing defective RAM module and reinstalling OS and SW on my machine).
Which in itself alludes to the encoding stream itself (or one of the intermediate streams during the encoding process) having some form of strong channel coding - in error detection - either by design or not. Detect 1-bit error in a gig+ stream, perhaps without easily being able to locate it, beyond saying it's in such or such chunk (the current frame(s) being processed).