[Qemu-devel] [PATCH 00/29] Fix memory leak relevant to calling qemu_allocate_irqs

[Qemu-devel] [PATCH 00/29] Fix memory leak relevant to calling qemu_allocate_irqs

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

Before I sent some patches to fix memory leak spotted by valgrind and
those are relevant to qemu_allocate_irqs. Then I find all the places
calling this function through code searching and test by valgrind to
check whether they have memory leak. These patches fix these memory leaks.

Sorry that maybe the names of the patches are vertiginous while I could
not find out better names and I try to sort them out.

Thanks,
Shannon

Shannon Zhao (29):
  hw/ide/ahci.c: Fix memory leak spotted by valgrind
  hw/ide/cmd646.c: Fix memory leak spotted by valgrind
  hw/i386/pc: Fix memory leak spotted by valgrind
  hw/i386/pc_q35.c: Fix memory leak spotted by valgrind
  hw/isa/lpc_ich9.c: Fix memory leak spotted by valgrind
  hw/isa/i82378.c: Fix memory leak spotted by valgrind
  hw/timer/arm_timer.c: Fix memory leak spotted by valgrind
  hw/intc/exynos4210_gic.c: Fix memory leak spotted by valgrind
  hw/sparc/leon3.c: Fix memory leak spotted by valgrind
  hw/sparc/sun4m.c: Fix memory leak spotted by valgrind
  hw/ppc/mac_oldworld.c: Fix memory leak spotted by valgrind
  hw/ppc/ppc440_bamboo.c: Fix memory leak spotted by valgrind
  hw/ppc/prep.c: Fix memory leak spotted by valgrind
  hw/mips/mips_int.c: Fix memory leak spotted by valgrind
  hw/mips/mips_jazz.c: Fix memory leak spotted by valgrind
  hw/lm32/lm32_boards.c: Fix memory leak spotted by valgrind
  hw/lm32/milkymist.c: Fix memory leak spotted by valgrind
  hw/m68k/mcf5206.c: Fix memory leak spotted by valgrind
  hw/openrisc/pic_cpu.c: Fix memory leak spotted by valgrind
  hw/unicore32/puv3.c: Fix memory leak spotted by valgrind
  hw/sh4/r2d.c: Fix memory leak spotted by valgrind
  hw/alpha/typhoon.c: Fix memory leak spotted by valgrind
  hw/arm/nseries.c: Fix memory leak spotted by valgrind
  hw/arm/omap_sx1.c: Fix memory leak spotted by valgrind
  hw/arm/palm.c: Fix memory leak spotted by valgrind
  hw/arm/spitz.c: Fix memory leak spotted by valgrind
  hw/arm/tosa.c: Fix memory leak spotted by valgrind
  hw/display/tc6393xb.c: Fix memory leak spotted by valgrind
  hw/s390x/sclpcpu.c: Fix memory leak spotted by valgrind

 hw/alpha/typhoon.c       |  4 ++--
 hw/arm/nseries.c         |  4 ++--
 hw/arm/omap_sx1.c        |  2 +-
 hw/arm/palm.c            |  1 +
 hw/arm/spitz.c           |  6 +++++-
 hw/arm/tosa.c            |  1 +
 hw/display/tc6393xb.c    |  2 +-
 hw/dma/rc4030.c          |  2 +-
 hw/i386/pc.c             |  4 ++--
 hw/i386/pc_piix.c        |  4 +---
 hw/i386/pc_q35.c         |  5 ++---
 hw/ide/ahci.c            |  1 +
 hw/ide/cmd646.c          |  1 +
 hw/intc/exynos4210_gic.c |  7 +++----
 hw/isa/i82378.c          |  6 +++---
 hw/isa/lpc_ich9.c        |  5 +----
 hw/lm32/lm32_boards.c    | 12 ++++++------
 hw/lm32/milkymist.c      |  6 +++---
 hw/m68k/mcf5206.c        | 10 ++++++++--
 hw/mips/mips_int.c       |  1 +
 hw/mips/mips_jazz.c      | 15 ++++++++++++++-
 hw/openrisc/pic_cpu.c    |  1 +
 hw/ppc/mac_oldworld.c    |  1 +
 hw/ppc/ppc440_bamboo.c   | 15 +++++++++++++++
 hw/ppc/prep.c            |  6 +++---
 hw/s390x/sclpcpu.c       |  9 ++++++---
 hw/sh4/r2d.c             | 10 ++++++++++
 hw/sparc/leon3.c         |  9 ++++++++-
 hw/sparc/sun4m.c         | 10 ++++++----
 hw/timer/arm_timer.c     |  1 +
 hw/unicore32/puv3.c      |  8 ++++----
 include/hw/i386/pc.h     |  2 +-
 include/hw/m68k/mcf.h    |  3 +--
 33 files changed, 117 insertions(+), 57 deletions(-)

-- 
2.0.4

[Qemu-devel] [PATCH 01/29] hw/ide/ahci.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==23381== 8 bytes in 1 blocks are definitely lost in loss record 438 of 2,785
==23381==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23381==    by 0x35478F: malloc_and_trace (vl.c:2556)
==23381==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==23381==    by 0x3ED98B: qemu_extend_irqs (irq.c:55)
==23381==    by 0x3EDA17: qemu_allocate_irqs (irq.c:64)
==23381==    by 0x43D767: ahci_init (ahci.c:1356)
==23381==    by 0x43DAC5: sysbus_ahci_realize (ahci.c:1520)
==23381==    by 0x3EA4CC: device_set_realized (qdev.c:1058)
==23381==    by 0x516CD2: property_set_bool (object.c:1514)
==23381==    by 0x5155CC: object_property_set (object.c:837)
==23381==    by 0x5178EE: object_property_set_qobject (qom-qobject.c:24)
==23381==    by 0x51583B: object_property_set_bool (object.c:905)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/ide/ahci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 9e5d862..4702a05 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -1367,6 +1367,7 @@ void ahci_init(AHCIState *s, DeviceState *qdev, AddressSpace *as, int ports)
         ad->port.dma->ops = &ahci_dma_ops;
         ide_register_restart_cb(&ad->port);
     }
+    g_free(irqs);
 }
 
 void ahci_uninit(AHCIState *s)
-- 
2.0.4

Re: [Qemu-devel] [PATCH 01/29] hw/ide/ahci.c: Fix memory leak spotted by valgrind

[Peter Maydell]

On 28 May 2015 at 13:08, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> valgrind complains about:
> ==23381== 8 bytes in 1 blocks are definitely lost in loss record 438 of 2,785
> ==23381==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==23381==    by 0x35478F: malloc_and_trace (vl.c:2556)
> ==23381==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
> ==23381==    by 0x3ED98B: qemu_extend_irqs (irq.c:55)
> ==23381==    by 0x3EDA17: qemu_allocate_irqs (irq.c:64)
> ==23381==    by 0x43D767: ahci_init (ahci.c:1356)
> ==23381==    by 0x43DAC5: sysbus_ahci_realize (ahci.c:1520)
> ==23381==    by 0x3EA4CC: device_set_realized (qdev.c:1058)
> ==23381==    by 0x516CD2: property_set_bool (object.c:1514)
> ==23381==    by 0x5155CC: object_property_set (object.c:837)
> ==23381==    by 0x5178EE: object_property_set_qobject (qom-qobject.c:24)
> ==23381==    by 0x51583B: object_property_set_bool (object.c:905)
>
> Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  hw/ide/ahci.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index 9e5d862..4702a05 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -1367,6 +1367,7 @@ void ahci_init(AHCIState *s, DeviceState *qdev, AddressSpace *as, int ports)
>          ad->port.dma->ops = &ahci_dma_ops;
>          ide_register_restart_cb(&ad->port);
>      }
> +    g_free(irqs);
>  }

Freeing the return value of qemu_allocate_irqs()
directly rather than using qemu_free_irqs() looks
dubious to me.

-- PMM

Re: [Qemu-devel] [PATCH 01/29] hw/ide/ahci.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

On 2015/5/28 20:16, Peter Maydell wrote:
> On 28 May 2015 at 13:08, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > valgrind complains about:
>> > ==23381== 8 bytes in 1 blocks are definitely lost in loss record 438 of 2,785
>> > ==23381==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>> > ==23381==    by 0x35478F: malloc_and_trace (vl.c:2556)
>> > ==23381==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
>> > ==23381==    by 0x3ED98B: qemu_extend_irqs (irq.c:55)
>> > ==23381==    by 0x3EDA17: qemu_allocate_irqs (irq.c:64)
>> > ==23381==    by 0x43D767: ahci_init (ahci.c:1356)
>> > ==23381==    by 0x43DAC5: sysbus_ahci_realize (ahci.c:1520)
>> > ==23381==    by 0x3EA4CC: device_set_realized (qdev.c:1058)
>> > ==23381==    by 0x516CD2: property_set_bool (object.c:1514)
>> > ==23381==    by 0x5155CC: object_property_set (object.c:837)
>> > ==23381==    by 0x5178EE: object_property_set_qobject (qom-qobject.c:24)
>> > ==23381==    by 0x51583B: object_property_set_bool (object.c:905)
>> >
>> > Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> >  hw/ide/ahci.c | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
>> > index 9e5d862..4702a05 100644
>> > --- a/hw/ide/ahci.c
>> > +++ b/hw/ide/ahci.c
>> > @@ -1367,6 +1367,7 @@ void ahci_init(AHCIState *s, DeviceState *qdev, AddressSpace *as, int ports)
>> >          ad->port.dma->ops = &ahci_dma_ops;
>> >          ide_register_restart_cb(&ad->port);
>> >      }
>> > +    g_free(irqs);
>> >  }
> Freeing the return value of qemu_allocate_irqs()
> directly rather than using qemu_free_irqs() looks
> dubious to me.

qemu_free_irqs() will free the return value self of qemu_allocate_irqs()
and also will free all the contents of this array while some of them are
still in use.

-- 
Shannon

Re: [Qemu-devel] [PATCH 01/29] hw/ide/ahci.c: Fix memory leak spotted by valgrind

[Peter Maydell]

On 28 May 2015 at 13:24, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>
>
> On 2015/5/28 20:16, Peter Maydell wrote:
>> On 28 May 2015 at 13:08, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>>> > --- a/hw/ide/ahci.c
>>> > +++ b/hw/ide/ahci.c
>>> > @@ -1367,6 +1367,7 @@ void ahci_init(AHCIState *s, DeviceState *qdev, AddressSpace *as, int ports)
>>> >          ad->port.dma->ops = &ahci_dma_ops;
>>> >          ide_register_restart_cb(&ad->port);
>>> >      }
>>> > +    g_free(irqs);
>>> >  }
>> Freeing the return value of qemu_allocate_irqs()
>> directly rather than using qemu_free_irqs() looks
>> dubious to me.
>
> qemu_free_irqs() will free the return value self of qemu_allocate_irqs()
> and also will free all the contents of this array while some of them are
> still in use.

