On Thu, 2013-03-21 at 18:39 +0000, Martin Simmons wrote:

...

...

...

...

...

On Mon, 18 Mar 2013 21:41:42 +0100, Stelian Ionescu said:

I'd like to make a new release by this weekend, so please run the test suite on all available implementations.

There are two bugs in the LispWorks implementation of bt:join-thread. Firstly, mp:process-private-property only works on the current thread (the second argument is actually the default) and secondly the private properties are removed when the process exits.

Please use mp:process-property instead:

Thanks, committed. I think this feature should be part of the LW API, it's very useful.

On Sat, 2013-03-23 at 04:24 +0400, Anton Vodonosov wrote:

19.03.2013, 00:42, "Stelian Ionescu" sionescu@cddr.org:

...

I'd like to make a new release by this weekend, so please run the test suite on all available implementations.

I have run the tests on the following implementations*

• implementation names are computed by (asdf:implementation-identifier); ecl-12.12.1-unknown means the ECL 12.12.1 release, don't be confused by the "unknown' word.

---

Windows: sbcl-1.1.0.45-win-x86 OK sbcl-1.1.0.36.mswinmt.1201-284e340-win-x64 OK sbcl-1.1.0.36.mswinmt.1201-284e340-win-x86 OK abcl-1.1.0-fasl39-win-x64 HANGS ccl-1.8-f95-win-x86 OK ccl-1.8-f95-win-x64 OK ecl-12.12.1-ab933fa5-win-x86-bytecode FAILED-TESTS: bordeaux-threads-test.join-thread-return-value bordeaux-threads-test.current-thread-identity ecl-12.12.1-ab933fa5-win-x86-lisp-to-c FAILED-TESTS bordeaux-threads-test.join-thread-return-value bordeaux-threads-test.current-thread-identity bordeaux-threads-test.default-special-bindings bordeaux-threads-test.should-retrieve-thread-name bordeaux-threads-test.condition-variable bordeaux-threads-test.should-identify-threads-correctly bordeaux-threads-test.should-have-thread-interaction bordeaux-threads.interrupt-thread acl-9.0a-win-x86 OK

Linux: ccl-1.8-f95-linux-x86 OK ccl-1.9-f96-linux-x86 HANGS (not alwasy 2 times from 4 tries) sbcl-1.1.1-linux-x86 OK sbcl-1.1.3.12-b9691ef-linux-x86 OK cmu-snapshot-2013-03-a__20d_unicode_-linux-x86 HANGS (the issue I reported some time ago, it hangs and keeps printing lot of '.' symbols to the log) ecl-12.12.1-unknown-linux-x86-bytecode OK ecl-12.12.1-unknown-linux-x86-lisp-to-c FAILED-TESTS bordeaux-threads-test.join-thread-return-value bordeaux-threads-test.should-identify-threads-correctly bordeaux-threads.interrupt-thread bordeaux-threads-test.default-special-bindings bordeaux-threads-test.should-retrieve-thread-name bordeaux-threads-test.condition-variable bordeaux-threads-test.current-thread-identity bordeaux-threads-test.should-have-thread-interaction abcl-1.1.1-fasl39-linux-x86" HANGS

Thanks for the testing. I only use Linux/x86_64. I can reproduce the ABCL issue and I've notified its developers, but not the ones with CCL - I tried both 32bit and 64bit for many times without problems - nor with CMUCL, so I need more information. Can you interrupt the test and get stack traces ? As for ECL, I can't even compile it, I'll just report the problem. .

On Sat, 2013-03-23 at 09:57 +0400, Anton Vodonosov wrote:

23.03.2013, 05:57, "Stelian Ionescu" sionescu@cddr.org:

...

Thanks for the testing. I only use Linux/x86_64. I can reproduce the ABCL issue and I've notified its developers, but not the ones with CCL - I tried both 32bit and 64bit for many times without problems - nor with CMUCL, so I need more information. Can you interrupt the test and get stack traces ?

CCL stack trace:

