Message196243
| Author |
tim.peters |
| Recipients |
amaury.forgeotdarc, mmokrejs, tim.peters, vstinner |
| Date |
2013年08月26日.20:09:19 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1377547759.37.0.539601032578.issue18843@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Memory corruption can be difficult to track down. Best thing you can do is strive to find a test case as small and fast as possible that shows the same kind of error.
By "rogue extension module" I just mean 3rd-party C code (like, for example, matplotlib).
I doubt it's a hardware problem. That's possible, of course, but these kinds of errors are almost always the result of errors in C code.
The stacktrace probably isn't helpful. All we know is that memory got corrupted _sometime_ between someone asking for a block of memory and releasing it. The corruption may have happened a millisecond ago, or weeks ago (if the program ran that long) - there's no way to tell by the time the memory corruption is _detected_.
About "object counter overflows", I'm not sure what you're asking. Python doesn't have an object counter. The "serial number" in debug-mode allocators just counts the number of times a debug-mode malloc has been called. If that overflows, it would do no harm.
Bottom line: no matter what's to blame here, the smaller & faster a test program you can find, the more likely it is to get fixed. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2013年08月26日 20:09:19 | tim.peters | set | recipients:
+ tim.peters, amaury.forgeotdarc, mmokrejs, vstinner |
| 2013年08月26日 20:09:19 | tim.peters | set | messageid: <1377547759.37.0.539601032578.issue18843@psf.upfronthosting.co.za> |
| 2013年08月26日 20:09:19 | tim.peters | link | issue18843 messages |
| 2013年08月26日 20:09:19 | tim.peters | create |
|