Yes, but you're still looking into the internal implementation
details of this API, which is what I'm suggesting is dubious.

For instance, in this case, why are we calling
qemu_allocate_irqs() in the first place, rather than
just calling qemu_allocate_irq() inside the for() loop in
ahci_init()?

If code wants to deal with the array of irqs as an array,
it should probably be saving the pointer somewhere in its
state struct and freeing the whole thing on deinit. If it
doesn't actually want an array of irqs (as here) it should
probably not be calling qemu_allocate_irqs() in the first
place.

thanks
-- PMM

[Qemu-devel] [PATCH 02/29] hw/ide/cmd646.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==23215== 32 bytes in 2 blocks are definitely lost in loss record 1,356 of 2,329
==23215==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23215==    by 0x27482B: malloc_and_trace (vl.c:2556)
==23215==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==23215==    by 0x2EEFD3: qemu_extend_irqs (irq.c:55)
==23215==    by 0x2EF05F: qemu_allocate_irqs (irq.c:64)
==23215==    by 0x305498: pci_cmd646_ide_realize (cmd646.c:364)
==23215==    by 0x33DB29: pci_qdev_realize (pci.c:1781)
==23215==    by 0x2EBB14: device_set_realized (qdev.c:1058)
==23215==    by 0x3C1A0E: property_set_bool (object.c:1514)
==23215==    by 0x3C0308: object_property_set (object.c:837)
==23215==    by 0x3C262A: object_property_set_qobject (qom-qobject.c:24)
==23215==    by 0x3C0577: object_property_set_bool (object.c:905)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/ide/cmd646.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index 66fb9d9..c9703e2 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -370,6 +370,7 @@ static void pci_cmd646_ide_realize(PCIDevice *dev, Error **errp)
         d->bmdma[i].bus = &d->bus[i];
         ide_register_restart_cb(&d->bus[i]);
     }
+    g_free(irq);
 
     vmstate_register(DEVICE(dev), 0, &vmstate_ide_pci, d);
     qemu_register_reset(cmd646_reset, d);
-- 
2.0.4

[Qemu-devel] [PATCH 03/29] hw/i386/pc: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==20308== 8 bytes in 1 blocks are definitely lost in loss record 622 of 3,474
==20308==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20308==    by 0x2EB687: malloc_and_trace (vl.c:2556)
==20308==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==20308==    by 0x377C57: qemu_extend_irqs (irq.c:55)
==20308==    by 0x377CE3: qemu_allocate_irqs (irq.c:64)
==20308==    by 0x2522B8: pc_allocate_cpu_irq (pc.c:1350)
==20308==    by 0x255AFF: pc_q35_init (pc_q35.c:233)
==20308==    by 0x2EFA52: main (vl.c:4249)

==16440== 8 bytes in 1 blocks are definitely lost in loss record 599 of 3,443
==16440==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16440==    by 0x2EB687: malloc_and_trace (vl.c:2556)
==16440==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==16440==    by 0x377C57: qemu_extend_irqs (irq.c:55)
==16440==    by 0x377CE3: qemu_allocate_irqs (irq.c:64)
==16440==    by 0x2522B8: pc_allocate_cpu_irq (pc.c:1350)
==16440==    by 0x2546B6: pc_init1 (pc_piix.c:223)
==16440==    by 0x254C16: pc_init_pci (pc_piix.c:311)
==16440==    by 0x2EFA52: main (vl.c:4249)

Since pc_allocate_cpu_irq only requests one irq, so let it just call
qemu_allocate_irq.

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/i386/pc.c         | 4 ++--
 hw/i386/pc_piix.c    | 4 +---
 hw/i386/pc_q35.c     | 4 +---
 include/hw/i386/pc.h | 2 +-
 4 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 769eb25..bb59a04 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1345,9 +1345,9 @@ FWCfgState *pc_memory_init(MachineState *machine,
     return fw_cfg;
 }
 
