Go bindings mem_unmap

[eqv]

mem_unmap is missing in the go bindings. I tried to add it myself (https://github.com/ranmrdrakono/unicorn/commit/af2a6e7f27e6f78a3a7120b289fcddb9f62f6015 and https://github.com/ranmrdrakono/unicorn/commit/853734724fd80a286b0da44ba9df0d5e67d4d025). However my aproach seems to be of. calling unmap with invalid arguments works as expected (ARG_ERR returned). Calling unmap on an not-yet-mapped pages fails with UC_ERR_NOMEM as expected as well. However calling it on a previously maped page will not unmap the page. Calling it a second time on the same page will result in a crash:

main: /golang/src/github.com/unicorn-engine/unicorn/qemu/memory.c:1596: memory_region_del_subregion_x86_64: Assertion `subregion->container == mr' failed.

Any hint would be appreciated

[lunixbochs]

Worked for me in #203

Maybe make sure you're mapping/unmapping page-sized data?

[eqv]

Yes I did. Can you try what happens if you add another call to unmap creating a double-unmap?

[aquynh]

i merged the PR #203.

[eqv]

I have absolutely no idea why the exact same patches worked but this did solve the issue indeed.

[eqv]

Actually it didn't. This is still crashing:

package main

import (
    uc "github.com/unicorn-engine/unicorn/bindings/go/unicorn"
  "fmt"
  "testing"
)

func TestUnmap(t* testing.T) {
    mu, err := uc.NewUnicorn(uc.ARCH_X86, uc.MODE_64)

    if err != nil {
        fmt.Printf("%v\n",err)
    }

    // map and write code to memory
    if err := mu.MemMap(0x1000, 0x1000); err != nil {
        t.Error(fmt.Sprintf("%v\n",err));
    }

    if err := mu.MemMap(0x4000, 0x1000); err != nil {
        t.Error(fmt.Sprintf("%v\n",err));
    }

    if err := mu.MemUnmap(0x4000, 0x1000); err != nil {
        t.Error(fmt.Sprintf("%v\n",err));
    }

    if err := mu.MemUnmap(0x4000, 0x1000); err != nil {
        t.Error(fmt.Sprintf("%v\n",err));
    }

}

[lunixbochs]

What's your platform? That test works for me. Have you run go get -u github.com/unicorn-engine/unicorn/bindings/go to update the bindings? Do you have the latest version of unicorn installed?

[eqv]

Fresh pull from the main Repo. Clean build and install. Up to date version of the bindings used via go get. Ubuntu 14.04 64 bit. I also ran the testcase under valgrind but nothing suspicious there (might be due to the fact that go and valgrind don't play together well).

[lunixbochs]

Can you port your testcase to C and make sure that works as expected? The Go bindings are a very thin wrapper. The only remotely scary thing is the hook callback code.

[eqv]

sure, give me a moment, be right back.

[eqv]

#define __STDC_FORMAT_MACROS
#include <inttypes.h>
#include <string.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

#include <unicorn/unicorn.h>

int main(int argc, char **argv, char **envp)
{
    uc_engine *uc;
    uc_hook trace1, trace2;
    uc_err err;

    printf("===================================\n");
    printf("# Example of unmapping memory\n");

    // Initialize emulator in X86-32bit mode
    err = uc_open(UC_ARCH_X86, UC_MODE_32, &uc);
    if (err) {
        printf("not ok - Failed on uc_open() with error returned: %u\n", err);
        return;
    }

    uc_mem_map(uc, 0x1000, 0x1000, UC_PROT_ALL);
    uc_mem_map(uc, 0x4000, 0x1000, UC_PROT_ALL);
    uc_mem_unmap(uc, 0x4000, 0x1000);
    uc_mem_unmap(uc, 0x4000, 0x1000);

    uc_close(uc);
    return 0;
}

Also fails with

test_doublefree: /home/ranmrdrakono/golang/src/github.com/unicorn-engine/unicorn/qemu/memory.c:1597: memory_region_del_subregion_x86_64: Assertion `subregion->container == mr' failed

[eqv]

Oh btw this time valgrind has quite few instances of:

==14298== Invalid read of size 8
==14298==    at 0x55DC86E: memory_mapping (uc.c:817)
==14298==    by 0x55DB7BD: check_mem_area (uc.c:326)
==14298==    by 0x55DC709: uc_mem_unmap (uc.c:784)
==14298==    by 0x4008CA: main (in /home/ranmrdrakono/golang/src/github.com/unicorn-engine/unicorn/samples/test_doublefree)
==14298==  Address 0x1a933730 is 96 bytes inside a block of size 272 free'd
==14298==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14298==    by 0x4F4D429: memory_unmap_x86_64 (memory.c:71)
==14298==    by 0x55DC7D3: uc_mem_unmap (uc.c:800)
==14298==    by 0x4008B4: main (in /home/ranmrdrakono/golang/src/github.com/unicorn-engine/unicorn/samples/test_doublefree)

So I suspect a use after free bug to be hidden somewhere around that lines.

[lunixbochs]

I primarily test on OS X, where allocation behavior is totally different. I've seen bugs before that are easier to trigger on Linux.

[eqv]

Can you reproduce the use after frees in valgrind (even if they don't trigger any strange behaviour)?

[lunixbochs]

Yep it dumps a bunch of these on OS X:

==44278== Invalid read of size 8
==44278==    at 0x104F78C82: memory_mapping (in /usr/local/lib/libunicorn.0.dylib)
==44278==    by 0x104F78B86: check_mem_area (in /usr/local/lib/libunicorn.0.dylib)
==44278==    by 0x104F79A04: uc_mem_unmap (in /usr/local/lib/libunicorn.0.dylib)
==44278==    by 0x100000EA0: main (in ./a.out)
==44278==  Address 0x11ce578b0 is 96 bytes inside a block of size 272 free'd
==44278==    at 0x1000088EF: free (in vgpreload_memcheck-amd64-darwin.so)
==44278==    by 0x1048326D4: memory_unmap_x86_64 (in /usr/local/lib/libunicorn.0.dylib)
==44278==    by 0x104F79AF6: uc_mem_unmap (in /usr/local/lib/libunicorn.0.dylib)
==44278==    by 0x100000E86: main (in ./a.out)

I'm guessing the Go runtime allocates enough surrounding memory to mask the error for me.

Based on memory_mapping() here it looks like uc_mem_unmap() isn't properly removing a reference to the MemoryRegion after unmapping it.

[eqv]

Jup, that's what I was thinking. If I had to guess (without verifying) the memory mapping index cache (https://github.com/unicorn-engine/unicorn/blob/master/uc.c#L815) could be the culprit. It might be that if the currently cached mapping is removed the cached_index is not invalidated.

[eqv]

Indeed, adding a check:

 if (i < uc->mapped_block_count && address >= uc->mapped_blocks[i]->addr && address < uc->mapped_blocks[i]->end)

Here: https://github.com/unicorn-engine/unicorn/blob/master/uc.c#L817 fixes the crash. However, this doesn't seem to fix all problems:

==28493==    at 0x4F51E88: memory_region_unref_x86_64 (memory.c:1273)
==28493==    by 0x4F4E20F: flatview_destroy_x86_64 (memory.c:337)
==28493==    by 0x4F4E2C5: flatview_unref_x86_64 (memory.c:351)
==28493==    by 0x4F545A4: address_space_destroy_x86_64 (memory.c:1846)
==28493==    by 0x4F13170: release_common (unicorn_common.h:54)
==28493==    by 0x4F1337E: x86_release (unicorn.c:29)
==28493==    by 0x55DB556: uc_close (uc.c:259)
==28493==    by 0x4008D4: main (in /.../golang/src/github.com/unicorn-engine/unicorn/samples/test_doublefree)
==28493==  Address 0x1a9336f8 is 40 bytes inside a block of size 272 free'd
==28493==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28493==    by 0x4F4D429: memory_unmap_x86_64 (memory.c:71)
==28493==    by 0x55DC7E1: uc_mem_unmap (uc.c:801)
==28493==    by 0x4008B2: main (in /.../golang/src/github.com/unicorn-engine/unicorn/samples/test_doublefree)

[aquynh]

after the fix https://github.com/unicorn-engine/unicorn/pull/213, we still have a below problem (happens once in a while, but not all the time):

./tests/regress/mem_double_unmap
Tests OK
**
ERROR:qom/object.c:708:object_unref: assertion failed: (obj->ref > 0)
[1]    63378 abort      ./mem_double_unmap

[eqv]

I believe this is the use after free i mentioned in my last message. I think we should create a second issue for that and close this one. It might be a good idea to run all tests under valgrind memcheck regularily to avoid memory corruption bugs.

[aquynh]

fixed this use-after-free issue, please confirm, thanks.

[eqv]

All fixed. Now there is only some memory leak:

valgrind --leak-check=yes ./mem_double_unmap

==6083== Memcheck, a memory error detector
==6083== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6083== Command: ./mem_double_unmap
==6083== 
==6083== Warning: set address range perms: large range [0xf01000, 0x14f01000) (defined)
Tests OK
==6083== 
==6083== HEAP SUMMARY:
==6083==     in use at exit: 9,089 bytes in 164 blocks
==6083==   total heap usage: 596 allocs, 432 frees, 32,907,031 bytes allocated
==6083== 
==6083== 7 bytes in 1 blocks are definitely lost in loss record 37 of 146
==6083==    at 0x15B2BB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6083==    by 0x15D86610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==6083==    by 0x15D9DB0E: g_strdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==6083==    by 0x42DB14: memory_region_init_x86_64 (memory.c:928)
==6083==    by 0x42E790: memory_region_init_ram_x86_64 (memory.c:1183)
==6083==    by 0x429F89: memory_map_x86_64 (memory.c:38)
==6083==    by 0x404703: uc_mem_map (uc.c:594)
==6083==    by 0x4033E7: main (in /.../golang/src/github.com/unicorn-engine/unicorn/tests/regress/mem_double_unmap)
==6083== 
==6083== 8 bytes in 1 blocks are definitely lost in loss record 39 of 146
==6083==    at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6083==    by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==6083==    by 0x5A44C2: qemu_tcg_init_vcpu_x86_64 (cpus.c:182)
==6083==    by 0x5A42FB: qemu_init_vcpu_x86_64 (cpus.c:116)
==6083==    by 0x5A8BD1: x86_cpu_realizefn (cpu.c:2292)
==6083==    by 0x4433C1: device_set_realized (qdev.c:184)
==6083==    by 0x4421B8: property_set_bool (object.c:1504)
==6083==    by 0x44057D: object_property_set (object.c:829)
==6083==    by 0x442BAC: object_property_set_qobject (qom-qobject.c:24)
==6083==    by 0x4408E3: object_property_set_bool (object.c:897)
==6083==    by 0x59F01F: pc_new_cpu (pc.c:107)
==6083==    by 0x59F0D7: pc_cpus_init (pc.c:132)
==6083== 
==6083== 144 bytes in 1 blocks are definitely lost in loss record 132 of 146
==6083==    at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6083==    by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==6083==    by 0x433929: tcg_cpu_address_space_init_x86_64 (exec.c:405)
==6083==    by 0x5A44A7: qemu_tcg_init_vcpu_x86_64 (cpus.c:178)
==6083==    by 0x5A42FB: qemu_init_vcpu_x86_64 (cpus.c:116)
==6083==    by 0x5A8BD1: x86_cpu_realizefn (cpu.c:2292)
==6083==    by 0x4433C1: device_set_realized (qdev.c:184)
==6083==    by 0x4421B8: property_set_bool (object.c:1504)
==6083==    by 0x44057D: object_property_set (object.c:829)
==6083==    by 0x442BAC: object_property_set_qobject (qom-qobject.c:24)
==6083==    by 0x4408E3: object_property_set_bool (object.c:897)
==6083==    by 0x59F01F: pc_new_cpu (pc.c:107)
==6083== 
==6083== 272 bytes in 1 blocks are possibly lost in loss record 134 of 146
==6083==    at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6083==    by 0x14F13E54: _dl_allocate_tls (dl-tls.c:296)
==6083==    by 0x16048DA0: pthread_create@@GLIBC_2.2.5 (allocatestack.c:589)
==6083==    by 0x43C17A: qemu_thread_create (qemu-thread-posix.c:420)
==6083==    by 0x5A4560: qemu_tcg_init_vcpu_x86_64 (cpus.c:188)
==6083==    by 0x5A42FB: qemu_init_vcpu_x86_64 (cpus.c:116)
==6083==    by 0x5A8BD1: x86_cpu_realizefn (cpu.c:2292)
==6083==    by 0x4433C1: device_set_realized (qdev.c:184)
==6083==    by 0x4421B8: property_set_bool (object.c:1504)
==6083==    by 0x44057D: object_property_set (object.c:829)
==6083==    by 0x442BAC: object_property_set_qobject (qom-qobject.c:24)
==6083==    by 0x4408E3: object_property_set_bool (object.c:897)
==6083== 
==6083== 360 (96 direct, 264 indirect) bytes in 1 blocks are definitely lost in loss record 137 of 146
==6083==    at 0x15B2BB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6083==    by 0x15D86610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==6083==    by 0x43F694: object_new_with_type (object.c:425)
==6083==    by 0x43F72B: object_new (object.c:436)
==6083==    by 0x43D033: machine_initialize (vl.c:119)
==6083==    by 0x403A89: uc_open (uc.c:238)
==6083==    by 0x4033A5: main (in /.../golang/src/github.com/unicorn-engine/unicorn/tests/regress/mem_double_unmap)
==6083== 
==6083== 616 (80 direct, 536 indirect) bytes in 1 blocks are definitely lost in loss record 138 of 146
==6083==    at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6083==    by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==6083==    by 0x4401AB: object_property_add (object.c:755)
==6083==    by 0x442068: object_property_add_str (object.c:1464)
==6083==    by 0x442ACF: object_instance_init (object.c:1699)
==6083==    by 0x43EFC7: object_init_with_type (object.c:310)
==6083==    by 0x43EF9D: object_init_with_type (object.c:306)
==6083==    by 0x43F1DF: object_initialize_with_type (object.c:340)
==6083==    by 0x43F262: object_initialize (object.c:348)
==6083==    by 0x42DAC9: memory_region_init_x86_64 (memory.c:922)
==6083==    by 0x436D92: memory_map_init_x86_64 (exec.c:1575)
==6083==    by 0x436E0A: cpu_exec_init_all_x86_64 (exec.c:1583)
==6083== 
==6083== 616 (80 direct, 536 indirect) bytes in 1 blocks are definitely lost in loss record 139 of 146
==6083==    at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6083==    by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==6083==    by 0x4401AB: object_property_add (object.c:755)
==6083==    by 0x442068: object_property_add_str (object.c:1464)
==6083==    by 0x442ACF: object_instance_init (object.c:1699)
==6083==    by 0x43EFC7: object_init_with_type (object.c:310)
==6083==    by 0x43EF9D: object_init_with_type (object.c:306)
==6083==    by 0x43F1DF: object_initialize_with_type (object.c:340)
==6083==    by 0x43F262: object_initialize (object.c:348)
==6083==    by 0x42DAC9: memory_region_init_x86_64 (memory.c:922)
==6083==    by 0x42E6F5: memory_region_init_io_x86_64 (memory.c:1169)
==6083==    by 0x436604: io_mem_init (exec.c:1423)
==6083== 
==6083== 616 (80 direct, 536 indirect) bytes in 1 blocks are definitely lost in loss record 140 of 146
==6083==    at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6083==    by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==6083==    by 0x4401AB: object_property_add (object.c:755)
==6083==    by 0x442068: object_property_add_str (object.c:1464)
==6083==    by 0x442ACF: object_instance_init (object.c:1699)
==6083==    by 0x43EFC7: object_init_with_type (object.c:310)
==6083==    by 0x43EF9D: object_init_with_type (object.c:306)
==6083==    by 0x43F1DF: object_initialize_with_type (object.c:340)
==6083==    by 0x43F262: object_initialize (object.c:348)
==6083==    by 0x42DAC9: memory_region_init_x86_64 (memory.c:922)
==6083==    by 0x42E6F5: memory_region_init_io_x86_64 (memory.c:1169)
==6083==    by 0x43663E: io_mem_init (exec.c:1424)
==6083== 
==6083== 616 (80 direct, 536 indirect) bytes in 1 blocks are definitely lost in loss record 141 of 146
==6083==    at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6083==    by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==6083==    by 0x4401AB: object_property_add (object.c:755)
==6083==    by 0x442068: object_property_add_str (object.c:1464)
==6083==    by 0x442ACF: object_instance_init (object.c:1699)
==6083==    by 0x43EFC7: object_init_with_type (object.c:310)
==6083==    by 0x43EF9D: object_init_with_type (object.c:306)
==6083==    by 0x43F1DF: object_initialize_with_type (object.c:340)
==6083==    by 0x43F262: object_initialize (object.c:348)
==6083==    by 0x42DAC9: memory_region_init_x86_64 (memory.c:922)
==6083==    by 0x42E6F5: memory_region_init_io_x86_64 (memory.c:1169)
==6083==    by 0x436675: io_mem_init (exec.c:1426)
==6083== 
==6083== 616 (80 direct, 536 indirect) bytes in 1 blocks are definitely lost in loss record 142 of 146
==6083==    at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6083==    by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==6083==    by 0x4401AB: object_property_add (object.c:755)
==6083==    by 0x442068: object_property_add_str (object.c:1464)
==6083==    by 0x442ACF: object_instance_init (object.c:1699)
==6083==    by 0x43EFC7: object_init_with_type (object.c:310)
==6083==    by 0x43EF9D: object_init_with_type (object.c:306)
==6083==    by 0x43F1DF: object_initialize_with_type (object.c:340)
==6083==    by 0x43F262: object_initialize (object.c:348)
==6083==    by 0x42DAC9: memory_region_init_x86_64 (memory.c:922)
==6083==    by 0x42E790: memory_region_init_ram_x86_64 (memory.c:1183)
==6083==    by 0x429F89: memory_map_x86_64 (memory.c:38)
==6083== 
==6083== 640 (320 direct, 320 indirect) bytes in 1 blocks are definitely lost in loss record 143 of 146
==6083==    at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6083==    by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==6083==    by 0x43584D: qemu_ram_alloc_from_ptr_x86_64 (exec.c:1094)
==6083==    by 0x43594B: qemu_ram_alloc_x86_64 (exec.c:1113)
==6083==    by 0x42E7EE: memory_region_init_ram_x86_64 (memory.c:1191)
==6083==    by 0x429F89: memory_map_x86_64 (memory.c:38)
==6083==    by 0x404703: uc_mem_map (uc.c:594)
==6083==    by 0x4033E7: main (in /.../golang/src/github.com/unicorn-engine/unicorn/tests/regress/mem_double_unmap)
==6083== 
==6083== 1,612 (80 direct, 1,532 indirect) bytes in 1 blocks are definitely lost in loss record 145 of 146
==6083==    at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6083==    by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==6083==    by 0x4401AB: object_property_add (object.c:755)
==6083==    by 0x442068: object_property_add_str (object.c:1464)
==6083==    by 0x442ACF: object_instance_init (object.c:1699)
==6083==    by 0x43EFC7: object_init_with_type (object.c:310)
==6083==    by 0x43EF9D: object_init_with_type (object.c:306)
==6083==    by 0x43F1DF: object_initialize_with_type (object.c:340)
==6083==    by 0x43F6B4: object_new_with_type (object.c:426)
==6083==    by 0x43F72B: object_new (object.c:436)
==6083==    by 0x440F47: object_get_root (object.c:1041)
==6083==    by 0x4437A9: qdev_get_machine (qdev.c:278)
==6083== 
==6083== LEAK SUMMARY:
==6083==    definitely lost: 1,055 bytes in 11 blocks
==6083==    indirectly lost: 4,796 bytes in 147 blocks
==6083==      possibly lost: 272 bytes in 1 blocks
==6083==    still reachable: 2,966 bytes in 5 blocks
==6083==         suppressed: 0 bytes in 0 blocks
==6083== Reachable blocks (those to which a pointer was found) are not shown.
==6083== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6083== 
==6083== For counts of detected and suppressed errors, rerun with: -v
==6083== ERROR SUMMARY: 12 errors from 12 contexts (suppressed: 0 from 0)

[aquynh]

Yes, memleak is a known issue. If you can fix any, plz send PR. On Oct 28, 2015 1:52 AM, "ranmrdrakono" notifications@github.com wrote:

All fixed. Now there is only some memory leak:

valgrind --leak-check=yes ./mem_double_unmap

==6083== Memcheck, a memory error detector ==6083== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==6083== Command: ./mem_double_unmap ==6083== ==6083== Warning: set address range perms: large range [0xf01000, 0x14f01000) (defined) Tests OK ==6083== ==6083== HEAP SUMMARY: ==6083== in use at exit: 9,089 bytes in 164 blocks ==6083== total heap usage: 596 allocs, 432 frees, 32,907,031 bytes allocated ==6083== ==6083== 7 bytes in 1 blocks are definitely lost in loss record 37 of 146 ==6083== at 0x15B2BB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6083== by 0x15D86610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==6083== by 0x15D9DB0E: g_strdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==6083== by 0x42DB14: memory_region_init_x86_64 (memory.c:928) ==6083== by 0x42E790: memory_region_init_ram_x86_64 (memory.c:1183) ==6083== by 0x429F89: memory_map_x86_64 (memory.c:38) ==6083== by 0x404703: uc_mem_map (uc.c:594) ==6083== by 0x4033E7: main (in /.../golang/src/github.com/unicorn-engine/unicorn/tests/regress/mem_double_unmap) ==6083== ==6083== 8 bytes in 1 blocks are definitely lost in loss record 39 of 146 ==6083== at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6083== by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==6083== by 0x5A44C2: qemu_tcg_init_vcpu_x86_64 (cpus.c:182) ==6083== by 0x5A42FB: qemu_init_vcpu_x86_64 (cpus.c:116) ==6083== by 0x5A8BD1: x86_cpu_realizefn (cpu.c:2292) ==6083== by 0x4433C1: device_set_realized (qdev.c:184) ==6083== by 0x4421B8: property_set_bool (object.c:1504) ==6083== by 0x44057D: object_property_set (object.c:829) ==6083== by 0x442BAC: object_property_set_qobject (qom-qobject.c:24) ==6083== by 0x4408E3: object_property_set_bool (object.c:897) ==6083== by 0x59F01F: pc_new_cpu (pc.c:107) ==6083== by 0x59F0D7: pc_cpus_init (pc.c:132) ==6083== ==6083== 144 bytes in 1 blocks are definitely lost in loss record 132 of 146 ==6083== at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6083== by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==6083== by 0x433929: tcg_cpu_address_space_init_x86_64 (exec.c:405) ==6083== by 0x5A44A7: qemu_tcg_init_vcpu_x86_64 (cpus.c:178) ==6083== by 0x5A42FB: qemu_init_vcpu_x86_64 (cpus.c:116) ==6083== by 0x5A8BD1: x86_cpu_realizefn (cpu.c:2292) ==6083== by 0x4433C1: device_set_realized (qdev.c:184) ==6083== by 0x4421B8: property_set_bool (object.c:1504) ==6083== by 0x44057D: object_property_set (object.c:829) ==6083== by 0x442BAC: object_property_set_qobject (qom-qobject.c:24) ==6083== by 0x4408E3: object_property_set_bool (object.c:897) ==6083== by 0x59F01F: pc_new_cpu (pc.c:107) ==6083== ==6083== 272 bytes in 1 blocks are possibly lost in loss record 134 of 146 ==6083== at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6083== by 0x14F13E54: _dl_allocate_tls (dl-tls.c:296) ==6083== by 0x16048DA0: pthread_create@@GLIBC_2.2.5 (allocatestack.c:589) ==6083== by 0x43C17A: qemu_thread_create (qemu-thread-posix.c:420) ==6083== by 0x5A4560: qemu_tcg_init_vcpu_x86_64 (cpus.c:188) ==6083== by 0x5A42FB: qemu_init_vcpu_x86_64 (cpus.c:116) ==6083== by 0x5A8BD1: x86_cpu_realizefn (cpu.c:2292) ==6083== by 0x4433C1: device_set_realized (qdev.c:184) ==6083== by 0x4421B8: property_set_bool (object.c:1504) ==6083== by 0x44057D: object_property_set (object.c:829) ==6083== by 0x442BAC: object_property_set_qobject (qom-qobject.c:24) ==6083== by 0x4408E3: object_property_set_bool (object.c:897) ==6083== ==6083== 360 (96 direct, 264 indirect) bytes in 1 blocks are definitely lost in loss record 137 of 146 ==6083== at 0x15B2BB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6083== by 0x15D86610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==6083== by 0x43F694: object_new_with_type (object.c:425) ==6083== by 0x43F72B: object_new (object.c:436) ==6083== by 0x43D033: machine_initialize (vl.c:119) ==6083== by 0x403A89: uc_open (uc.c:238) ==6083== by 0x4033A5: main (in /.../golang/src/github.com/unicorn-engine/unicorn/tests/regress/mem_double_unmap) ==6083== ==6083== 616 (80 direct, 536 indirect) bytes in 1 blocks are definitely lost in loss record 138 of 146 ==6083== at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6083== by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==6083== by 0x4401AB: object_property_add (object.c:755) ==6083== by 0x442068: object_property_add_str (object.c:1464) ==6083== by 0x442ACF: object_instance_init (object.c:1699) ==6083== by 0x43EFC7: object_init_with_type (object.c:310) ==6083== by 0x43EF9D: object_init_with_type (object.c:306) ==6083== by 0x43F1DF: object_initialize_with_type (object.c:340) ==6083== by 0x43F262: object_initialize (object.c:348) ==6083== by 0x42DAC9: memory_region_init_x86_64 (memory.c:922) ==6083== by 0x436D92: memory_map_init_x86_64 (exec.c:1575) ==6083== by 0x436E0A: cpu_exec_init_all_x86_64 (exec.c:1583) ==6083== ==6083== 616 (80 direct, 536 indirect) bytes in 1 blocks are definitely lost in loss record 139 of 146 ==6083== at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6083== by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==6083== by 0x4401AB: object_property_add (object.c:755) ==6083== by 0x442068: object_property_add_str (object.c:1464) ==6083== by 0x442ACF: object_instance_init (object.c:1699) ==6083== by 0x43EFC7: object_init_with_type (object.c:310) ==6083== by 0x43EF9D: object_init_with_type (object.c:306) ==6083== by 0x43F1DF: object_initialize_with_type (object.c:340) ==6083== by 0x43F262: object_initialize (object.c:348) ==6083== by 0x42DAC9: memory_region_init_x86_64 (memory.c:922) ==6083== by 0x42E6F5: memory_region_init_io_x86_64 (memory.c:1169) ==6083== by 0x436604: io_mem_init (exec.c:1423) ==6083== ==6083== 616 (80 direct, 536 indirect) bytes in 1 blocks are definitely lost in loss record 140 of 146 ==6083== at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6083== by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==6083== by 0x4401AB: object_property_add (object.c:755) ==6083== by 0x442068: object_property_add_str (object.c:1464) ==6083== by 0x442ACF: object_instance_init (object.c:1699) ==6083== by 0x43EFC7: object_init_with_type (object.c:310) ==6083== by 0x43EF9D: object_init_with_type (object.c:306) ==6083== by 0x43F1DF: object_initialize_with_type (object.c:340) ==6083== by 0x43F262: object_initialize (object.c:348) ==6083== by 0x42DAC9: memory_region_init_x86_64 (memory.c:922) ==6083== by 0x42E6F5: memory_region_init_io_x86_64 (memory.c:1169) ==6083== by 0x43663E: io_mem_init (exec.c:1424) ==6083== ==6083== 616 (80 direct, 536 indirect) bytes in 1 blocks are definitely lost in loss record 141 of 146 ==6083== at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6083== by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==6083== by 0x4401AB: object_property_add (object.c:755) ==6083== by 0x442068: object_property_add_str (object.c:1464) ==6083== by 0x442ACF: object_instance_init (object.c:1699) ==6083== by 0x43EFC7: object_init_with_type (object.c:310) ==6083== by 0x43EF9D: object_init_with_type (object.c:306) ==6083== by 0x43F1DF: object_initialize_with_type (object.c:340) ==6083== by 0x43F262: object_initialize (object.c:348) ==6083== by 0x42DAC9: memory_region_init_x86_64 (memory.c:922) ==6083== by 0x42E6F5: memory_region_init_io_x86_64 (memory.c:1169) ==6083== by 0x436675: io_mem_init (exec.c:1426) ==6083== ==6083== 616 (80 direct, 536 indirect) bytes in 1 blocks are definitely lost in loss record 142 of 146 ==6083== at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6083== by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==6083== by 0x4401AB: object_property_add (object.c:755) ==6083== by 0x442068: object_property_add_str (object.c:1464) ==6083== by 0x442ACF: object_instance_init (object.c:1699) ==6083== by 0x43EFC7: object_init_with_type (object.c:310) ==6083== by 0x43EF9D: object_init_with_type (object.c:306) ==6083== by 0x43F1DF: object_initialize_with_type (object.c:340) ==6083== by 0x43F262: object_initialize (object.c:348) ==6083== by 0x42DAC9: memory_region_init_x86_64 (memory.c:922) ==6083== by 0x42E790: memory_region_init_ram_x86_64 (memory.c:1183) ==6083== by 0x429F89: memory_map_x86_64 (memory.c:38) ==6083== ==6083== 640 (320 direct, 320 indirect) bytes in 1 blocks are definitely lost in loss record 143 of 146 ==6083== at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6083== by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==6083== by 0x43584D: qemu_ram_alloc_from_ptr_x86_64 (exec.c:1094) ==6083== by 0x43594B: qemu_ram_alloc_x86_64 (exec.c:1113) ==6083== by 0x42E7EE: memory_region_init_ram_x86_64 (memory.c:1191) ==6083== by 0x429F89: memory_map_x86_64 (memory.c:38) ==6083== by 0x404703: uc_mem_map (uc.c:594) ==6083== by 0x4033E7: main (in /.../golang/src/github.com/unicorn-engine/unicorn/tests/regress/mem_double_unmap) ==6083== ==6083== 1,612 (80 direct, 1,532 indirect) bytes in 1 blocks are definitely lost in loss record 145 of 146 ==6083== at 0x15B2F9D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==6083== by 0x15D872B8: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==6083== by 0x4401AB: object_property_add (object.c:755) ==6083== by 0x442068: object_property_add_str (object.c:1464) ==6083== by 0x442ACF: object_instance_init (object.c:1699) ==6083== by 0x43EFC7: object_init_with_type (object.c:310) ==6083== by 0x43EF9D: object_init_with_type (object.c:306) ==6083== by 0x43F1DF: object_initialize_with_type (object.c:340) ==6083== by 0x43F6B4: object_new_with_type (object.c:426) ==6083== by 0x43F72B: object_new (object.c:436) ==6083== by 0x440F47: object_get_root (object.c:1041) ==6083== by 0x4437A9: qdev_get_machine (qdev.c:278) ==6083== ==6083== LEAK SUMMARY: ==6083== definitely lost: 1,055 bytes in 11 blocks ==6083== indirectly lost: 4,796 bytes in 147 blocks ==6083== possibly lost: 272 bytes in 1 blocks ==6083== still reachable: 2,966 bytes in 5 blocks ==6083== suppressed: 0 bytes in 0 blocks ==6083== Reachable blocks (those to which a pointer was found) are not shown. ==6083== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==6083== ==6083== For counts of detected and suppressed errors, rerun with: -v ==6083== ERROR SUMMARY: 12 errors from 12 contexts (suppressed: 0 from 0)

— Reply to this email directly or view it on GitHub https://github.com/unicorn-engine/unicorn/issues/202#issuecomment-151585712 .

[aquynh]

please open a new issue on memory leak, thanks.