On Fri, May 20, 2011 at 2:47 PM, Steve Kemp <[email protected]> wrote:
> 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
Are you sure this isn't the temporary one that is allocated but freed
immediately once the virtqueue is empty:
static VirtIOBlockReq *virtio_blk_get_request(VirtIOBlock *s)
{
VirtIOBlockReq *req = virtio_blk_alloc_request(s);
if (req != NULL) {
if (!virtqueue_pop(s->vq, &req->elem)) {
qemu_free(req); <--- virtqueue empty, we're done
return NULL;
}
}
return req;
}
> 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.
Sounds scary 8).
Stefan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
