From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <03fcbb04cd320b98a8f1d042d14b3880@plan9.bell-labs.com> Date: Thu, 6 Jan 2005 22:32:06 -0500 From: jmk@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] mallocalign? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 29363f76-eace-11e9-9e20-41e7f4b1d025 It has only been used in the recent ether8169.c driver, which hasn't seen much use I suppose (there's one person here started using a machine with that chip yesterday as his terminal). On an x86 there should be no real functional difference between xpanalloc and mallocalign if the space is never freed, the memory type and location used is similar. You can send me more details of what you are doing off-line if you want. --jim On Thu Jan 6 21:49:16 EST 2005, newsham@lava.net wrote: > Hi, > I'm wondering how much confidence there is in the mallocalign > implementation. I'm seeing strange behavior in my code using it. > I started seeing a crash when I changed a simple buffer size definition > in one of my modules. On a hunch I replaced mallocalign with > a macro that uses xspanalloc and the problem disappeared. > > Normally my first instinct would be that the implementation is solid > and that I have a heap corruption issue somewhere, but I noticed > that mallocalign is not used elsewhere in the kernel sources right > now. I'm also fairly confident about the heap buffers that were > directly affected by the size change (although corruption elsewhere > isnt out of the question). Has this function seen much use yet? > > (meanwhile I'm still working under the assumption that my code > trashed the heap somehow). > > Tim N.