Message196557
| Author |
neologix |
| Recipients |
amaury.forgeotdarc, mmokrejs, neologix, sjt, skrah, tim.peters, vstinner |
| Date |
2013年08月30日.15:13:53 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CAH_1eM219f7PZBoALm=5U1+d_A_ZmVMc7NpWedS47AJ-2xEeVg@mail.gmail.com> |
| In-reply-to |
<1377856407.33.0.585951271385.issue18843@psf.upfronthosting.co.za> |
| Content |
2013年8月30日 Martin Mokrejs <report@bugs.python.org>:
> Per comment from Charles-François, so you mean that this single-bit change won't be caught by valgrind, right? Why does not memtest86+ detect that? Could python when compiled with the --with-pydebug print also physical, hardware address of the wrong value? That would be really helpful here! Thanks.
I mean that in the vast majority of cases, a single bit flip is due to
a hardware error.
That can be due to faulty RAM, electric noise, cosmic rays...
Software-induced memory corruptions generally corrupt at least a byte.
Do you reproduce the crash systematically, or is it random? |
|