(B79C0B5C) : 0 (%PROCESS-WAIT-ON-SEMAPHORE-PTR #<A Foreign Pointer [gcable] #x80875F0> 16777215 0 "semaphore wait" NIL) 431 (B79C0BA0) : 1 (WAIT-ON-SEMAPHORE #<CCL:SEMAPHORE #x1890308E> NIL "semaphore wait") 207 (B79C0BBC) : 2 (CONDITION-WAIT #<CCL:SEMAPHORE #x1890308E> #<RECURSIVE-LOCK "Anonymous lock" [ptr @ #x8089840] #x18903E7E>) 159 (B79C0BE8) : 3 (FUNCALL #'#<Anonymous Function #x18962E3E>) 671 (B79C0C10) : 4 (FUNCALL #'#<(:INTERNAL IT.BESE.FIVEAM::RUN-IT (IT.BESE.FIVEAM::RUN-TEST-LAMBDA (IT.BESE.FIVEAM::TEST-CASE)))>) 1095 (B79C0C78) : 5 (FUNCALL #'#<#<STANDARD-METHOD IT.BESE.FIVEAM::RUN-TEST-LAMBDA (IT.BESE.FIVEAM::TEST-CASE)>> #<TEST-CASE CONDITION-VARIABLE #x18902816>) 63 (B79C0C90) : 6 (FUNCALL #'#<#<STANDARD-METHOD IT.BESE.FIVEAM::RUN-RESOLVING-DEPENDENCIES (IT.BESE.FIVEAM::TEST-CASE)>> #<TEST-CASE CONDITION-VARIABLE #x18902816>) 199 (B79C0CA0) : 7 (FUNCALL #'#<(:INTERNAL IT.BESE.FIVEAM::RUN-TESTS (IT.BESE.FIVEAM::%RUN (IT.BESE.FIVEAM::TEST-SUITE)))>) 327 (B79C0CCC) : 8 (FUNCALL #'#<#<STANDARD-METHOD IT.BESE.FIVEAM::%RUN (IT.BESE.FIVEAM::TEST-SUITE)>> #<TEST-SUITE :BORDEAUX-THREADS #x18906F1E>) 239 (B79C0D00) : 9 (FUNCALL #'#<(:INTERNAL RUN)>) 727 (B79C0D2C) : 10 (RUN! :BORDEAUX-THREADS) 119 (B79C0D3C) : 11 (CALL-CHECK-REGS RUN! :BORDEAUX-THREADS) 247

CMUCL:

0: (UNIX::SIGINT-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFC68C)) 1: (UNIX::SIGINT-HANDLER 3 #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFC68C))[:EXTERNAL] 2: ("call_into_lisp+#xAB [#x8054FEF] ./lisps/cmucl-2013-03a/bin/lisp") 3: ("funcall3+#x32 [#x8054A82] ./lisps/cmucl-2013-03a/bin/lisp") 4: ("interrupt_handle_now+#xEC [#x8051A6C] ./lisps/cmucl-2013-03a/bin/lisp") 5: ("__kernel_rt_sigreturn+#x0 [#xB7FE5440] ") 6: (SLEEP 0.001) 7: ("LAMBDA NIL") 8: ((LABELS IT.BESE.FIVEAM::RUN-IT)) 9: ((METHOD IT.BESE.FIVEAM::RUN-TEST-LAMBDA NIL (IT.BESE.FIVEAM::TEST-CASE)) (#(5 7 6 3) . #()) #<unused-arg> #<IT.BESE.FIVEAM::TEST-CASE SHOULD-HAVE-THREAD-INTERACTION {5837A5C5}>) 10: ((METHOD IT.BESE.FIVEAM::RUN-RESOLVING-DEPENDENCIES NIL (IT.BESE.FIVEAM::TEST-CASE)) (#(2 0 3 3) . #()) #<unused-arg> #<IT.BESE.FIVEAM::TEST-CASE SHOULD-HAVE-THREAD-INTERACTION {5837A5C5}>) 11: ((FLET IT.BESE.FIVEAM::RUN-TESTS)) 12: ((METHOD IT.BESE.FIVEAM::%RUN NIL (IT.BESE.FIVEAM::TEST-SUITE)) (#(5 6 3) . #()) #<unused-arg> #<IT.BESE.FIVEAM::TEST-SUITE :BORDEAUX-THREADS {597B3A85}>) 13: ("DEFUN RUN") 14: (RUN! :BORDEAUX-THREADS)

...

As for ECL, I can't even compile it, I'll just report the problem.

ECL is easy to compile: confgiure; make; make install.

I know, but on my machine the latest release segfaults during compilation.

If you send me your ssh key, I can give you access to my machine, where these failures can be reproduced.

Will do.