On Nov 17, 2012, at 9:56 PM, Nils Bruin <nbr...@sfu.ca> wrote: > 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.
Thanks for the explanation. That makes sense. It sounds like there's not much valgrind will help with, but I'll give it a go anyway. -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.
