uma and double free detection?
Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
Alfred Perlstein wrote: Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( THat's an INVARIANTS thing, even without UMA... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
* Terry Lambert [EMAIL PROTECTED] [020327 13:30] wrote: Alfred Perlstein wrote: Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( THat's an INVARIANTS thing, even without UMA... /usr/src/sys/i386/conf % grep INVA BRIGHT options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structu All I got was a panic because uma seemed to get confused rather than catch the double free. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
Alfred Perlstein wrote: * Terry Lambert [EMAIL PROTECTED] [020327 13:30] wrote: Alfred Perlstein wrote: Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( THat's an INVARIANTS thing, even without UMA... /usr/src/sys/i386/conf % grep INVA BRIGHT options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structu All I got was a panic because uma seemed to get confused rather than catch the double free. I got a similar untraceable panic because the ucred reference counter was overlayed with an invariants structure. Probably invariants is stomping something that is used as a marker into seeming validity. It's very tempting to require that invariants add their own crap to to the front of a structure, and then hide it, so that this is not possible. It was a real pain in the butt to track doewn the cred free problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
On Wed, 27 Mar 2002, Alfred Perlstein wrote: Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( Oh! Thanks for pointing this out. Originally it could, but with the per cpu buckets it lost the ability to until the data was really freed. What I will do is disable per cpu buckets if INVARIANTS is on. The reason for this is that you have to lock the zone and look at the slabs to do double free detection. Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
On Wed, 27 Mar 2002, Alfred Perlstein wrote: * Terry Lambert [EMAIL PROTECTED] [020327 13:30] wrote: Alfred Perlstein wrote: Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( THat's an INVARIANTS thing, even without UMA... /usr/src/sys/i386/conf % grep INVA BRIGHT options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structu All I got was a panic because uma seemed to get confused rather than catch the double free. Yikes, a panic? From a double free? Was this from malloc or zalloc? Are you sure there was no other memory corruption? Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
* Jeff Roberson [EMAIL PROTECTED] [020327 14:16] wrote: On Wed, 27 Mar 2002, Alfred Perlstein wrote: Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( Oh! Thanks for pointing this out. Originally it could, but with the per cpu buckets it lost the ability to until the data was really freed. What I will do is disable per cpu buckets if INVARIANTS is on. The reason for this is that you have to lock the zone and look at the slabs to do double free detection. That's really not a good idea, how is one supposed to debug problems with the per-cpu stuff if INVARIANTS disables them? Why don't you look at how the old malloc(9) did it, it will show you how to do it with minimum performance impact (i think). -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
On Wed, 27 Mar 2002, Alfred Perlstein wrote: Oh! Thanks for pointing this out. Originally it could, but with the per cpu buckets it lost the ability to until the data was really freed. What I will do is disable per cpu buckets if INVARIANTS is on. The reason for this is that you have to lock the zone and look at the slabs to do double free detection. That's really not a good idea, how is one supposed to debug problems with the per-cpu stuff if INVARIANTS disables them? Why don't you look at how the old malloc(9) did it, it will show you how to do it with minimum performance impact (i think). -Alfred Given the structure of UMA it is much more complicated than the original malloc. No matter how you do it you'll have to grab the zone lock to check for double frees. Which means that the per cpu free lists will have to be drained so that you know the item isn't already in one of those. Which means the operation can not really use the per cpu queues unless you just search them all without really retiring the memory. So I have two options. The first, which I already suggested, and which requires the least code, is to disable per cpu queues. You can have it excercise most of the code paths by just forcing all bucket allocation to fail. Or, the second approach, I can write a significant amount of new code in both the allocation and free routines that is only executed when invariants is on. It would effectively execute all of the code paths in the per cpu queues but you would have to lock the zone to verify an address and then lock each per cpu queue to make sure it does not reoccur. I favor the first solution because it has less risk. What you end up with is the ability to debug UMA or users of UMA, but not both at the same time. I think this is acceptable. Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
