|
From: Dan K. <da...@ke...> - 2009-08-05 13:50:15
|
Does this make any sense? Invalid write of size 4 ... Address 0x1c1ddcec is 1,629,372 bytes inside a block of size 4,065,600 alloc'd ... (How can you have an invalid address in the middle of a big block?) Or is this more likely a symptom of memory corruption breaking Valgrind? - Dan |
|
From: Tom H. <to...@co...> - 2009-08-05 14:14:52
|
On 05/08/09 14:44, Dan Kegel wrote: > Does this make any sense? > > Invalid write of size 4 > ... > Address 0x1c1ddcec is 1,629,372 bytes inside a block of size 4,065,600 alloc'd > ... > > (How can you have an invalid address in the middle of a big block?) It's perfectly possible if you've done VALGRIND_MAKE_MEM_NOACCESS() on that piece of memory. Most commonly that would be because that big piece of memory is really food for some sort of allocator that is marking it all as NOACCESS until it hands out particular pieces. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Dan K. <da...@ke...> - 2009-08-05 15:10:03
|
On Wed, Aug 5, 2009 at 7:14 AM, Tom Hughes<to...@co...> wrote: >> (How can you have an invalid address in the middle of a big block?) > > It's perfectly possible if you've done VALGRIND_MAKE_MEM_NOACCESS() on that > piece of memory. Most commonly that would be because that big piece of > memory is really food for some sort of allocator that is marking it all as > NOACCESS until it hands out particular pieces. This is a bitmapped frame buffer, so the app probably didn't do that. I'm having heap corruption problems (sorry, I should have mentioned that), so that's still my favorite explanation. |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-05 22:48:06
|
On Thu, Aug 6, 2009 at 1:09 AM, Dan Kegel<da...@ke...> wrote: > On Wed, Aug 5, 2009 at 7:14 AM, Tom Hughes<to...@co...> wrote: >>> (How can you have an invalid address in the middle of a big block?) >> >> It's perfectly possible if you've done VALGRIND_MAKE_MEM_NOACCESS() on that >> piece of memory. Most commonly that would be because that big piece of >> memory is really food for some sort of allocator that is marking it all as >> NOACCESS until it hands out particular pieces. > > This is a bitmapped frame buffer, so the app probably didn't do that. > I'm having heap corruption problems (sorry, I should have mentioned > that), so that's still my favorite explanation. It could also happen if you munmap'd the middle of a heap block, but that seems unlikely (not to mention a terrible idea as it would likely crash the allocator). N |