I foud a problem that when it resize the hash table, it may hangs if the resize larger than 16384, the call path is: g_hash_table_resize->g_new0->g_malloc0->dlcalloc.
I think the resize function in unicorn may has some flaw:
The g_new0 is similar malloc. Generally, the new_nodes should be cleared I guess. Since unicorn_efi some code continue to use official unicron, so this code is the same as unicron.
I think this problem is caused by g_hash_table_resize, it seems to resize the has table, and write the old value to the new hash table. It seems look for the empty items in the new_nodes, and if the new_nodes is not be cleared, it maybe naver found the empty items. So I added a line under the g_new0 function, and I think clearing new_nodes every time may improve the performance. Is anyone else having the same problem?
I foud a problem that when it resize the hash table, it may hangs if the resize larger than 16384, the call path is: g_hash_table_resize->g_new0->g_malloc0->dlcalloc. I think the resize function in unicorn may has some flaw: The g_new0 is similar malloc. Generally, the new_nodes should be cleared I guess. Since unicorn_efi some code continue to use official unicron, so this code is the same as unicron.
I think this problem is caused by g_hash_table_resize, it seems to resize the has table, and write the old value to the new hash table. It seems look for the empty items in the new_nodes, and if the new_nodes is not be cleared, it maybe naver found the empty items. So I added a line under the g_new0 function, and I think clearing new_nodes every time may improve the performance. Is anyone else having the same problem?