On Fri, Jul 07, 2017 at 08:52:42AM +0200, Otto Moerbeek wrote: > On Fri, Jul 07, 2017 at 08:35:39AM +0200, Otto Moerbeek wrote: > > > On Fri, Jul 07, 2017 at 04:27:30AM +0200, Ingo Schwarze wrote: > > > > > The end of the problem is that in malloc_bytes(), malloc.c line 981, > > > the code enters the double for loop with a bp having the inconvenient > > > property that in bp->bits, all sixteen entries are 0, causing the > > > inner for loop to spin indefinitely. > > > > > > I must admit, though, that i have no idea what that means, and where > > > the problem starts leading to that ugly end: i clearly underestimated > > > the difficulty of reading malloc.c ... :-o > > > > > > But maybe that rings a bell for somebody else. > > > > I guess that would be me ;) > > > > WHat happens is the struct chunk_info says: there are chunks free, but > > the bitmap itself says: no more. > > > > I can reproduce, but I do not understand it yet. Will do some more > > investigation, > > I think I found it: requested size is not recorded for malloc(0), > bp->offset is not initialized in that case. Other code is carefull not to > use ->offset for size == 0.
> OA I have no idea who inserted "OA" here ;-) > -Otto > > Index: malloc.c > =================================================================== > RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v > retrieving revision 1.226 > diff -u -p -r1.226 malloc.c > --- malloc.c 19 Jun 2017 03:06:26 -0000 1.226 > +++ malloc.c 7 Jul 2017 06:51:30 -0000 > @@ -1013,7 +1013,7 @@ malloc_bytes(struct dir_info *d, size_t > /* Adjust to the real offset of that chunk */ > k += (lp - bp->bits) * MALLOC_BITS; > > - if (mopts.chunk_canaries) > + if (mopts.chunk_canaries && size > 0) > bp->bits[bp->offset + k] = size; > > k <<= bp->shift;
