Re: How to diagnose memory leak in kvm-qemu-0.14.0?

[Stefan Hajnoczi <stefanha@gmail.com>]

On Fri, May 20, 2011 at 2:47 PM, Steve Kemp <steve@bytemark.co.uk> 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