On Nov 17, 12:20 pm, Ivan Andrus <darthand...@gmail.com> wrote: > 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.
Anything that has to do with libsingular. The problem is that OTHER tests may well exercise this code much better than libsingular's own doctests. However, with an unmodified libsingular it's unlikely you'll find anything. omalloc allocates pages of system memory and then manages pieces of it by itself. So as far as valgrind is concerned, there is relatively little allocation/deallocation activity. I think you can go further and tell valgrind about the functioning of alternative memory managers. That would improve diagnostics a little. But if the compact memory layout of omalloc (the compactness is its purpose) isn't changed, you still have a good chance that an access-after-free refers to perfectly valid memory (a block that now has been reallocated for a different purpose) This is the issue I'm trying to address with malloc-version of singular. Combined with a malloc implementation that puts blocks on separate pages, on the edge of the page, unmaps any page upon deallocation, and tries to avoid reusing or using adjacent logical pages means that any illegal access is almost sure to segfault. BSD's gmalloc does that. It seems glibc's malloc with MALLOC_CHECK_=2 or 3 does at least a bit of that. The real problem here is that we (Simon, Volker or I) don't know for sure what the refcount and deletion protocols are for Singular objects. It seems to be the kind of thing that is folklore inside the Singular group but was never properly documented. Singular was not designed to be a clean library, but it does seem to be a direction Singular is heading, so perhaps this might sometime get documented properly. I just think Sage can't wait for the decade or so that this is probably going to take. -- 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.
