On Nov 17, 2012, at 8:01 PM, Nils Bruin <nbr...@sfu.ca> wrote: > 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)
At one point I had the goal of creating a suppressions file so that the doctests passed "cleanly". I'm sure some of the suppressions were actual problems, but it would at least allow you to find new problems. I still have the scripts that I used to collect and remove duplicate suppressions. I would be happy to run them again if people thought it would be useful. Sadly my machine isn't the fastest, so it takes quite a while (running all the doctests under valgrind is _slow_). I never did make it all the way through the test suite. But especially if I knew the likely areas it wouldn't be too hard to run some overnight and see what turns up. -Ivan -- 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.