-qemu_irq *pc_allocate_cpu_irq(void)
+qemu_irq pc_allocate_cpu_irq(void)
 {
-    return qemu_allocate_irqs(pic_irq_request, NULL, 1);
+    return qemu_allocate_irq(pic_irq_request, NULL, 0);
 }
 
 DeviceState *pc_vga_init(ISABus *isa_bus, PCIBus *pci_bus)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 5e4c0b8..f2b6ebd 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -86,7 +86,6 @@ static void pc_init1(MachineState *machine,
     ISABus *isa_bus;
     PCII440FXState *i440fx_state;
     int piix3_devfn = -1;
-    qemu_irq *cpu_irq;
     qemu_irq *gsi;
     qemu_irq *i8259;
     qemu_irq smi_irq;
@@ -220,8 +219,7 @@ static void pc_init1(MachineState *machine,
     } else if (xen_enabled()) {
         i8259 = xen_interrupt_controller_init();
     } else {
-        cpu_irq = pc_allocate_cpu_irq();
-        i8259 = i8259_init(isa_bus, cpu_irq[0]);
+        i8259 = i8259_init(isa_bus, pc_allocate_cpu_irq());
     }
 
     for (i = 0; i < ISA_NUM_IRQS; i++) {
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index e67f2de..f2e3cf7 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -79,7 +79,6 @@ static void pc_q35_init(MachineState *machine)
     GSIState *gsi_state;
     ISABus *isa_bus;
     int pci_enabled = 1;
-    qemu_irq *cpu_irq;
     qemu_irq *gsi;
     qemu_irq *i8259;
     int i;
@@ -230,8 +229,7 @@ static void pc_q35_init(MachineState *machine)
     } else if (xen_enabled()) {
         i8259 = xen_interrupt_controller_init();
     } else {
-        cpu_irq = pc_allocate_cpu_irq();
-        i8259 = i8259_init(isa_bus, cpu_irq[0]);
+        i8259 = i8259_init(isa_bus, pc_allocate_cpu_irq());
     }
 
     for (i = 0; i < ISA_NUM_IRQS; i++) {
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 1b35168..6c6a45e 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -195,7 +195,7 @@ FWCfgState *pc_memory_init(MachineState *machine,
                            MemoryRegion *rom_memory,
                            MemoryRegion **ram_memory,
                            PcGuestInfo *guest_info);
-qemu_irq *pc_allocate_cpu_irq(void);
+qemu_irq pc_allocate_cpu_irq(void);
 DeviceState *pc_vga_init(ISABus *isa_bus, PCIBus *pci_bus);
 void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
                           ISADevice **rtc_state,
-- 
2.0.4

[Qemu-devel] [PATCH 04/29] hw/i386/pc_q35.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==25058== 128 bytes in 1 blocks are definitely lost in loss record 2,624 of 3,473
==25058==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==25058==    by 0x2EB657: malloc_and_trace (vl.c:2556)
==25058==    by 0x64C71F5: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
==25058==    by 0x64C7766: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.3600.3)
==25058==    by 0x3C62B2: i8259_init (i8259.c:475)
==25058==    by 0x255AF4: pc_q35_init (pc_q35.c:232)
==25058==    by 0x2EFA22: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/i386/pc_q35.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index f2e3cf7..1a311dc 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -235,6 +235,7 @@ static void pc_q35_init(MachineState *machine)
     for (i = 0; i < ISA_NUM_IRQS; i++) {
         gsi_state->i8259_irq[i] = i8259[i];
     }
+    g_free(i8259);
     if (pci_enabled) {
         ioapic_init_gsi(gsi_state, "q35");
     }
-- 
2.0.4

[Qemu-devel] [PATCH 05/29] hw/isa/lpc_ich9.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==25058== 8 bytes in 1 blocks are definitely lost in loss record 623 of 3,473
==25058==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==25058==    by 0x2EB657: malloc_and_trace (vl.c:2556)
==25058==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==25058==    by 0x377C27: qemu_extend_irqs (irq.c:55)
==25058==    by 0x377CB3: qemu_allocate_irqs (irq.c:64)
==25058==    by 0x222338: ich9_lpc_pm_init (lpc_ich9.c:365)
==25058==    by 0x255C42: pc_q35_init (pc_q35.c:255)
==25058==    by 0x2EFA22: main (vl.c:4249)

Since ich9_lpc_pm_init only requests one irq, so let it just call
qemu_allocate_irq.

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/isa/lpc_ich9.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index dba7585..144b210 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -360,11 +360,8 @@ static void ich9_set_sci(void *opaque, int irq_num, int level)
 void ich9_lpc_pm_init(PCIDevice *lpc_pci)
 {
     ICH9LPCState *lpc = ICH9_LPC_DEVICE(lpc_pci);
-    qemu_irq *sci_irq;
-
-    sci_irq = qemu_allocate_irqs(ich9_set_sci, lpc, 1);
-    ich9_pm_init(lpc_pci, &lpc->pm, sci_irq[0]);
 
+    ich9_pm_init(lpc_pci, &lpc->pm, qemu_allocate_irq(ich9_set_sci, lpc, 0));
     ich9_lpc_reset(&lpc->d.qdev);
 }
 
-- 
2.0.4

[Qemu-devel] [PATCH 06/29] hw/isa/i82378.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==32654== 8 bytes in 1 blocks are definitely lost in loss record 476 of 4,036
==32654==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32654==    by 0x336F47: malloc_and_trace (vl.c:2556)
==32654==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==32654==    by 0x3C093B: qemu_extend_irqs (irq.c:55)
==32654==    by 0x3C09C7: qemu_allocate_irqs (irq.c:64)
==32654==    by 0x3EA4CF: i82378_realize (i82378.c:92)
==32654==    by 0x420991: pci_qdev_realize (pci.c:1781)
==32654==    by 0x3BD47C: device_set_realized (qdev.c:1058)
==32654==    by 0x4A6516: property_set_bool (object.c:1514)
==32654==    by 0x4A4E10: object_property_set (object.c:837)
==32654==    by 0x4A7132: object_property_set_qobject (qom-qobject.c:24)
==32654==    by 0x4A507F: object_property_set_bool (object.c:905)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/isa/i82378.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/isa/i82378.c b/hw/isa/i82378.c
index 9da9dfc..48cc1ae 100644
--- a/hw/isa/i82378.c
+++ b/hw/isa/i82378.c
@@ -65,7 +65,7 @@ static void i82378_realize(PCIDevice *pci, Error **errp)
     uint8_t *pci_conf;
     ISABus *isabus;
     ISADevice *isa;
-    qemu_irq *out0_irq;
+    qemu_irq out0_irq;
 
     pci_conf = pci->config;
     pci_set_word(pci_conf + PCI_COMMAND,
@@ -89,10 +89,10 @@ static void i82378_realize(PCIDevice *pci, Error **errp)
      */
 
     /* Workaround the fact that i8259 is not qdev'ified... */
-    out0_irq = qemu_allocate_irqs(i82378_request_out0_irq, s, 1);
+    out0_irq = qemu_allocate_irq(i82378_request_out0_irq, s, 0);
 
     /* 2 82C59 (irq) */
-    s->i8259 = i8259_init(isabus, *out0_irq);
+    s->i8259 = i8259_init(isabus, out0_irq);
     isa_bus_irqs(isabus, s->i8259);
 
     /* 1 82C54 (pit) */
-- 
2.0.4

[Qemu-devel] [PATCH 07/29] hw/timer/arm_timer.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==16356== 32 bytes in 2 blocks are definitely lost in loss record 1,689 of 2,802
==16356==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16356==    by 0x35478F: malloc_and_trace (vl.c:2556)
==16356==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==16356==    by 0x3ED94B: qemu_extend_irqs (irq.c:55)
==16356==    by 0x3ED9D7: qemu_allocate_irqs (irq.c:64)
==16356==    by 0x4BA8D1: sp804_init (arm_timer.c:285)
==16356==    by 0x3EEE1D: sysbus_device_init (sysbus.c:204)
==16356==    by 0x3E838D: device_realize (qdev.c:247)
==16356==    by 0x3EA48C: device_set_realized (qdev.c:1058)
==16356==    by 0x516CD2: property_set_bool (object.c:1514)
==16356==    by 0x5155CC: object_property_set (object.c:837)
==16356==    by 0x5178EE: object_property_set_qobject (qom-qobject.c:24)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/timer/arm_timer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/timer/arm_timer.c b/hw/timer/arm_timer.c
index 1452910..6894f76 100644
--- a/hw/timer/arm_timer.c
+++ b/hw/timer/arm_timer.c
@@ -288,6 +288,7 @@ static int sp804_init(SysBusDevice *sbd)
     s->timer[1] = arm_timer_init(s->freq1);
     s->timer[0]->irq = qi[0];
     s->timer[1]->irq = qi[1];
+    g_free(qi);
     memory_region_init_io(&s->iomem, OBJECT(s), &sp804_ops, s,
                           "sp804", 0x1000);
     sysbus_init_mmio(sbd, &s->iomem);
-- 
2.0.4

[Qemu-devel] [PATCH 08/29] hw/intc/exynos4210_gic.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==17211== 784 (288 direct, 496 indirect) bytes in 4 blocks are definitely lost in loss record 3,018 of 3,201
==17211==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==17211==    by 0x35478F: malloc_and_trace (vl.c:2556)
==17211==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==17211==    by 0x5148DD: object_new_with_type (object.c:428)
==17211==    by 0x514939: object_new (object.c:439)
==17211==    by 0x3EDA38: qemu_allocate_irq (irq.c:71)
==17211==    by 0x3EDC2D: qemu_irq_split (irq.c:119)
==17211==    by 0x23D231: exynos4210_init_board_irqs (exynos4210_gic.c:216)
==17211==    by 0x293B00: exynos4210_init (exynos4210.c:250)
==17211==    by 0x27915A: exynos4_boards_init_common (exynos4_boards.c:127)
==17211==    by 0x2791D9: smdkc210_init (exynos4_boards.c:140)
==17211==    by 0x358B5A: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/intc/exynos4210_gic.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/hw/intc/exynos4210_gic.c b/hw/intc/exynos4210_gic.c
index 0590d5d..b2a4950 100644
--- a/hw/intc/exynos4210_gic.c
+++ b/hw/intc/exynos4210_gic.c
@@ -213,9 +213,6 @@ void exynos4210_init_board_irqs(Exynos4210Irq *s)
     uint32_t grp, bit, irq_id, n;
 
     for (n = 0; n < EXYNOS4210_MAX_EXT_COMBINER_IN_IRQ; n++) {
-        s->board_irqs[n] = qemu_irq_split(s->int_combiner_irq[n],
-                s->ext_combiner_irq[n]);
-
         irq_id = 0;
         if (n == EXYNOS4210_COMBINER_GET_IRQ_NUM(1, 4) ||
                 n == EXYNOS4210_COMBINER_GET_IRQ_NUM(12, 4)) {
@@ -230,8 +227,10 @@ void exynos4210_init_board_irqs(Exynos4210Irq *s)
         if (irq_id) {
             s->board_irqs[n] = qemu_irq_split(s->int_combiner_irq[n],
                     s->ext_gic_irq[irq_id-32]);
+        } else {
+            s->board_irqs[n] = qemu_irq_split(s->int_combiner_irq[n],
+                    s->ext_combiner_irq[n]);
         }
-
     }
     for (; n < EXYNOS4210_MAX_INT_COMBINER_IN_IRQ; n++) {
         /* these IDs are passed to Internal Combiner and External GIC */
-- 
2.0.4

[Qemu-devel] [PATCH 09/29] hw/sparc/leon3.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==21199== 2,468 (128 direct, 2,340 indirect) bytes in 1 blocks are definitely lost in loss record 1,094 of 1,125
==21199==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21199==    by 0x21B933: malloc_and_trace (vl.c:2556)
==21199==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==21199==    by 0x2700D3: qemu_extend_irqs (irq.c:55)
==21199==    by 0x27015F: qemu_allocate_irqs (irq.c:64)
==21199==    by 0x1ED14D: grlib_irqmp_create (grlib.h:64)
==21199==    by 0x1ED6B9: leon3_generic_hw_init (leon3.c:142)
==21199==    by 0x21FCFE: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/sparc/leon3.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/hw/sparc/leon3.c b/hw/sparc/leon3.c
index 7f5dcd6..c449b39 100644
--- a/hw/sparc/leon3.c
+++ b/hw/sparc/leon3.c
@@ -111,7 +111,7 @@ static void leon3_generic_hw_init(MachineState *machine)
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
     MemoryRegion *prom = g_new(MemoryRegion, 1);
-    int         ret;
+    int         ret, i;
     char       *filename;
     qemu_irq   *cpu_irqs = NULL;
     int         bios_size;
@@ -214,6 +214,13 @@ static void leon3_generic_hw_init(MachineState *machine)
     if (serial_hds[0]) {
         grlib_apbuart_create(0x80000100, serial_hds[0], cpu_irqs[3]);
     }
+
+    for (i = 0; i < MAX_PILS; i++) {
+        if ((i != 3) || (i != 6) || (i != 7)) {
+            qemu_free_irq(cpu_irqs[i]);
+        }
+    }
+    g_free(cpu_irqs);
 }
 
 static QEMUMachine leon3_generic_machine = {
-- 
2.0.4

[Qemu-devel] [PATCH 10/29] hw/sparc/sun4m.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==23693== 8 bytes in 1 blocks are definitely lost in loss record 424 of 2,014
==23693==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23693==    by 0x21B93F: malloc_and_trace (vl.c:2556)
==23693==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==23693==    by 0x2700DF: qemu_extend_irqs (irq.c:55)
==23693==    by 0x27016B: qemu_allocate_irqs (irq.c:64)
==23693==    by 0x1EC7DE: sun4m_hw_init (sun4m.c:1027)
==23693==    by 0x1ECE17: ss5_init (sun4m.c:1374)
==23693==    by 0x21FD0A: main (vl.c:4249)
==23693==
==23693==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23693==    by 0x21B93F: malloc_and_trace (vl.c:2556)
==23693==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==23693==    by 0x2700DF: qemu_extend_irqs (irq.c:55)
==23693==    by 0x27016B: qemu_allocate_irqs (irq.c:64)
==23693==    by 0x1EC074: cpu_devinit (sun4m.c:882)
==23693==    by 0x1EC13A: sun4m_hw_init (sun4m.c:911)
==23693==    by 0x1ECE17: ss5_init (sun4m.c:1374)
==23693==    by 0x21FD0A: main (vl.c:4249)
==23693==
==23693== 1,920 bytes in 15 blocks are definitely lost in loss record 1,952 of 2,014
==23693==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23693==    by 0x21B93F: malloc_and_trace (vl.c:2556)
==23693==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==23693==    by 0x2700DF: qemu_extend_irqs (irq.c:55)
==23693==    by 0x27016B: qemu_allocate_irqs (irq.c:64)
==23693==    by 0x1EC179: sun4m_hw_init (sun4m.c:915)
==23693==    by 0x1ECE17: ss5_init (sun4m.c:1374)
==23693==    by 0x21FD0A: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/sparc/sun4m.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c
index a69bf2d..3d5707b 100644
--- a/hw/sparc/sun4m.c
+++ b/hw/sparc/sun4m.c
@@ -897,7 +897,6 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef,
         espdma_irq, ledma_irq;
     qemu_irq esp_reset, dma_enable;
     qemu_irq fdc_tc;
-    qemu_irq *cpu_halt;
     unsigned long kernel_size;
     DriveInfo *fd[MAX_FD];
     FWCfgState *fw_cfg;
@@ -928,6 +927,10 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef,
                                        hwdef->intctl_base + 0x10000ULL,
                                        cpu_irqs);
 
+    for (i = 0; i < MAX_CPUS; i++) {
+        g_free(cpu_irqs[i]);
+    }
+
     for (i = 0; i < 32; i++) {
         slavio_irq[i] = qdev_get_gpio_in(slavio_intctl, i);
     }
@@ -1024,9 +1027,8 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef,
     escc_init(hwdef->serial_base, slavio_irq[15], slavio_irq[15],
               serial_hds[0], serial_hds[1], ESCC_CLOCK, 1);
 
-    cpu_halt = qemu_allocate_irqs(cpu_halt_signal, NULL, 1);
     if (hwdef->apc_base) {
-        apc_init(hwdef->apc_base, cpu_halt[0]);
+        apc_init(hwdef->apc_base, qemu_allocate_irq(cpu_halt_signal, NULL, 0));
     }
 
     if (hwdef->fd_base) {
@@ -1036,7 +1038,7 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef,
         sun4m_fdctrl_init(slavio_irq[22], hwdef->fd_base, fd,
                           &fdc_tc);
     } else {
-        fdc_tc = *qemu_allocate_irqs(dummy_fdc_tc, NULL, 1);
+        fdc_tc = qemu_allocate_irq(dummy_fdc_tc, NULL, 0);
     }
 
     slavio_misc_init(hwdef->slavio_base, hwdef->aux1_base, hwdef->aux2_base,
-- 
2.0.4

[Qemu-devel] [PATCH 11/29] hw/ppc/mac_oldworld.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==12412== 8 bytes in 1 blocks are definitely lost in loss record 448 of 3,760
==12412==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==12412==    by 0x336F37: malloc_and_trace (vl.c:2556)
==12412==    by 0x64C71F5: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
==12412==    by 0x64C7766: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.3600.3)
==12412==    by 0x26D448: ppc_heathrow_init (mac_oldworld.c:238)
==12412==    by 0x33B302: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/ppc/mac_oldworld.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index f26133d..f66b8aa 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -263,6 +263,7 @@ static void ppc_heathrow_init(MachineState *machine)
         hw_error("Only 6xx bus is supported on heathrow machine\n");
     }
     pic = heathrow_pic_init(&pic_mem, 1, heathrow_irqs);
+    g_free(heathrow_irqs);
     pci_bus = pci_grackle_init(0xfec00000, pic,
                                get_system_memory(),
                                get_system_io());
-- 
2.0.4

[Qemu-devel] [PATCH 12/29] hw/ppc/ppc440_bamboo.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==6366== 4,936 (256 direct, 4,680 indirect) bytes in 1 blocks are definitely lost in loss record 3,245 of 3,271
==6366==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==6366==    by 0x336F47: malloc_and_trace (vl.c:2556)
==6366==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==6366==    by 0x3C093B: qemu_extend_irqs (irq.c:55)
==6366==    by 0x3C09C7: qemu_allocate_irqs (irq.c:64)
==6366==    by 0x265091: ppcuic_init (ppc4xx_devs.c:317)
==6366==    by 0x26A90A: bamboo_init (ppc440_bamboo.c:205)
==6366==    by 0x33B312: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/ppc/ppc440_bamboo.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index 778970a..23b091f 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -235,13 +235,28 @@ static void bamboo_init(MachineState *machine)
         serial_mm_init(address_space_mem, 0xef600300, 0, pic[0],
                        PPC_SERIAL_MM_BAUDBASE, serial_hds[0],
                        DEVICE_BIG_ENDIAN);
+    } else {
+        qemu_free_irq(pic[0]);
     }
     if (serial_hds[1] != NULL) {
         serial_mm_init(address_space_mem, 0xef600400, 0, pic[1],
                        PPC_SERIAL_MM_BAUDBASE, serial_hds[1],
                        DEVICE_BIG_ENDIAN);
+    } else {
+        qemu_free_irq(pic[1]);
     }
 
+    for (i = 2; i < 14; i++) {
+        qemu_free_irq(pic[i]);
+    }
+    for (i = 15; i < 25; i++) {
+        qemu_free_irq(pic[i]);
+    }
+    for (i = 29; i < 32; i++) {
+        qemu_free_irq(pic[i]);
+    }
+    g_free(pic);
+
     if (pcibus) {
         /* Register network interfaces. */
         for (i = 0; i < nb_nics; i++) {
-- 
2.0.4

[Qemu-devel] [PATCH 13/29] hw/ppc/prep.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==22156== 8 bytes in 1 blocks are definitely lost in loss record 469 of 3,966
==22156==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==22156==    by 0x337033: malloc_and_trace (vl.c:2556)
==22156==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==22156==    by 0x3C0A27: qemu_extend_irqs (irq.c:55)
==22156==    by 0x3C0AB3: qemu_allocate_irqs (irq.c:64)
==22156==    by 0x26C792: ppc_prep_init (prep.c:628)
==22156==    by 0x33B3FE: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/ppc/prep.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 7f52662..310fa71 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -528,7 +528,7 @@ static void ppc_prep_init(MachineState *machine)
     PCIDevice *pci;
     ISABus *isa_bus;
     ISADevice *isa;
-    qemu_irq *cpu_exit_irq;
+    qemu_irq cpu_exit_irq;
     int ppc_boot_device;
     DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
 
@@ -625,11 +625,11 @@ static void ppc_prep_init(MachineState *machine)
 
     /* PCI -> ISA bridge */
     pci = pci_create_simple(pci_bus, PCI_DEVFN(1, 0), "i82378");
-    cpu_exit_irq = qemu_allocate_irqs(cpu_request_exit, NULL, 1);
+    cpu_exit_irq = qemu_allocate_irq(cpu_request_exit, NULL, 0);
     cpu = POWERPC_CPU(first_cpu);
     qdev_connect_gpio_out(&pci->qdev, 0,
                           cpu->env.irq_inputs[PPC6xx_INPUT_INT]);
-    qdev_connect_gpio_out(&pci->qdev, 1, *cpu_exit_irq);
+    qdev_connect_gpio_out(&pci->qdev, 1, cpu_exit_irq);
     sysbus_connect_irq(&pcihost->busdev, 0, qdev_get_gpio_in(&pci->qdev, 9));
     sysbus_connect_irq(&pcihost->busdev, 1, qdev_get_gpio_in(&pci->qdev, 11));
     sysbus_connect_irq(&pcihost->busdev, 2, qdev_get_gpio_in(&pci->qdev, 9));
-- 
2.0.4

[Qemu-devel] [PATCH 14/29] hw/mips/mips_int.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==24666== 64 bytes in 1 blocks are definitely lost in loss record 1,564 of 2,346
==24666==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24666==    by 0x2F5B8B: malloc_and_trace (vl.c:2556)
==24666==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==24666==    by 0x3842F7: qemu_extend_irqs (irq.c:55)
==24666==    by 0x384383: qemu_allocate_irqs (irq.c:64)
==24666==    by 0x244186: cpu_mips_irq_init_cpu (mips_int.c:65)
==24666==    by 0x244E88: mips_fulong2e_init (mips_fulong2e.c:345)
==24666==    by 0x2F9F56: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/mips/mips_int.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/mips/mips_int.c b/hw/mips/mips_int.c
index d740046..56b43da 100644
--- a/hw/mips/mips_int.c
+++ b/hw/mips/mips_int.c
@@ -66,6 +66,7 @@ void cpu_mips_irq_init_cpu(CPUMIPSState *env)
     for (i = 0; i < 8; i++) {
         env->irq[i] = qi[i];
     }
+    g_free(qi);
 }
 
 void cpu_mips_soft_irq(CPUMIPSState *env, int irq, int level)
-- 
2.0.4

[Qemu-devel] [PATCH 15/29] hw/mips/mips_jazz.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==28487== 1,568 (128 direct, 1,440 indirect) bytes in 1 blocks are definitely lost in loss record 2,160 of 2,212
==28487==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28487==    by 0x2F5B97: malloc_and_trace (vl.c:2556)
==28487==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==28487==    by 0x384303: qemu_extend_irqs (irq.c:55)
==28487==    by 0x38438F: qemu_allocate_irqs (irq.c:64)
==28487==    by 0x3B81DD: rc4030_init (rc4030.c:806)
==28487==    by 0x240151: mips_jazz_init (mips_jazz.c:221)
==28487==    by 0x240898: mips_magnum_init (mips_jazz.c:341)
==28487==    by 0x2F9F62: main (vl.c:4249)

==28487== 32 bytes in 1 blocks are definitely lost in loss record 1,359 of 2,212
==28487==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28487==    by 0x2F5B97: malloc_and_trace (vl.c:2556)
==28487==    by 0x64C71F5: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
==28487==    by 0x64C7766: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.3600.3)
==28487==    by 0x3B8132: rc4030_allocate_dmas (rc4030.c:787)
==28487==    by 0x3B81F5: rc4030_init (rc4030.c:807)
==28487==    by 0x240151: mips_jazz_init (mips_jazz.c:221)
==28487==    by 0x240898: mips_magnum_init (mips_jazz.c:341)
==28487==    by 0x2F9F62: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/dma/rc4030.c     |  2 +-
 hw/mips/mips_jazz.c | 15 ++++++++++++++-
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/hw/dma/rc4030.c b/hw/dma/rc4030.c
index af26632..9b42aab 100644
--- a/hw/dma/rc4030.c
+++ b/hw/dma/rc4030.c
@@ -803,7 +803,7 @@ void *rc4030_init(qemu_irq timer, qemu_irq jazz_bus,
 
     s = g_malloc0(sizeof(rc4030State));
 
-    *irqs = qemu_allocate_irqs(rc4030_irq_jazz_request, s, 16);
+    *irqs = qemu_allocate_irqs(rc4030_irq_jazz_request, s, 10);
     *dmas = rc4030_allocate_dmas(s, 4);
 
     s->periodic_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, rc4030_periodic_timer, s);
diff --git a/hw/mips/mips_jazz.c b/hw/mips/mips_jazz.c
index 2c153e0..cd26f60 100644
--- a/hw/mips/mips_jazz.c
+++ b/hw/mips/mips_jazz.c
@@ -261,8 +261,10 @@ static void mips_jazz_init(MachineState *machine,
         break;
     case JAZZ_PICA61:
         isa_vga_mm_init(0x40000000, 0x60000000, 0, get_system_memory());
+        qemu_free_irq(rc4030[3]);
         break;
     default:
+        qemu_free_irq(rc4030[3]);
         break;
     }
 
@@ -288,6 +290,7 @@ static void mips_jazz_init(MachineState *machine,
     esp_init(0x80002000, 0,
              rc4030_dma_read, rc4030_dma_write, dmas[0],
              rc4030[5], &esp_reset, &dma_enable);
+    g_free(dmas);
 
     /* Floppy */
     if (drive_get_max_bus(IF_FLOPPY) >= MAX_FD) {
@@ -312,18 +315,28 @@ static void mips_jazz_init(MachineState *machine,
     if (serial_hds[0]) {
         serial_mm_init(address_space, 0x80006000, 0, rc4030[8], 8000000/16,
                        serial_hds[0], DEVICE_NATIVE_ENDIAN);
+    } else {
+        qemu_free_irq(rc4030[8]);
     }
+
     if (serial_hds[1]) {
         serial_mm_init(address_space, 0x80007000, 0, rc4030[9], 8000000/16,
                        serial_hds[1], DEVICE_NATIVE_ENDIAN);
+    } else {
+        qemu_free_irq(rc4030[9]);
     }
 
     /* Parallel port */
-    if (parallel_hds[0])
+    if (parallel_hds[0]) {
         parallel_mm_init(address_space, 0x80008000, 0, rc4030[0],
                          parallel_hds[0]);
+    } else {
+        qemu_free_irq(rc4030[0]);
+    }
 
     /* FIXME: missing Jazz sound at 0x8000c000, rc4030[2] */
+    qemu_free_irq(rc4030[2]);
+    g_free(rc4030);
 
     /* NVRAM */
     dev = qdev_create(NULL, "ds1225y");
-- 
2.0.4

[Qemu-devel] [PATCH 16/29] hw/lm32/lm32_boards.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==8662== 8 bytes in 1 blocks are definitely lost in loss record 228 of 1,108
==8662==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8662==    by 0x1E77EB: malloc_and_trace (vl.c:2556)
==8662==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==8662==    by 0x238C47: qemu_extend_irqs (irq.c:55)
==8662==    by 0x238CD3: qemu_allocate_irqs (irq.c:64)
==8662==    by 0x1C32FC: lm32_evr_init (lm32_boards.c:126)
==8662==    by 0x1EBBB6: main (vl.c:4249)

==12877== 8 bytes in 1 blocks are definitely lost in loss record 209 of 1,042
==12877==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==12877==    by 0x1E77E7: malloc_and_trace (vl.c:2556)
==12877==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==12877==    by 0x238C43: qemu_extend_irqs (irq.c:55)
==12877==    by 0x238CCF: qemu_allocate_irqs (irq.c:64)
==12877==    by 0x1C384E: lm32_uclinux_init (lm32_boards.c:228)
==12877==    by 0x1EBBB2: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/lm32/lm32_boards.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/lm32/lm32_boards.c b/hw/lm32/lm32_boards.c
index 14d0efc..cf37997 100644
--- a/hw/lm32/lm32_boards.c
+++ b/hw/lm32/lm32_boards.c
@@ -78,7 +78,7 @@ static void lm32_evr_init(MachineState *machine)
     DriveInfo *dinfo;
     MemoryRegion *address_space_mem =  get_system_memory();
     MemoryRegion *phys_ram = g_new(MemoryRegion, 1);
-    qemu_irq *cpu_irq, irq[32];
+    qemu_irq cpu_irq, irq[32];
     ResetInfo *reset_info;
     int i;
 
@@ -123,8 +123,8 @@ static void lm32_evr_init(MachineState *machine)
                           1, 2, 0x01, 0x7e, 0x43, 0x00, 0x555, 0x2aa, 1);
 
     /* create irq lines */
-    cpu_irq = qemu_allocate_irqs(cpu_irq_handler, cpu, 1);
-    env->pic_state = lm32_pic_init(*cpu_irq);
+    cpu_irq = qemu_allocate_irq(cpu_irq_handler, cpu, 0);
+    env->pic_state = lm32_pic_init(cpu_irq);
     for (i = 0; i < 32; i++) {
         irq[i] = qdev_get_gpio_in(env->pic_state, i);
     }
@@ -173,7 +173,7 @@ static void lm32_uclinux_init(MachineState *machine)
     DriveInfo *dinfo;
     MemoryRegion *address_space_mem =  get_system_memory();
     MemoryRegion *phys_ram = g_new(MemoryRegion, 1);
-    qemu_irq *cpu_irq, irq[32];
+    qemu_irq cpu_irq, irq[32];
     HWSetup *hw;
     ResetInfo *reset_info;
     int i;
@@ -225,8 +225,8 @@ static void lm32_uclinux_init(MachineState *machine)
                           1, 2, 0x01, 0x7e, 0x43, 0x00, 0x555, 0x2aa, 1);
 
     /* create irq lines */
-    cpu_irq = qemu_allocate_irqs(cpu_irq_handler, env, 1);
-    env->pic_state = lm32_pic_init(*cpu_irq);
+    cpu_irq = qemu_allocate_irq(cpu_irq_handler, env, 0);
+    env->pic_state = lm32_pic_init(cpu_irq);
     for (i = 0; i < 32; i++) {
         irq[i] = qdev_get_gpio_in(env->pic_state, i);
     }
-- 
2.0.4

[Qemu-devel] [PATCH 17/29] hw/lm32/milkymist.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==20652== 8 bytes in 1 blocks are definitely lost in loss record 252 of 1,314
==20652==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20652==    by 0x1E77E7: malloc_and_trace (vl.c:2556)
==20652==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==20652==    by 0x238C43: qemu_extend_irqs (irq.c:55)
==20652==    by 0x238CCF: qemu_allocate_irqs (irq.c:64)
==20652==    by 0x1C49AD: milkymist_init (milkymist.c:133)
==20652==    by 0x1EBBB2: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/lm32/milkymist.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/lm32/milkymist.c b/hw/lm32/milkymist.c
index e0cec7d..4b8284f 100644
--- a/hw/lm32/milkymist.c
+++ b/hw/lm32/milkymist.c
@@ -86,7 +86,7 @@ milkymist_init(MachineState *machine)
     DriveInfo *dinfo;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *phys_sdram = g_new(MemoryRegion, 1);
-    qemu_irq irq[32], *cpu_irq;
+    qemu_irq irq[32], cpu_irq;
     int i;
     char *bios_filename;
     ResetInfo *reset_info;
@@ -130,8 +130,8 @@ milkymist_init(MachineState *machine)
                           2, 0x00, 0x89, 0x00, 0x1d, 1);
 
     /* create irq lines */
-    cpu_irq = qemu_allocate_irqs(cpu_irq_handler, cpu, 1);
-    env->pic_state = lm32_pic_init(*cpu_irq);
+    cpu_irq = qemu_allocate_irq(cpu_irq_handler, cpu, 0);
+    env->pic_state = lm32_pic_init(cpu_irq);
     for (i = 0; i < 32; i++) {
         irq[i] = qdev_get_gpio_in(env->pic_state, i);
     }
-- 
2.0.4

[Qemu-devel] [PATCH 18/29] hw/m68k/mcf5206.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==16659== 1,912 (112 direct, 1,800 indirect) bytes in 1 blocks are definitely lost in loss record 1,254 of 1,285
==16659==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16659==    by 0x251F97: malloc_and_trace (vl.c:2556)
==16659==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==16659==    by 0x2C994F: qemu_extend_irqs (irq.c:55)
==16659==    by 0x2C99DB: qemu_allocate_irqs (irq.c:64)
==16659==    by 0x225878: mcf5206_init (mcf5206.c:539)
==16659==    by 0x223991: an5206_init (an5206.c:61)
==16659==    by 0x256362: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/m68k/mcf5206.c     | 10 ++++++++--
 include/hw/m68k/mcf.h |  3 +--
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/hw/m68k/mcf5206.c b/hw/m68k/mcf5206.c
index 1727a46..67390e6 100644
--- a/hw/m68k/mcf5206.c
+++ b/hw/m68k/mcf5206.c
@@ -525,10 +525,11 @@ static const MemoryRegionOps m5206_mbar_ops = {
     .endianness = DEVICE_NATIVE_ENDIAN,
 };
 
-qemu_irq *mcf5206_init(MemoryRegion *sysmem, uint32_t base, M68kCPU *cpu)
+void mcf5206_init(MemoryRegion *sysmem, uint32_t base, M68kCPU *cpu)
 {
     m5206_mbar_state *s;
     qemu_irq *pic;
+    int i;
 
     s = (m5206_mbar_state *)g_malloc0(sizeof(m5206_mbar_state));
 
@@ -543,6 +544,11 @@ qemu_irq *mcf5206_init(MemoryRegion *sysmem, uint32_t base, M68kCPU *cpu)
     s->uart[1] = mcf_uart_init(pic[13], serial_hds[1]);
     s->cpu = cpu;
 
+    for (i = 0; i < 9; i++) {
+        qemu_free_irq(pic[i]);
+    }
+    qemu_free_irq(pic[11]);
+    g_free(pic);
+
     m5206_mbar_reset(s);
-    return pic;
 }
diff --git a/include/hw/m68k/mcf.h b/include/hw/m68k/mcf.h
index fbc8dc2..9bf4f5f 100644
--- a/include/hw/m68k/mcf.h
+++ b/include/hw/m68k/mcf.h
@@ -24,7 +24,6 @@ void mcf_fec_init(struct MemoryRegion *sysmem, NICInfo *nd,
                   hwaddr base, qemu_irq *irq);
 
 /* mcf5206.c */
-qemu_irq *mcf5206_init(struct MemoryRegion *sysmem,
-                       uint32_t base, M68kCPU *cpu);
+void mcf5206_init(struct MemoryRegion *sysmem, uint32_t base, M68kCPU *cpu);
 
 #endif
-- 
2.0.4

[Qemu-devel] [PATCH 19/29] hw/openrisc/pic_cpu.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==2442== 256 bytes in 1 blocks are definitely lost in loss record 803 of 952
==2442==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==2442==    by 0x1E22A7: malloc_and_trace (vl.c:2556)
==2442==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==2442==    by 0x22FF53: qemu_extend_irqs (irq.c:55)
==2442==    by 0x22FFDF: qemu_allocate_irqs (irq.c:64)
==2442==    by 0x1BCBBE: cpu_openrisc_pic_init (pic_cpu.c:55)
==2442==    by 0x1BD3BA: openrisc_sim_init (openrisc_sim.c:121)
==2442==    by 0x1E6672: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/openrisc/pic_cpu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/openrisc/pic_cpu.c b/hw/openrisc/pic_cpu.c
index 2af1d60..8347f5c 100644
--- a/hw/openrisc/pic_cpu.c
+++ b/hw/openrisc/pic_cpu.c
@@ -57,4 +57,5 @@ void cpu_openrisc_pic_init(OpenRISCCPU *cpu)
     for (i = 0; i < NR_IRQS; i++) {
         cpu->env.irq[i] = qi[i];
     }
+    g_free(qi);
 }
