Bug in alloc.c?

I'm getting an infinite loop in alloc.c, which is located in
MSL/MSL_C/MSL_Common/Src. This is with CW 9.5. The function is
allocate_from_var_pools. There is a do/while loop that searches for a
block with the required size to allocate a block of memory. I got to this
point through new, not malloc, in my own code. My new requests 16384
floats, which new translates to 65536 (four bytes per float) but which
alloc first converts to 65552 before starting the do/while loop. After
that, the loop starts trying to find a block. In other situations in my
program, this allocation works, but in one reproducible situation the loop
becomes infinite, meaning it neither finds a block, nor ever breaks out
with a failed allocation. It should be noted that there is plenty of free
memory on my computer, and we're only talking about 65k here.

Any thoughts?

________________________________________________________________________
Keith Wiley kwiley DeleteThis @cs.unm.edu http://www.unm.edu/~keithw

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
-- Edwin A. Abbott, Flatland
________________________________________________________________________

In article <Pine.LNX.4.60.0505271341480.12157 RemoveThis @ramon.cs.unm.edu>,
Keith Wiley <kwiley RemoveThis @cs.unm.edu> wrote:

> I'm getting an infinite loop in alloc.c, which is located in
> MSL/MSL_C/MSL_Common/Src. This is with CW 9.5. The function is
> allocate_from_var_pools. There is a do/while loop that searches for a
> block with the required size to allocate a block of memory. I got to this
> point through new, not malloc, in my own code. My new requests 16384
> floats, which new translates to 65536 (four bytes per float) but which
> alloc first converts to 65552 before starting the do/while loop. After
> that, the loop starts trying to find a block. In other situations in my
> program, this allocation works, but in one reproducible situation the loop
> becomes infinite, meaning it neither finds a block, nor ever breaks out
> with a failed allocation. It should be noted that there is plenty of free
> memory on my computer, and we're only talking about 65k here.
>
> Any thoughts?

You've got my attention (I wrote this code). The most common cause of a
situation like this is heap corruption from client code. However it is
always possible that there is a bug in malloc. This malloc
implementation is purposefully not robust in order to maximize
performance and to make heap corruption bugs as visible as possible.

The heap is a doubly linked and circular list of memory chunks. The
behavior you describe indicates that the circularity of this chain has
been compromised, perhaps it has been short circuited such that
pool_obj->start_ no longer points anywhere into that circle. After
making one circle around the chain, the loop should give up and go to
the OS for more memory.

If you could create a demo that you would be willing to mail me, I'd be
happy to look at it. You could also try plugging in a debug new or
malloc which might catch an earlier bug. There's one here you are
welcome to try:

http://home.twcny.rr.com/hinnant/MemoryManager/

-Howard