Re: [Evolution-hackers] Evo 1.4.5 crashes on exit on Sparc64 FreeBSD

[Not Zed <notzed ximian com>]

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