Hello! > >> (process:4102): GLib-CRITICAL **: g_hash_table_iter_next: assertion > >> 'ri->version == ri->hash_table->version' failed > >> > >> (process:4102): GLib-CRITICAL **: g_hash_table_iter_next: assertion > >> 'ri->version == ri->hash_table->version' failed > >> > >> (process:4102): GLib-CRITICAL **: iter_remove_or_steal: assertion > >> 'ri->version == ri->hash_table->version' failed
Wow... Actually this may come from attempts to modify the tree inside iteration. > Thanks! sclp_init() seems to violate several QOM design principles in > that it uses object_new() during TypeInfo::instance_init() and uses a > TYPE_... constant as property name. But nothing else stands out immediately. I think we should refactor this and retry. If not all problems go away, then we are indeed modifying the tree during iteration, and we have to find some solution. I wonder... Could we have both list and hashtable? hashtable for searching by name and list for iteration. In this case we would not have to use glib's iterators, and would be free of problems with them. Just keep the list and hashtable in sync. Or, is there any hashtable implementation out there which would keep iterators valid during modification? OTOH, glib has a function "remove the element at iterator's position", and we could postpone addition. So, perhaps, using both containers would be an overkill, just refactor the code to adapt to the new behavior. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
