Re: Race condition in threading code?

[Han-Wen Nienhuys]

Andy Wingo escreveu:
> Hi,
> 
> On Sat 16 Aug 2008 11:45, Han-Wen Nienhuys <address@hidden> writes:
> 
>> Julian Graham escreveu:
>>> Hmmm... I don't recall seeing those when I was writing that test
>>> suite.  Just to be clear, were you getting those errors before making
>>> your changes?
>> No, but some very unrelated changes made them go away again. 
> 
> I still get that error, having merged master into vm. Do you have other
> fixes?

Hi,

can we have some certainty that this 

> 
> The original error that you had, reflowed:
> 
> ERROR: srfi-18.test: thread-start!:
>   thread activates only after start
>    - arguments: ((syntax-error "memoization"
>                   "In file ~S, line ~S: ~A ~S in expression ~S."
>                   ("/home/lilydev/vc/guile/srfi/srfi-18.scm" 135
>                    "Bad binding" ct
>                     (let (ct (current-thread))
>                     address@hidden (or (hashq-ref thread-exception-handlers 
> ct)
>                           (hashq-set! thread-exception-handlers ct
>                     (list initial-handler))))) #f))
> 
> Bad binding with an address@hidden This would seem to indicate that a
> memoized cell was not marked, and was then swept/re-used.


x.test:

(define-module (test-suite test-srfi-18)
  #:use-module (test-suite lib)
  #:use-module (srfi srfi-18))

(iota 1000000)
(for-each (lambda (x)
 (display x) (newline)
 (gc) (gc)
 (with-test-prefix "thread-start!"

  (pass-if "thread activates only after start" 
    (let* ((started #f)
           (m (make-mutex 'thread-start-mutex))
           (t (make-thread (lambda () (set! started #t)) 'thread-start-1)))
      (and (not started) (thread-start! t) (thread-join! t) started))))

) (iota 1000))


...
[Thread 0xb7322b90 (LWP 10865) exited]
333
[New Thread 0xb7322b90 (LWP 10866)]
[Thread 0xb7322b90 (LWP 10866) exited]
334
[New Thread 0xb7322b90 (LWP 10867)]
[Thread 0xb7322b90 (LWP 10867) exited]
335
[New Thread 0xb7322b90 (LWP 10868)]


<hang forever>


The large allocation and the 2 (gc) calls ensure that this test itself does not 
trigger gcs.

The code exercised here appears to deadlock.  I would be suspect of other 
threading problems 
(race conditions) in this code as well.


^C
Program received signal SIGINT, Interrupt.
0x00110416 in __kernel_vsyscall ()
(gdb) bt
#0  0x00110416 in __kernel_vsyscall ()
#1  0x007f3ba5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x001c7453 in scm_pthread_cond_wait (cond=0x955c04c, mutex=0x95f2e90)
    at threads.c:1804
#3  0x001c79bd in block_self (queue=0xb7397690, 
    sleep_object=<value optimized out>, mutex=0x95f2e90, waittime=0x0)
    at threads.c:248
#4  0x001c8875 in fat_mutex_lock (mutex=0xb73976c0, timeout=0x0, 
    owner=0xb7f87a28, ret=0xbfee5348) at threads.c:1299
#5  0x001c8b6b in scm_lock_mutex_timed (m=0xb73976c0, timeout=0x204, 
    owner=0xb7f87a28) at threads.c:1331
#6  0x001c8d54 in fat_mutex_unlock (mutex=0xb73976c0, cond=0xb7397590, 
    waittime=0x0, relock=1) at threads.c:1449
#7  0x001c8e89 in scm_timed_wait_condition_variable (cv=0xb7397590, 
    mx=0xb73976c0, t=0x204) at threads.c:1626
#8  0x00171ab3 in scm_gsubr_apply (args=0x404) at gsubr.c:221
#9  0x001588f3 in scm_apply (proc=0xb7f87a60, arg1=0xb7f87fb0, args=0xb73970e8)
    at eval.i.c:1778
#10 0x0014a2b7 in ceval (x=0x404, env=0xb7397170) at eval.i.c:1360
#11 0x0014a4cd in ceval (x=0x95a3fc0, env=0xb7397170) at eval.i.c:358
#12 0x0014dfbb in ceval (x=0xb7366e38, env=0xb73977f0) at eval.i.c:609
#13 0x0014dfbb in ceval (x=0xb73613d0, env=0x95b7020) at eval.i.c:609
#14 0x0015a21d in scm_call_0 (proc=0x95b7988) at eval.c:3053


-- 
 Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen