possible hash deadlock with recent changes

possible hash deadlock with recent changes

[dsmich]

Recent changes to stable-2.0 seem to cause a deadlock in scwm.  Here is the last 10 frames of a backtrace.

-Dale

(gdb) bt
#0  0xb77fa424 in __kernel_vsyscall ()
#1  0xb734cf02 in __lll_lock_wait ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:142
#2  0xb734839b in _L_lock_728 () from /lib/i686/cmov/libpthread.so.0
#3  0xb73481c1 in __pthread_mutex_lock (mutex=0xb74e60a0)
    at pthread_mutex_lock.c:61
#4  0xb74d4737 in GC_lock () at pthread_support.c:1681
#5  0xb74c8b79 in GC_general_register_disappearing_link (link=0x8882e14, 
    obj=0x886be50) at finalize.c:156
#6  0xb75716eb in set_weak_cdr (data=0xbf9f5b18) at hashtab.c:783
#7  0xb74c74dc in GC_call_with_alloc_lock (fn=0xb75716a0 <set_weak_cdr>, 
    client_data=0xbf9f5b18) at finalize.c:925
#8  0xb7572b30 in scm_hash_fn_set_x (table=0x885f3f0, obj=0x89f2a30, 
    val=0x886be50, hash_fn=0xb7571050 <scm_ihash>, 
    assoc_fn=0xb7539820 <scm_sloppy_assoc>, closure=0x0) at hashtab.c:808
#9  0xb7572be7 in scm_hash_set_x (table=0x885f3f0, key=0x89f2a30, 
    val=0x886be50) at hashtab.c:1108
#10 0x080659c4 in ScmMakeColor (cn=0xbf9f5bf1 "rgb:5f5f/5f5f/5f5f", 
    perror_status=0x0) at color.c:230

Re: possible hash deadlock with recent changes

[Ludovic Courtès]

Hi,

<dsmich@roadrunner.com> 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:

--8<---------------cut here---------------start------------->8---
Testing /tmp/nix-build-1xsqvp6zcbqg4pxjmbfnf5dvzy7hn9k6-guile-disable-deprecated-disable-discouraged-2.0.1.41-22523.drv-0/build/meta/guile ...
with GUILE_LOAD_PATH=/tmp/nix-build-1xsqvp6zcbqg4pxjmbfnf5dvzy7hn9k6-guile-disable-deprecated-disable-discouraged-2.0.1.41-22523.drv-0/guile-2.0.1.41-22523/test-suite
Backtrace:
In ice-9/boot-9.scm:
 170: 2 [catch #t #<catch-closure 4ca9f80> ...]
In unknown file:
   ?: 1 [catch-closure]
In ice-9/futures.scm:
  95: 0 [process-futures]

ice-9/futures.scm:94:4: In procedure process-futures:
ice-9/futures.scm:94:4: In procedure module-lookup: Unbound variable: %futures-available
Running 00-initial-env.test
Running alist.test

Running future.test
ERROR: future.test: futures: make-future - arguments: ((abandoned-mutex-error "lock obtained on abandoned mutex"))
ERROR: future.test: futures: future - arguments: ((misc-error "mutex already locked by thread"))
ERROR: future.test: futures: true - arguments: ((misc-error "mutex already locked by thread"))
ERROR: future.test: futures: (+ 2 3) - arguments: ((misc-error "mutex already locked by thread"))
ERROR: future.test: futures: many - arguments: ((misc-error "mutex already locked by thread"))
ERROR: future.test: futures: touch several times - arguments: ((misc-error "mutex already locked by thread"))
ERROR: future.test: futures: nested - arguments: ((misc-error "mutex already locked by thread"))
ERROR: future.test: futures: multiple values - arguments: ((misc-error "mutex already locked by thread"))
ERROR: future.test: futures: no exception - arguments: ((misc-error "mutex already locked by thread"))
ERROR: future.test: futures: exception - arguments: ((misc-error "mutex already locked by thread"))

[...]

Running threads.test
ERROR: threads.test: parallel: 1 - arguments: ((misc-error "mutex already locked by thread"))
ERROR: threads.test: parallel: 1 2 - arguments: ((misc-error "mutex already locked by thread"))
ERROR: threads.test: parallel: 1 2 3 - arguments: ((misc-error "mutex already locked by thread"))
ERROR: threads.test: par-map: simple - arguments: ((misc-error "mutex already locked by thread"))
ERROR: threads.test: par-for-each: simple - arguments: ((misc-error "mutex already locked by thread"))
--8<---------------cut here---------------end--------------->8---

(From <http://hydra.nixos.org/build/1080016>.)

Ludo’.

Re: possible hash deadlock with recent changes

[dsmich]

---- "Ludovic Courtès" <ludo@gnu.org> wrote: 
> Hi,
> 
> <dsmich@roadrunner.com> 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.]


-Dale

Re: possible hash deadlock with recent changes

[dsmich]

---- dsmich@roadrunner.com wrote: 
> 
> ---- "Ludovic Courtès" <ludo@gnu.org> wrote: 
> > Hi,
> > 
> > <dsmich@roadrunner.com> 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 <wingo@pobox.com>
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

Re: possible hash deadlock with recent changes

[Andy Wingo]

On Sat 07 May 2011 16:58, <dsmich@roadrunner.com> writes:

> Recent changes to stable-2.0 seem to cause a deadlock in scwm.  Here
> is the last 10 frames of a backtrace.

Fixed.  Apologies for the long delay.

Regards,

Andy
-- 
http://wingolog.org/

Re: possible hash deadlock with recent changes

[dsmich]

---- Andy Wingo <wingo@pobox.com> wrote: 
> On Sat 07 May 2011 16:58, <dsmich@roadrunner.com> writes:
> 
> > Recent changes to stable-2.0 seem to cause a deadlock in scwm.  Here
> > is the last 10 frames of a backtrace.
> 
> Fixed.  Apologies for the long delay.

np!  Great Thankfulness is applied.

-Dale

Re: possible hash deadlock with recent changes

[Andy Wingo]

Greets,

On Sun 08 May 2011 16:34, ludo@gnu.org (Ludovic Courtès) writes:

> <dsmich@roadrunner.com> writes:
>
>> Recent changes to stable-2.0 seem to cause a deadlock in scwm.  Here is the last 10 frames of a backtrace.

These are fixed.

> I’m not sure if this is related

It's not :)

> but there’s this new error that has started happening from time to
> time:
>
> ice-9/futures.scm:94:4: In procedure process-futures:
> ice-9/futures.scm:94:4: In procedure module-lookup: Unbound variable: %futures-available

I haven't seen this.  Please start a new thread if it still happens, and
you have more info :)

Cheers,

Andy
-- 
http://wingolog.org/