On Nov 17, 1:01 am, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > On 2012-11-16 19:35, Nils Bruin wrote:> On Nov 15, 11:59 pm, Jeroen Demeyer > <jdeme...@cage.ugent.be> wrote: > After adding every single ticket, there is reason to expect differently. > This stuff is *so sensitive* to changes, even changes which look > completely unrelated. That's why the effort to do strict checking on memory management should help (and it was in that light that I interpreted your request). I think the sensitivity comes from the fact that you have to wait for the coincidence that a freed-too-early location gets reused and *then* written in its own role (i.e., actual corruption).
gc.collect() all the time should make deletions a little more predictable and a very strict malloc/free should detect the problem sooner. I'm afraid that MALLOC_CHECK_ isn't as good as BSD's gmalloc, where even an access-after-free is a segfault (and many out-of-bound accesses too). Once one gets a little better in writing valgrind suppressions it's easy to let valgrind produce less irrelevant output, so perhaps there's a future for that. Or perhaps a tool to query and sort valgrind reports after the fact (basically filter after the fact). Perhaps it's time for William to hire someone again who is really good at this stuff, because mathematically it's utterly uninteresting work (and it really is finding and cleaning other people's mess) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
