It would be a severely lame OS that allowed a process to overwrite another process's memory ;-)  "Bad C or C++ code", in the process you're running, is still the best guess.

A memory module that sometimes dropped the last bit _could_ be at fault, but I doubt it (0xfb changes to 0xfa if the last bit is cleared).

That the address is different across the two failure examples doesn't rule out bad memory, though:  the memory address an OS shows you is a "logical address", an _offset_ from the start of the physical memory the OS happened to assign to the process.  Across different runs, the same physical memory location may be shown as any number of different logical addresses.

We'll understand why it's off by 1 eventually ;-)  For example, it could be C code as simple as:

    char* p = (char *)allocate_some_memory(80);
    ...
    p -= 5;
    ...
    if (something)
        --*p;

It's extremely easy for C code to do insane stores; indeed, that's why there are so many sophisticated tools for trying to find the source of memory corruption in C/C++ code.

Question:  did the last failure come from your code, or from merely running `emerge`?  You said your code "was parsing an XML file" at the time, but there's no trace of expat (or any other xml parsing code) in the traceback, and the traceback "bottoms out" at `emerge`.  Maybe this has nothing at all to do with your code????