Fix memory leaks (memory listeners)

[iroiro123]

This is a fix for one of memory leaks #258.

I added some codes which free memory listeners to address_space_destroy(), but I don't know whether there is no problem with this way.
Is it possible for a memory listener to be registered with two or more address spaces?

This leak has been resolved.

$ valgrind --leak-check=yes ./mem_double_unmap
...
==18718== 144 bytes in 1 blocks are definitely lost in loss record 130 of 141
==18718==    at 0x15B34C70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18718==    by 0x15D8D668: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==18718==    by 0x40E9C7: tcg_cpu_address_space_init_x86_64 (exec.c:405)
==18718==    by 0x5555CB: qemu_tcg_init_vcpu_x86_64 (cpus.c:184)
==18718==    by 0x555417: qemu_init_vcpu_x86_64 (cpus.c:122)
==18718==    by 0x5BF6ED: x86_cpu_realizefn (cpu.c:2309)
==18718==    by 0x438E6B: device_set_realized (qdev.c:184)
==18718==    by 0x437C4C: property_set_bool (object.c:1509)
==18718==    by 0x435FC5: object_property_set (object.c:829)
==18718==    by 0x438650: object_property_set_qobject (qom-qobject.c:24)
==18718==    by 0x43634C: object_property_set_bool (object.c:898)
==18718==    by 0x4155C1: pc_new_cpu (pc.c:107)
...

[aquynh]

Thanks for this serie of memleak fixes, but before I take a closer look, maybe you want to try the "memleak" branch, which is supposed to fix most/all memleak issue on X86. Let me know if you can confirm that, and compare with your solution. Thanks.

[iroiro123]

The memory leaks I fixed seem to have been already fixed.
I withdraw my pull requests(#455, #456) and I'll try to fix remaining leaks.

[aquynh]

there are still some issues with the "memleak" branch:

• tests/regress/regress.py crashes for some unknown reason (due to sparc_reg.py IIRC)
• memleak is fixed for x86, arm & ar64, but not for the rest architectures yet.

memleak is the biggest blocker for the next release 1.0. if you can finish this work, that will be great!

thanks.