Re: [Valgrind-users] Memory allocation errors starting valgrind

[Art H. <ah...@ai...>]

On Thu, Jan 22, 2004 at 04:29:56PM -0800, Jeremy Fitzhardinge wrote:
> On Thu, 2004-01-22 at 16:20, Art Haas wrote:
> > 'b' just gets bigger, but elfbrk and 'delta' stay the same.  Anything else
> > I can try?
> 
> Well, delta is just 32M, so I wouldn't expect it to change until the
> very end. b will keep growing until it hits endbrk (it'll take a while
> in 32M steps).
> 
> Ah! And that printf itself will cause the failure, because it maps some
> memory.  So, comment out the printf.  If that doesn't work, try this as
> well:
> *** ume.c	6 Jan 2004 16:02:29 -0000	1.7
> --- ume.c	23 Jan 2004 00:29:03 -0000
> *************** ESZ(Addr) mapelf(struct elfinfo *e, ESZ(
> *** 352,357 ****
> --- 352,358 ----
>   		    "perhaps we hit the datasize ulimit?\n");
>   	    return 0;
>   	 }
> + 	 munmap((char *)PGROUNDUP(b), delta);
>   	 b += delta;
>         }
>         munmap(initb, (char *)PGROUNDDN(elfbrk)-initb);

I bumped the magic number back up to 64 and removed the print() call,
and the message about sbrk failing went away, but valgrind did not run.
Instead I got a long print out about the options - just what you see
when you run 'valgrind --help'. Adding in the munmap() call didn't help
either.

I then tried explicitly adding in a '--tool' option ...

$ valgrind --tool=memcheck ls -l
Illegal instruction
$

No luck again. For grins I then restored the number back to 256, and got
the old error message again.

> But basically I consider this whole mucking about with brk a bug anyway,
> so I intend changing the way all this works.

I'll keep building the CVS code and keep trying things out. If I can try
out some more patches let me know.

Art

-- 
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822