ASDF problem on second load of ECL

querent querent at yandex.com
Thu Feb 27 09:57:04 UTC 2020


Hi there,

I am just trying to use ECL for a little project of mine, but I have a problem.

Immediately after installation, things seem to work fine.  I can run things, produce executables, etc.

However, the second time I load ECL I get the error listed below.

Deleting .cache/common-lisp/ecl-16.1.3 removes the error, but of course the world gets recompiled every time I load something.  

And then again the next time I load ECL after that I get the error again. 

I am using Ubuntu 19.10.  I have tried compiling the development branch from gitlab (wouldn't be the first time Ubuntu ships with a buggy package when upstream is fine) but I get the same behaviour.  

I did try using restart 1. to increase the stack size, but I just keep getting the error until I get an error about being unable to increase the stack size anymore. 

The error is the same that Zhou Qianliang reported in January, but I'm not doing anything odd, just trying to start ecl for a second time. 

https://mailman.common-lisp.net/pipermail/ecl-devel/2020-January/011473.html

I have searched for the error message but not come up with anything much more than the above mailing list message. 


Error message: 

;; Loading #P"/usr/local/lib/ecl-16.1.3/asdf.fas"
An error occurred during initialization:
The slot ASDF/PLAN::STAMP in the object #<action-status

Condition of type: STACK-OVERFLOW
BINDING-STACK overflow at size 10240. Stack can probably be resized.
Proceed with caution.
Available restarts:

1. (CONTINUE) Extend stack size
2. (RETRY) Retry ASDF operation.
3. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration.
4. (RETRY) Retry completing compilation for #<package-inferred-system "asdf">.
5. (ACCEPT) Continue, treating completing compilation for #<package-inferred-system "asdf"> as having been successful.
6. (RETRY) Retry ASDF operation.
7. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration.
8. (CONTINUE) Ignore initialization errors and continue.
9. (ABORT) Quit ECL unsafely, ignoring all existing threads.

Top level in: #<process TOP-LEVEL 0x55b73cdd2f80>.
>


Thanks for any help you can give me.  I'm looking forward to using ECL, seems like a nice platform! 

--querent. 



More information about the ecl-devel mailing list