Andy Wingo escreveu:
> Hi,
>
> On Sat 16 Aug 2008 11:45, Han-Wen Nienhuys <[EMAIL PROTECTED]> 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))
> [EMAIL PROTECTED] (or (hashq-ref
> thread-exception-handlers ct)
> (hashq-set! thread-exception-handlers ct
> (list initial-handler))))) #f))
>
> Bad binding with an [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
