9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] mallocalign?
@ 2005-01-07  2:48 Tim Newsham
  2005-01-07  3:32 ` jmk
  2005-01-07  3:48 ` Russ Cox
  0 siblings, 2 replies; 3+ messages in thread
From: Tim Newsham @ 2005-01-07  2:48 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [9fans] mallocalign?
  2005-01-07  2:48 [9fans] mallocalign? Tim Newsham
@ 2005-01-07  3:32 ` jmk
  2005-01-07  3:48 ` Russ Cox
  1 sibling, 0 replies; 3+ messages in thread
From: jmk @ 2005-01-07  3:32 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [9fans] mallocalign?
  2005-01-07  2:48 [9fans] mallocalign? Tim Newsham
  2005-01-07  3:32 ` jmk
@ 2005-01-07  3:48 ` Russ Cox
  1 sibling, 0 replies; 3+ messages in thread
From: Russ Cox @ 2005-01-07  3:48 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> 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.

There's not much confidence in the mallocalign implementation.
I exercised it a little, but I won't be surprised if there are lurking bugs.

Try including <pool.h> in your source file and then before
and after the mallocalign run poolcheck(mainmem).
If there's a corruption due to mallocalign, the second
one should fail.

Russ


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-01-07  3:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-07  2:48 [9fans] mallocalign? Tim Newsham
2005-01-07  3:32 ` jmk
2005-01-07  3:48 ` Russ Cox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).