search

cosmos72 / stmx

High performance Transactional Memory for Common Lisp
http://stmx.org/
244 stars 14 forks source link

compilation problem on ECL #5

Closed avodonosov closed 11 years ago

avodonosov commented 11 years ago

stmx sometimes fails to compile on ECL

Here is the command which removes FASL files of stmx, and then runs ECL to ql:quickload stmx:

 rm -rf ~/.cache/common-lisp/ecl-13.5.1-unknown-linux-i686/home/testgrid/quicklisp/dists/quicklisp/software/stmx-stable-5bb5051b-git/ && rlwrap ./lisps/ecl-bin-13.5.1/bin/ecl -eval '(ql:quickload :stmx)' -eval '(quit)'
;;; Loading "/home/testgrid/quicklisp/setup.lisp"
;;; Loading #P"/home/testgrid/lisps/ecl-bin-13.5.1/lib/ecl-13.5.1/cmp.fas"
;;; Loading #P"/home/testgrid/lisps/ecl-bin-13.5.1/lib/ecl-13.5.1/asdf.fas"
To load "stmx":
  Load 1 ASDF system:
    stmx
; Loading "stmx"
[package stmx.lang]..
;;; Error:
;;;   in file thread.lisp, position 1836
;;;   at (EVAL-WHEN (COMPILE-TOPLEVEL) ...)
;;;   * The form (PROGN (DEFVAR *TESTED-JOIN-THREAD* NIL) (UNLESS *TESTED-JOIN-THREAD* (SETF *TESTED-JOIN-THREAD* T) (LET ((X (GENSYM))) (WHEN (EQ X (JOIN-THREAD (MAKE-THREAD (LAMBDA NIL X)))) (ADD-FEATURE 'BT.JOIN-THREAD-IS-SANE))))) was not evaluated successfully.
;;; Error detected:
;;; There is no support for this method on this implementation.An error occurred during initialization:
COMPILE-FILE-ERROR while compiling #<cl-source-file "stmx" "lang" "thread">.

This is ECL release 13.5.1 on linux.

cosmos72 commented 11 years ago

I cannot reproduce this problem. Even under stress test, STMX seems to loads correctly on 64-bit ECL. Maybe it happens only on 32-bit ECL, I will try that too

avodonosov commented 11 years ago

Have you tried to remove FASL files before compiling?

Because I only was able to reproduce this after removing FASL files. By the way, the error message "There is no support for this method on this implementation." is from bordeaux-threads.

cosmos72 commented 11 years ago

Yes, I am running this loop:

while ecl -eval '(ql:quickload :stmx)' -eval '(quit)'; do rm -rf ~/.cache/common-lisp/ecl-13.5.1-unknown-linux-x64/home/max/src/lisp/stmx; done

and until now it never failed... My local STMX sources are in /home/max/src/lisp/stmx, also linked from ~/quicklisp/local-projects/stmx

avodonosov commented 11 years ago

are you sure the 'ecl' process will return failure status code ?

cosmos72 commented 11 years ago

it seems so:

$ ecl -eval 'junk' -eval '(quit)' ;;; Loading "/home/max/quicklisp/setup.lisp" ;;; Loading #P"/usr/local/lib/ecl-13.5.1/cmp.fas" ;;; Loading #P"/usr/local/lib/ecl-13.5.1/asdf.fas" An error occurred during initialization: The variable JUNK is unbound.. $ echo $? 1

$ ecl -eval '7' -eval '(quit)' ;;; Loading "/home/max/quicklisp/setup.lisp" ;;; Loading #P"/usr/local/lib/ecl-13.5.1/cmp.fas" ;;; Loading #P"/usr/local/lib/ecl-13.5.1/asdf.fas" $ echo $? 0

As I said, I will try on 32-bit ECL too...

cosmos72 commented 11 years ago

Just reproduced, on 64-bit ECL. Now trying to pinpoint it...

cosmos72 commented 11 years ago

It seems to happen when FASL files for stmx dependencies (log4cl, bordeaux-threads...) exist already. Testing a fix

cosmos72 commented 11 years ago

Commit 4bc089cc5b29d086dcc5b5f992ead61747ce43e7 PARTIALLY fixes this bug. With it, loading STMX works, but test suite still has problems in certain cases: STMX test suite passes as long as you remove ALL FASL files before starting ECL. If instead bordeaux-threads FASL are present when starting ECL, loading STMX will work, but test suite will fail with 3 errors.

The reason is a known ECL bug triggered with bordeaux-threads 0.8.3, see: http://permalink.gmane.org/gmane.lisp.bordeaux-threads.devel/212 http://sourceforge.net/p/ecls/bugs/261/

The short explanation of the ECL bug is (quoted from links above):

There is no problem when bordeaux-threads is compiled for the first time, however thereafter loading from fasls will result in

Condition of type: BORDEAUX-MP-CONDITION There is no support for this method on this implementation.

It affects at least ECL 13.5.1 and ecl-12.12.1, allegedly fixed in git/CVS (see links above).

avodonosov commented 11 years ago

I see, so it was an ECL but

cosmos72 commented 11 years ago

ECL fixed this bug on 19 Jun 2013 with git commit 914ce253d1d9e52df684dfacc554167b3f100ce7 See ECL git repository http://sourceforge.net/p/ecls/ecl/ci/master/tree/

The correct solution is to upgrade ECL to a version released on 19 Jun 2013 or later.

A temporary workaround is to quit ECL, remove all cached FASL files from ~/.cache/common-lisp/ecl-*, start a new ECL and finally load STMX and its dependencies with (ql:quickload "stmx")