Re: possible hash deadlock with recent changes

[dsmich]

---- address@hidden wrote: 
> 
> ---- "Ludovic Courtès" <address@hidden> wrote: 
> > Hi,
> > 
> > <address@hidden> writes:
> > 
> > > Recent changes to stable-2.0 seem to cause a deadlock in scwm.  Here is 
> > > the last 10 frames of a backtrace.
> > 
> > I’m not sure if this is related but there’s this new error that has
> > started happening from time to time:
> > 
> [ removed ]
> 
> Hmm. Might be.  Andy noted this on #guile:
> 
> <wingo> one can reproduce easily
> <wingo> scheme@(guile-user)> (make-weak-value-hash-table )
> <wingo> $1 = #<weak-value-hash-table 0/31>
> <wingo> scheme@(guile-user)> (hash-set! $1 "foo" "bar")
> <wingo> $2 = "bar"
> <wingo> scheme@(guile-user)> (hash-set! $1 "foo" "baz")
> <wingo> [hang.]

A git bisect points to ecc9d1b54:

ecc9d1b547b21830f5ce4f1eaceb6b9dde44e5dc is the first bad commit
commit ecc9d1b547b21830f5ce4f1eaceb6b9dde44e5dc
Author: Andy Wingo <address@hidden>
Date:   Sun May 1 18:01:42 2011 +0200

    fix hash-set! in weak-value table from non-immediate to immediate
    
    * libguile/hashtab.c (set_weak_cdr, scm_hash_fn_set_x): If we have a
      weak-value hash table with a previous non-immediate value for a given
      key, and we are setting an immediate as the new value, we were not
      unregistering the disappearing link.  Fixed.

:040000 040000 2cc3212851bcb8b37a8c5f2aafa0f0d058298a36 
a0d3568613ce6d5d43755c113a1e00d3e7a9cf7f M      libguile
bisect run success

-Dale