On Fri May 20, 2011 at 14:16:05 +0100, Stefan Hajnoczi wrote:
> > I've had a quick read of hw/virtio-blk.c but didn't see anything
> > glaringly obvious. I'll need to trace through the code, drink more
> > coffee, or get lucky to narrow it down further.
>
> Enabling the memory allocation trace events and adding the
> __builtin_return_address() to them should provide enough information
> to catch the caller who is leaking memory.
I'm trying to do that at the moment. So far the only thing I've
done is add a trace on virtio_blk_alloc_request - I'm noticing
a leak there pretty easily.
I see *two* request structures be allocated all the time, one
is used and freed, the other is ignored. That seems pretty
conclusively wrong to me, but I'm trying to understand how that
happens:
virtio_blk_alloc_request 0.000 req=0x91e08f0 -> Allocation 1
virtio_blk_alloc_request 77.659 req=0x9215650 -> Allocation 2
virtio_blk_rw_complete 449.469 req=0x91e08f0 ret=0x0 -> First is used.
virtio_blk_req_complete 1.955 req=0x91e08f0 status=0x0 -> First is freed.
second is never seen again.
Steve Kemp
--
Bytemark Hosting
http://www.bytemark.co.uk/
phone UK: 0845 004 3 004
Dedicated Linux hosts from 15ukp ($30) per month
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
