Possible GHashTable bug?



	I've built a Quake2 renderer that uses Glib.  I'm currently adding
the necessary game rules (physics, A.I., etc.) to make it a complete game.  
GLib is solving all my cross-platform woes, and I expect to heavily use
the data structs (hash, lists, etc.) in the physics and A.I. portion of
the game.  Let's hope it's fast enough! :)

	I'm having trouble with a GHashTable, I don't know if it's a bug
or just improper usage on my part.  My interpretation of the documentation
is that it's a bug.

	I have an "entity manager" that, when destroyed, should remove all
the entities from its hash.  Here's the destroy func:


static void destroy(TEntityMgr *entity_mgr) {
	
	g_hash_table_foreach(entity_mgr->hash_table, unref_entity, entity_mgr);
	g_hash_table_destroy(entity_mgr->hash_table);
	g_free(entity_mgr);	
}

	When I call 'unref_entity', which is the GHFunc that's supposed
to remove the entity from entity_mgr->hash_table, I [eventually] call
this:

g_hash_table_lookup( entity_mgr->hash_table, &entity_id );

	What happens is this: The first entity is found with no problem
(and subsequently removed), but by the time I look up the second
entity--after removing the first entity--the foreach() calls
'unref_entity' with garbage.

	In short: Calling g_hash_table_remove() from within a
g_hash_table_foreach() causes the next iteration of your GHFunc to get
called with a garbage value.

	I'm guessing there's a missing freeze/thaw in
g_hash_table_foreach()....?

	In any event, using g_hash_table_foreach_remove() and turning
'unref_entity' into a GHRFunc that returns TRUE solved my problem.  If
anybody's interested I can put together a simplified demo program and post
it.

	
[dereks ip122 src]$ rpm -q libglib1.2 libglib1.2-devel
libglib1.2-1.2.10-1mdk
libglib1.2-devel-1.2.10-1mdk
[dereks ip122 src]$ 


Thanks,
Derek Simkowiak
dereks at realloc dot net





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]