Tim Peters added the comment:
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????
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