-- 
2.0.4

[Qemu-devel] [PATCH 20/29] hw/unicore32/puv3.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==26001== 8 bytes in 1 blocks are definitely lost in loss record 234 of 1,038
==26001==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26001==    by 0x1E1483: malloc_and_trace (vl.c:2556)
==26001==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==26001==    by 0x22D17B: qemu_extend_irqs (irq.c:55)
==26001==    by 0x22D207: qemu_allocate_irqs (irq.c:64)
==26001==    by 0x1BC56D: puv3_soc_init (puv3.c:49)
==26001==    by 0x1BC8B1: puv3_init (puv3.c:128)
==26001==    by 0x1E584E: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/unicore32/puv3.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/unicore32/puv3.c b/hw/unicore32/puv3.c
index cc9a21a..703e29d 100644
--- a/hw/unicore32/puv3.c
+++ b/hw/unicore32/puv3.c
@@ -40,15 +40,15 @@ static void puv3_intc_cpu_handler(void *opaque, int irq, int level)
 
 static void puv3_soc_init(CPUUniCore32State *env)
 {
-    qemu_irq *cpu_intc, irqs[PUV3_IRQS_NR];
+    qemu_irq cpu_intc, irqs[PUV3_IRQS_NR];
     DeviceState *dev;
     MemoryRegion *i8042 = g_new(MemoryRegion, 1);
     int i;
 
     /* Initialize interrupt controller */
-    cpu_intc = qemu_allocate_irqs(puv3_intc_cpu_handler,
-                                  uc32_env_get_cpu(env), 1);
-    dev = sysbus_create_simple("puv3_intc", PUV3_INTC_BASE, *cpu_intc);
+    cpu_intc = qemu_allocate_irq(puv3_intc_cpu_handler,
+                                 uc32_env_get_cpu(env), 0);
+    dev = sysbus_create_simple("puv3_intc", PUV3_INTC_BASE, cpu_intc);
     for (i = 0; i < PUV3_IRQS_NR; i++) {
         irqs[i] = qdev_get_gpio_in(dev, i);
     }
-- 
2.0.4

[Qemu-devel] [PATCH 21/29] hw/sh4/r2d.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==29844== 1,364 (104 direct, 1,260 indirect) bytes in 1 blocks are definitely lost in loss record 2,143 of 2,205
==29844==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==29844==    by 0x25096F: malloc_and_trace (vl.c:2556)
==29844==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==29844==    by 0x2C7CDB: qemu_extend_irqs (irq.c:55)
==29844==    by 0x2C7D67: qemu_allocate_irqs (irq.c:64)
==29844==    by 0x2167ED: r2d_fpga_init (r2d.c:191)
==29844==    by 0x2169CC: r2d_init (r2d.c:263)
==29844==    by 0x254D3A: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/sh4/r2d.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/hw/sh4/r2d.c b/hw/sh4/r2d.c
index 4221060..594c733 100644
--- a/hw/sh4/r2d.c
+++ b/hw/sh4/r2d.c
@@ -287,6 +287,16 @@ static void r2d_init(MachineState *machine)
     sysbus_mmio_map(busdev, 1, 0x1400080c);
     mmio_ide_init_drives(dev, dinfo, NULL);
 
+    /* free unused irq */
+    qemu_free_irq(irq[CF_CD]);
+    qemu_free_irq(irq[KEY]);
+    qemu_free_irq(irq[RTC_A]);
+    qemu_free_irq(irq[RTC_T]);
+    qemu_free_irq(irq[SDCARD]);
+    qemu_free_irq(irq[EXT]);
+    qemu_free_irq(irq[TP]);
+    g_free(irq);
+
     /* onboard flash memory */
     dinfo = drive_get(IF_PFLASH, 0, 0);
     pflash_cfi02_register(0x0, NULL, "r2d.flash", FLASH_SIZE,
-- 
2.0.4

Re: [Qemu-devel] [PATCH 21/29] hw/sh4/r2d.c: Fix memory leak spotted by valgrind

[Peter Maydell]

On 28 May 2015 at 13:08, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> valgrind complains about:
> ==29844== 1,364 (104 direct, 1,260 indirect) bytes in 1 blocks are definitely lost in loss record 2,143 of 2,205
> ==29844==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==29844==    by 0x25096F: malloc_and_trace (vl.c:2556)
> ==29844==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
> ==29844==    by 0x2C7CDB: qemu_extend_irqs (irq.c:55)
> ==29844==    by 0x2C7D67: qemu_allocate_irqs (irq.c:64)
> ==29844==    by 0x2167ED: r2d_fpga_init (r2d.c:191)
> ==29844==    by 0x2169CC: r2d_init (r2d.c:263)
> ==29844==    by 0x254D3A: main (vl.c:4249)
>
> Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  hw/sh4/r2d.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/hw/sh4/r2d.c b/hw/sh4/r2d.c
> index 4221060..594c733 100644
> --- a/hw/sh4/r2d.c
> +++ b/hw/sh4/r2d.c
> @@ -287,6 +287,16 @@ static void r2d_init(MachineState *machine)
>      sysbus_mmio_map(busdev, 1, 0x1400080c);
>      mmio_ide_init_drives(dev, dinfo, NULL);
>
> +    /* free unused irq */
> +    qemu_free_irq(irq[CF_CD]);
> +    qemu_free_irq(irq[KEY]);
> +    qemu_free_irq(irq[RTC_A]);
> +    qemu_free_irq(irq[RTC_T]);
> +    qemu_free_irq(irq[SDCARD]);
> +    qemu_free_irq(irq[EXT]);
> +    qemu_free_irq(irq[TP]);
> +    g_free(irq);
> +

Yuck. We should just save the irq pointer in some state structure
and g_free_irqs() it all in deinit.

-- PMM

Re: [Qemu-devel] [PATCH 21/29] hw/sh4/r2d.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

On 2015/5/28 20:46, Peter Maydell wrote:
> On 28 May 2015 at 13:08, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> >
>> > valgrind complains about:
>> > ==29844== 1,364 (104 direct, 1,260 indirect) bytes in 1 blocks are definitely lost in loss record 2,143 of 2,205
>> > ==29844==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>> > ==29844==    by 0x25096F: malloc_and_trace (vl.c:2556)
>> > ==29844==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
>> > ==29844==    by 0x2C7CDB: qemu_extend_irqs (irq.c:55)
>> > ==29844==    by 0x2C7D67: qemu_allocate_irqs (irq.c:64)
>> > ==29844==    by 0x2167ED: r2d_fpga_init (r2d.c:191)
>> > ==29844==    by 0x2169CC: r2d_init (r2d.c:263)
>> > ==29844==    by 0x254D3A: main (vl.c:4249)
>> >
>> > Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> >  hw/sh4/r2d.c | 10 ++++++++++
>> >  1 file changed, 10 insertions(+)
>> >
>> > diff --git a/hw/sh4/r2d.c b/hw/sh4/r2d.c
>> > index 4221060..594c733 100644
>> > --- a/hw/sh4/r2d.c
>> > +++ b/hw/sh4/r2d.c
>> > @@ -287,6 +287,16 @@ static void r2d_init(MachineState *machine)
>> >      sysbus_mmio_map(busdev, 1, 0x1400080c);
>> >      mmio_ide_init_drives(dev, dinfo, NULL);
>> >
>> > +    /* free unused irq */
>> > +    qemu_free_irq(irq[CF_CD]);
>> > +    qemu_free_irq(irq[KEY]);
>> > +    qemu_free_irq(irq[RTC_A]);
>> > +    qemu_free_irq(irq[RTC_T]);
>> > +    qemu_free_irq(irq[SDCARD]);
>> > +    qemu_free_irq(irq[EXT]);
>> > +    qemu_free_irq(irq[TP]);
>> > +    g_free(irq);
>> > +
> Yuck. We should just save the irq pointer in some state structure
> and g_free_irqs() it all in deinit.

Ok, will try to use this way for those which allocate a few irqs. But
the modifications for the ones which only allocate one irq are ok I
guess, I use qemu_allocate_irq to replace qemu_allocate_irqs.

-- 
Shannon

[Qemu-devel] [PATCH 22/29] hw/alpha/typhoon.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==7055== 8 bytes in 1 blocks are definitely lost in loss record 403 of 2,192
==7055==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7055==    by 0x24410F: malloc_and_trace (vl.c:2556)
==7055==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==7055==    by 0x2B7A8B: qemu_extend_irqs (irq.c:55)
==7055==    by 0x2B7B17: qemu_allocate_irqs (irq.c:64)
==7055==    by 0x2197CB: typhoon_init (typhoon.c:844)
==7055==    by 0x2178FD: clipper_init (dp264.c:73)
==7055==    by 0x2484DA: main (vl.c:4249)
==7055==
==7055== 8 bytes in 1 blocks are definitely lost in loss record 404 of 2,192
==7055==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7055==    by 0x24410F: malloc_and_trace (vl.c:2556)
==7055==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==7055==    by 0x2B7A8B: qemu_extend_irqs (irq.c:55)
==7055==    by 0x2B7B17: qemu_allocate_irqs (irq.c:64)
==7055==    by 0x219BA7: typhoon_init (typhoon.c:924)
==7055==    by 0x2178FD: clipper_init (dp264.c:73)
==7055==    by 0x2484DA: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/alpha/typhoon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/alpha/typhoon.c b/hw/alpha/typhoon.c
index 7df842d..3bb6d3d 100644
--- a/hw/alpha/typhoon.c
+++ b/hw/alpha/typhoon.c
@@ -841,7 +841,7 @@ PCIBus *typhoon_init(ram_addr_t ram_size, ISABus **isa_bus,
         }
     }
 
-    *p_rtc_irq = *qemu_allocate_irqs(typhoon_set_timer_irq, s, 1);
+    *p_rtc_irq = qemu_allocate_irq(typhoon_set_timer_irq, s, 0);
 
     /* Main memory region, 0x00.0000.0000.  Real hardware supports 32GB,
        but the address space hole reserved at this point is 8TB.  */
@@ -921,7 +921,7 @@ PCIBus *typhoon_init(ram_addr_t ram_size, ISABus **isa_bus,
         qemu_irq isa_pci_irq, *isa_irqs;
 
         *isa_bus = isa_bus_new(NULL, get_system_memory(), &s->pchip.reg_io);
-        isa_pci_irq = *qemu_allocate_irqs(typhoon_set_isa_irq, s, 1);
+        isa_pci_irq = qemu_allocate_irq(typhoon_set_isa_irq, s, 0);
         isa_irqs = i8259_init(*isa_bus, isa_pci_irq);
         isa_bus_irqs(*isa_bus, isa_irqs);
     }
-- 
2.0.4

[Qemu-devel] [PATCH 23/29] hw/arm/nseries.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==4835== 8 bytes in 1 blocks are definitely lost in loss record 509 of 3,278
==4835==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4835==    by 0x354793: malloc_and_trace (vl.c:2556)
==4835==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==4835==    by 0x3ED98F: qemu_extend_irqs (irq.c:55)
==4835==    by 0x3EDA1B: qemu_allocate_irqs (irq.c:64)
==4835==    by 0x280261: n8x0_gpio_setup (nseries.c:136)
==4835==    by 0x2830AB: n8x0_init (nseries.c:1337)
==4835==    by 0x2832D6: n800_init (nseries.c:1409)
==4835==    by 0x358B5E: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/arm/nseries.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/arm/nseries.c b/hw/arm/nseries.c
index d243159..2e392a9 100644
--- a/hw/arm/nseries.c
+++ b/hw/arm/nseries.c
@@ -133,8 +133,8 @@ static void n800_mmc_cs_cb(void *opaque, int line, int level)
 
 static void n8x0_gpio_setup(struct n800_s *s)
 {
-    qemu_irq *mmc_cs = qemu_allocate_irqs(n800_mmc_cs_cb, s->mpu->mmc, 1);
-    qdev_connect_gpio_out(s->mpu->gpio, N8X0_MMC_CS_GPIO, mmc_cs[0]);
+    qemu_irq mmc_cs = qemu_allocate_irq(n800_mmc_cs_cb, s->mpu->mmc, 0);
+    qdev_connect_gpio_out(s->mpu->gpio, N8X0_MMC_CS_GPIO, mmc_cs);
 
     qemu_irq_lower(qdev_get_gpio_in(s->mpu->gpio, N800_BAT_COVER_GPIO));
 }
-- 
2.0.4

[Qemu-devel] [PATCH 24/29] hw/arm/omap_sx1.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==19440== 248 bytes in 1 blocks are definitely lost in loss record 2,340 of 2,934
==19440==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==19440==    by 0x354793: malloc_and_trace (vl.c:2556)
==19440==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==19440==    by 0x2833DB: sx1_init (omap_sx1.c:106)
==19440==    by 0x2838C9: sx1_init_v2 (omap_sx1.c:217)
==19440==    by 0x358B5E: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/arm/omap_sx1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/omap_sx1.c b/hw/arm/omap_sx1.c
index 671e02c..4b0f7f9 100644
--- a/hw/arm/omap_sx1.c
+++ b/hw/arm/omap_sx1.c
@@ -103,7 +103,6 @@ static void sx1_init(MachineState *machine, const int version)
     struct omap_mpu_state_s *mpu;
     MemoryRegion *address_space = get_system_memory();
     MemoryRegion *flash = g_new(MemoryRegion, 1);
-    MemoryRegion *flash_1 = g_new(MemoryRegion, 1);
     MemoryRegion *cs = g_new(MemoryRegion, 4);
     static uint32_t cs0val = 0x00213090;
     static uint32_t cs1val = 0x00215070;
@@ -165,6 +164,7 @@ static void sx1_init(MachineState *machine, const int version)
 
     if ((version == 1) &&
             (dinfo = drive_get(IF_PFLASH, 0, fl_idx)) != NULL) {
+        MemoryRegion *flash_1 = g_new(MemoryRegion, 1);
         memory_region_init_ram(flash_1, NULL, "omap_sx1.flash1-0", flash1_size,
                                &error_abort);
         vmstate_register_ram_global(flash_1);
-- 
2.0.4

[Qemu-devel] [PATCH 25/29] hw/arm/palm.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==27206== 56 bytes in 1 blocks are definitely lost in loss record 2,000 of 3,127
==27206==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==27206==    by 0x35479F: malloc_and_trace (vl.c:2556)
==27206==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==27206==    by 0x3ED99B: qemu_extend_irqs (irq.c:55)
==27206==    by 0x3EDA27: qemu_allocate_irqs (irq.c:64)
==27206==    by 0x283C8B: palmte_gpio_setup (palm.c:168)
==27206==    by 0x2840FA: palmte_init (palm.c:239)
==27206==    by 0x358B6A: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/arm/palm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/palm.c b/hw/arm/palm.c
index 7f1cfb8..4e00695 100644
--- a/hw/arm/palm.c
+++ b/hw/arm/palm.c
@@ -173,6 +173,7 @@ static void palmte_gpio_setup(struct omap_mpu_state_s *cpu)
     qdev_connect_gpio_out(cpu->gpio, 13,			misc_gpio[4]);
     omap_mpuio_out_set(cpu->mpuio, 1,				misc_gpio[5]);
     omap_mpuio_out_set(cpu->mpuio, 3,				misc_gpio[6]);
+    g_free(misc_gpio);
 
     /* Reset some inputs to initial state.  */
     qemu_irq_lower(qdev_get_gpio_in(cpu->gpio, PALMTE_USBDETECT_GPIO));
-- 
2.0.4

[Qemu-devel] [PATCH 26/29] hw/arm/spitz.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==19832== 244 (64 direct, 180 indirect) bytes in 1 blocks are definitely lost in loss record 2,220 of 2,846
==19832==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==19832==    by 0x35479F: malloc_and_trace (vl.c:2556)
==19832==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==19832==    by 0x3ED99B: qemu_extend_irqs (irq.c:55)
==19832==    by 0x3EDA27: qemu_allocate_irqs (irq.c:64)
==19832==    by 0x2875CF: spitz_scoop_gpio_setup (spitz.c:818)
==19832==    by 0x2879FE: spitz_common_init (spitz.c:931)
==19832==    by 0x287AEF: spitz_init (spitz.c:957)
==19832==    by 0x358B6A: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/arm/spitz.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/arm/spitz.c b/hw/arm/spitz.c
index 5bf032a..6ff1825 100644
--- a/hw/arm/spitz.c
+++ b/hw/arm/spitz.c
@@ -815,7 +815,7 @@ static void spitz_out_switch(void *opaque, int line, int level)
 static void spitz_scoop_gpio_setup(PXA2xxState *cpu,
                 DeviceState *scp0, DeviceState *scp1)
 {
-    qemu_irq *outsignals = qemu_allocate_irqs(spitz_out_switch, cpu, 8);
+    qemu_irq *outsignals = qemu_allocate_irqs(spitz_out_switch, cpu, 7);
 
     qdev_connect_gpio_out(scp0, SPITZ_SCP_CHRG_ON, outsignals[0]);
     qdev_connect_gpio_out(scp0, SPITZ_SCP_JK_B, outsignals[1]);
@@ -825,9 +825,13 @@ static void spitz_scoop_gpio_setup(PXA2xxState *cpu,
     if (scp1) {
         qdev_connect_gpio_out(scp1, SPITZ_SCP2_BACKLIGHT_CONT, outsignals[4]);
         qdev_connect_gpio_out(scp1, SPITZ_SCP2_BACKLIGHT_ON, outsignals[5]);
+    } else {
+        qemu_free_irq(outsignals[4]);
+        qemu_free_irq(outsignals[5]);
     }
 
     qdev_connect_gpio_out(scp0, SPITZ_SCP_ADC_TEMP_ON, outsignals[6]);
+    g_free(outsignals);
 }
 
 #define SPITZ_GPIO_HSYNC		22
-- 
2.0.4

[Qemu-devel] [PATCH 27/29] hw/arm/tosa.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==3169== 32 bytes in 1 blocks are definitely lost in loss record 1,705 of 2,779
==3169==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3169==    by 0x3547D3: malloc_and_trace (vl.c:2556)
==3169==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==3169==    by 0x3ED9CF: qemu_extend_irqs (irq.c:55)
==3169==    by 0x3EDA5B: qemu_allocate_irqs (irq.c:64)
==3169==    by 0x28B2C3: tosa_gpio_setup (tosa.c:93)
==3169==    by 0x28B804: tosa_init (tosa.c:241)
==3169==    by 0x358B9E: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/arm/tosa.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/tosa.c b/hw/arm/tosa.c
index 73572eb..83eb991 100644
--- a/hw/arm/tosa.c
+++ b/hw/arm/tosa.c
@@ -112,6 +112,7 @@ static void tosa_gpio_setup(PXA2xxState *cpu,
     qdev_connect_gpio_out(scp1, TOSA_GPIO_NOTE_LED, outsignals[1]);
     qdev_connect_gpio_out(scp1, TOSA_GPIO_CHRG_ERR_LED, outsignals[2]);
     qdev_connect_gpio_out(scp1, TOSA_GPIO_WLAN_LED, outsignals[3]);
+    g_free(outsignals);
 
     qdev_connect_gpio_out(scp1, TOSA_GPIO_TC6393XB_L3V_ON, tc6393xb_l3v_get(tmio));
 
-- 
2.0.4

[Qemu-devel] [PATCH 28/29] hw/display/tc6393xb.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==3169== 8 bytes in 1 blocks are definitely lost in loss record 424 of 2,779
==3169==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3169==    by 0x3547D3: malloc_and_trace (vl.c:2556)
==3169==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==3169==    by 0x3ED9CF: qemu_extend_irqs (irq.c:55)
==3169==    by 0x3EDA5B: qemu_allocate_irqs (irq.c:64)
==3169==    by 0x426F74: tc6393xb_init (tc6393xb.c:574)
==3169==    by 0x28B7B4: tosa_init (tosa.c:235)
==3169==    by 0x358B9E: main (vl.c:4249)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/display/tc6393xb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/display/tc6393xb.c b/hw/display/tc6393xb.c
index 66b7ade..f5f3f3e 100644
--- a/hw/display/tc6393xb.c
+++ b/hw/display/tc6393xb.c
@@ -571,7 +571,7 @@ TC6393xbState *tc6393xb_init(MemoryRegion *sysmem, uint32_t base, qemu_irq irq)
     s->irq = irq;
     s->gpio_in = qemu_allocate_irqs(tc6393xb_gpio_set, s, TC6393XB_GPIOS);
 
-    s->l3v = *qemu_allocate_irqs(tc6393xb_l3v, s, 1);
+    s->l3v = qemu_allocate_irq(tc6393xb_l3v, s, 0);
     s->blanked = 1;
 
     s->sub_irqs = qemu_allocate_irqs(tc6393xb_sub_irq, s, TC6393XB_NR_IRQS);
-- 
2.0.4

[Qemu-devel] [PATCH 29/29] hw/s390x/sclpcpu.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

From: Shannon Zhao <shannon.zhao@linaro.org>

valgrind complains about:
==1413== 188 (8 direct, 180 indirect) bytes in 1 blocks are definitely lost in loss record 951 of 1,199
==1413==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1413==    by 0x262D8B: malloc_and_trace (vl.c:2556)
==1413==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==1413==    by 0x2C7ACF: qemu_extend_irqs (irq.c:55)
==1413==    by 0x2C7B5B: qemu_allocate_irqs (irq.c:64)
==1413==    by 0x2168F4: irq_cpu_hotplug_init (sclpcpu.c:84)
==1413==    by 0x21623F: event_realize (event-facility.c:385)
==1413==    by 0x2C4610: device_set_realized (qdev.c:1058)
==1413==    by 0x317DDA: property_set_bool (object.c:1514)
==1413==    by 0x3166D4: object_property_set (object.c:837)
==1413==    by 0x3189F6: object_property_set_qobject (qom-qobject.c:24)
==1413==    by 0x316943: object_property_set_bool (object.c:905)

Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 hw/s390x/sclpcpu.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/s390x/sclpcpu.c b/hw/s390x/sclpcpu.c
index 2fe8b5a..1090e2f 100644
--- a/hw/s390x/sclpcpu.c
+++ b/hw/s390x/sclpcpu.c
@@ -25,13 +25,13 @@ typedef struct ConfigMgtData {
     uint8_t event_qualifier;
 } QEMU_PACKED ConfigMgtData;
 
-static qemu_irq *irq_cpu_hotplug; /* Only used in this file */
+static qemu_irq irq_cpu_hotplug; /* Only used in this file */
 
 #define EVENT_QUAL_CPU_CHANGE  1
 
 void raise_irq_cpu_hotplug(void)
 {
-    qemu_irq_raise(*irq_cpu_hotplug);
+    qemu_irq_raise(irq_cpu_hotplug);
 }
 
 static unsigned int send_mask(void)
@@ -81,7 +81,10 @@ static void trigger_signal(void *opaque, int n, int level)
 
 static int irq_cpu_hotplug_init(SCLPEvent *event)
 {
-    irq_cpu_hotplug = qemu_allocate_irqs(trigger_signal, event, 1);
+    qemu_irq irq = qemu_allocate_irq(trigger_signal, event, 0);
+
+    irq_cpu_hotplug = irq;
+    qemu_free_irq(irq);
     return 0;
 }
 
-- 
2.0.4

Re: [Qemu-devel] [PATCH 29/29] hw/s390x/sclpcpu.c: Fix memory leak spotted by valgrind

[Cornelia Huck]

On Thu, 28 May 2015 20:08:52 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:

> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> valgrind complains about:
> ==1413== 188 (8 direct, 180 indirect) bytes in 1 blocks are definitely lost in loss record 951 of 1,199
> ==1413==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==1413==    by 0x262D8B: malloc_and_trace (vl.c:2556)
> ==1413==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
> ==1413==    by 0x2C7ACF: qemu_extend_irqs (irq.c:55)
> ==1413==    by 0x2C7B5B: qemu_allocate_irqs (irq.c:64)
> ==1413==    by 0x2168F4: irq_cpu_hotplug_init (sclpcpu.c:84)
> ==1413==    by 0x21623F: event_realize (event-facility.c:385)
> ==1413==    by 0x2C4610: device_set_realized (qdev.c:1058)
> ==1413==    by 0x317DDA: property_set_bool (object.c:1514)
> ==1413==    by 0x3166D4: object_property_set (object.c:837)
> ==1413==    by 0x3189F6: object_property_set_qobject (qom-qobject.c:24)
> ==1413==    by 0x316943: object_property_set_bool (object.c:905)
> 
> Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  hw/s390x/sclpcpu.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/s390x/sclpcpu.c b/hw/s390x/sclpcpu.c
> index 2fe8b5a..1090e2f 100644
> --- a/hw/s390x/sclpcpu.c
> +++ b/hw/s390x/sclpcpu.c
> @@ -25,13 +25,13 @@ typedef struct ConfigMgtData {
>      uint8_t event_qualifier;
>  } QEMU_PACKED ConfigMgtData;
> 
> -static qemu_irq *irq_cpu_hotplug; /* Only used in this file */
> +static qemu_irq irq_cpu_hotplug; /* Only used in this file */
> 
>  #define EVENT_QUAL_CPU_CHANGE  1
> 
>  void raise_irq_cpu_hotplug(void)
>  {
> -    qemu_irq_raise(*irq_cpu_hotplug);
> +    qemu_irq_raise(irq_cpu_hotplug);
>  }
> 
>  static unsigned int send_mask(void)
> @@ -81,7 +81,10 @@ static void trigger_signal(void *opaque, int n, int level)
> 
>  static int irq_cpu_hotplug_init(SCLPEvent *event)
>  {
> -    irq_cpu_hotplug = qemu_allocate_irqs(trigger_signal, event, 1);
> +    qemu_irq irq = qemu_allocate_irq(trigger_signal, event, 0);
> +
> +    irq_cpu_hotplug = irq;
> +    qemu_free_irq(irq);

This looks... odd. But then, the whole code structure here with its
global variable and its roundabout way of triggering the notification
looks weird. We'd probably be better off looking up the sclp event for
cpu hotplug and triggering the interrupt directly.

>      return 0;
>  }
> 

Re: [Qemu-devel] [PATCH 29/29] hw/s390x/sclpcpu.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

On 2015/5/28 21:11, Cornelia Huck wrote:
> On Thu, 28 May 2015 20:08:52 +0800
> Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> 
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> > 
>> > valgrind complains about:
>> > ==1413== 188 (8 direct, 180 indirect) bytes in 1 blocks are definitely lost in loss record 951 of 1,199
>> > ==1413==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>> > ==1413==    by 0x262D8B: malloc_and_trace (vl.c:2556)
>> > ==1413==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
>> > ==1413==    by 0x2C7ACF: qemu_extend_irqs (irq.c:55)
>> > ==1413==    by 0x2C7B5B: qemu_allocate_irqs (irq.c:64)
>> > ==1413==    by 0x2168F4: irq_cpu_hotplug_init (sclpcpu.c:84)
>> > ==1413==    by 0x21623F: event_realize (event-facility.c:385)
>> > ==1413==    by 0x2C4610: device_set_realized (qdev.c:1058)
>> > ==1413==    by 0x317DDA: property_set_bool (object.c:1514)
>> > ==1413==    by 0x3166D4: object_property_set (object.c:837)
>> > ==1413==    by 0x3189F6: object_property_set_qobject (qom-qobject.c:24)
>> > ==1413==    by 0x316943: object_property_set_bool (object.c:905)
>> > 
>> > Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> >  hw/s390x/sclpcpu.c | 9 ++++++---
>> >  1 file changed, 6 insertions(+), 3 deletions(-)
>> > 
>> > diff --git a/hw/s390x/sclpcpu.c b/hw/s390x/sclpcpu.c
>> > index 2fe8b5a..1090e2f 100644
>> > --- a/hw/s390x/sclpcpu.c
>> > +++ b/hw/s390x/sclpcpu.c
>> > @@ -25,13 +25,13 @@ typedef struct ConfigMgtData {
>> >      uint8_t event_qualifier;
>> >  } QEMU_PACKED ConfigMgtData;
>> > 
>> > -static qemu_irq *irq_cpu_hotplug; /* Only used in this file */
>> > +static qemu_irq irq_cpu_hotplug; /* Only used in this file */
>> > 
>> >  #define EVENT_QUAL_CPU_CHANGE  1
>> > 
>> >  void raise_irq_cpu_hotplug(void)
>> >  {
>> > -    qemu_irq_raise(*irq_cpu_hotplug);
>> > +    qemu_irq_raise(irq_cpu_hotplug);
>> >  }
>> > 
>> >  static unsigned int send_mask(void)
>> > @@ -81,7 +81,10 @@ static void trigger_signal(void *opaque, int n, int level)
>> > 
>> >  static int irq_cpu_hotplug_init(SCLPEvent *event)
>> >  {
>> > -    irq_cpu_hotplug = qemu_allocate_irqs(trigger_signal, event, 1);
>> > +    qemu_irq irq = qemu_allocate_irq(trigger_signal, event, 0);
>> > +
>> > +    irq_cpu_hotplug = irq;
>> > +    qemu_free_irq(irq);
> This looks... odd. But then, the whole code structure here with its
> global variable and its roundabout way of triggering the notification
> looks weird. We'd probably be better off looking up the sclp event for
> cpu hotplug and triggering the interrupt directly.
> 

Yeah, it's odd and　I don't find who calls raise_irq_cpu_hotplug().

-- 
Shannon

Re: [Qemu-devel] [PATCH 29/29] hw/s390x/sclpcpu.c: Fix memory leak spotted by valgrind

[Peter Maydell]

On 28 May 2015 at 13:08, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> @@ -81,7 +81,10 @@ static void trigger_signal(void *opaque, int n, int level)
>
>  static int irq_cpu_hotplug_init(SCLPEvent *event)
>  {
> -    irq_cpu_hotplug = qemu_allocate_irqs(trigger_signal, event, 1);
> +    qemu_irq irq = qemu_allocate_irq(trigger_signal, event, 0);
> +
> +    irq_cpu_hotplug = irq;
> +    qemu_free_irq(irq);
>      return 0;

Huh? Surely we can't validly use the irq once you've
called qemu_free_irq() on it?

-- PMM

Re: [Qemu-devel] [PATCH 29/29] hw/s390x/sclpcpu.c: Fix memory leak spotted by valgrind

[Paolo Bonzini]

On 28/05/2015 14:08, Shannon Zhao wrote:
> -static qemu_irq *irq_cpu_hotplug; /* Only used in this file */
> +static qemu_irq irq_cpu_hotplug; /* Only used in this file */
>  
>  #define EVENT_QUAL_CPU_CHANGE  1
>  
>  void raise_irq_cpu_hotplug(void)
>  {
> -    qemu_irq_raise(*irq_cpu_hotplug);
> +    qemu_irq_raise(irq_cpu_hotplug);
>  }
>  
>  static unsigned int send_mask(void)
> @@ -81,7 +81,10 @@ static void trigger_signal(void *opaque, int n, int level)
>  
>  static int irq_cpu_hotplug_init(SCLPEvent *event)
>  {
> -    irq_cpu_hotplug = qemu_allocate_irqs(trigger_signal, event, 1);
> +    qemu_irq irq = qemu_allocate_irq(trigger_signal, event, 0);
> +
> +    irq_cpu_hotplug = irq;
> +    qemu_free_irq(irq);
>      return 0;

This is wrong, you cannot free the IRQ after you have stored it in
irq_cpu_hotplug.

Paolo

Re: [Qemu-devel] [PATCH 29/29] hw/s390x/sclpcpu.c: Fix memory leak spotted by valgrind

[Shannon Zhao]

On 2015/5/30 18:34, Paolo Bonzini wrote:
>
> On 28/05/2015 14:08, Shannon Zhao wrote:
>> >-static qemu_irq *irq_cpu_hotplug; /* Only used in this file */
>> >+static qemu_irq irq_cpu_hotplug; /* Only used in this file */
>> >
>> >  #define EVENT_QUAL_CPU_CHANGE  1
>> >
>> >  void raise_irq_cpu_hotplug(void)
>> >  {
>> >-    qemu_irq_raise(*irq_cpu_hotplug);
>> >+    qemu_irq_raise(irq_cpu_hotplug);
>> >  }
>> >
>> >  static unsigned int send_mask(void)
>> >@@ -81,7 +81,10 @@ static void trigger_signal(void *opaque, int n, int level)
>> >
>> >  static int irq_cpu_hotplug_init(SCLPEvent *event)
>> >  {
>> >-    irq_cpu_hotplug = qemu_allocate_irqs(trigger_signal, event, 1);
>> >+    qemu_irq irq = qemu_allocate_irq(trigger_signal, event, 0);
>> >+
>> >+    irq_cpu_hotplug = irq;
>> >+    qemu_free_irq(irq);
>> >      return 0;
> This is wrong, you cannot free the IRQ after you have stored it in
> irq_cpu_hotplug.

Yeah, sorry for that. But I don't find who calls 
raise_irq_cpu_hotplug(). I'm not very familiar with these codes.

-- 
Shannon

Re: [Qemu-devel] [PATCH 00/29] Fix memory leak relevant to calling qemu_allocate_irqs

[Michael Tokarev]

28.05.2015 15:08, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> Before I sent some patches to fix memory leak spotted by valgrind and
> those are relevant to qemu_allocate_irqs. Then I find all the places
> calling this function through code searching and test by valgrind to
> check whether they have memory leak. These patches fix these memory leaks.
> 
> Sorry that maybe the names of the patches are vertiginous while I could
> not find out better names and I try to sort them out.

Maybe a better subject will be "fix memory leak after qemu_allocate_irqs"
or something like that?  And for some, "use qemu_allocate_irq not _irqs
for single irq" -- this kind is sorta fun, I wonder why the codebase has
so many cases of this API misuse.

And one more question: do you really care that whole valgrind report is
included into every commit message? :)  All the recent patches you sent
(all the 3 recent "spotted by valgrind" series) are fine without these
reports which are the only info included in the commit message, I'd just
drop these reports like -ETOOMUCHINFO :)  Anyone disagree? :)

Thanks,

/mjt

Re: [Qemu-devel] [PATCH 00/29] Fix memory leak relevant to calling qemu_allocate_irqs

[Shannon Zhao]

On 2015/5/28 20:34, Michael Tokarev wrote:
> 28.05.2015 15:08, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> Before I sent some patches to fix memory leak spotted by valgrind and
>> those are relevant to qemu_allocate_irqs. Then I find all the places
>> calling this function through code searching and test by valgrind to
>> check whether they have memory leak. These patches fix these memory leaks.
>>
>> Sorry that maybe the names of the patches are vertiginous while I could
>> not find out better names and I try to sort them out.
> 
> Maybe a better subject will be "fix memory leak after qemu_allocate_irqs"
> or something like that?  And for some, "use qemu_allocate_irq not _irqs
> for single irq" -- this kind is sorta fun, I wonder why the codebase has
> so many cases of this API misuse.
> 
> And one more question: do you really care that whole valgrind report is
> included into every commit message? :)  
not really, while these reports show people the problems. You could deal
them in your way.

Thanks,

-- 
Shannon