It should probably do some different method rather than a direct cast or something.
e.g.
void *np;
g_hash_table_lookup_extended(...., &np)
n = GPOINTER_TO_INT(np)
...
np = GINT_TO_POINTER(n);
g_hash_table_insert(...np);
the > 0 test doesn't inspire confidence for me.
Better would be to have a properly subclassable hash table class rather than the glib abomination, but oh well, what can you do eh?
On Wed, 2003-10-22 at 06:41, Joe Marcus Clarke wrote:
One of our users reported that Evo worked well on his Sparc64 machine, but crashed every time he exited the app. He sent a stack trace with symbols (http://www.marcuscom.com/downloads/evo_crash1.txt). What seems to happen here is that the uid is looked up in the hashtable, but a bad oldkey is returned with a count of 0. Since count is not one, it tries to update the count (decrement the ref count maybe?), but the key is bad, so we crash. I had him add a check to make sure n > 0, and that crash was fixed, but another (similar) one crept up (http://www.marcuscom.com/downloads/evo_crash2.txt). The same thing happens here (n == 0). I applied the same patch, and the crashes went away. Is this patch correct (http://rainbow-runner.nl/~kwm/patch-camel_camel-vee-folder.c) or is this just a nasty hack-around? If a bad hack, does anyone have any idea how this could happen, or anywhere else I could look to find a better solution? Thanks. Joe
