For the first issue, the number of shared objects a single process can map is limited by:

- max open file number (ulimit -n)
- sysctl max_map_count

I set them both to 65530, the program can run now.

Thank you again.


ZHUO Qingliang (KDr2,

On Sunday, January 5, 2020, 10:16:11 PM GMT+8, ZHUO Qingliang (KDr2) <> wrote:

Hi Marius Gerbershagen,

Thank you for your reply,

About the second issue, you are right, if I delete ~/.cache/common-lisp/ecl-16.1.3-unknown-linux-x64/usr/share/common-lisp/source/cl-asdf/build/asdf.fas, the issue disappears.


ZHUO Qingliang (KDr2,

On Sunday, January 5, 2020, 04:57:39 AM GMT+8, Marius Gerbershagen <> wrote:


> Hi list,
> I am sorry I didn't find an ECL-User mailing list, so I post this question here. If here is not the right place to ask this kind of question, please let me know.
> I wrote a simple GTK program using cl-gtk2-gtk, please see it here:
> After I installed the dependent packages using quicklisp,  I ran it with `ecl --load ecl-gtk.lisp`, then, ECL started to compile files. It compiled for about 5 hours, and emitted an error, here is the log:

The important parts of the log are the errors such as

(Error: "/tmp/ecl3258uX7y8Y.fas: failed to map segment from shared object")

I can't tell you exactly how to fix this, but it is clear that the
cl-gtk2-gtk system is compiling A HUGE NUMBER of files and also single
functions. This number might be simply too big for ECL to handle and the
above error a result of some limit on the number of shared libraries
that one can load imposed by the glibc or the kernel, I don't know.

> Then I run it again, it gave a different error:
> ```$ ecl --load ecl-gtk.lisp;;; Loading "/home/kdr2/Work/mine/DS-III/explore/common-lisp/ecl-gtk.lisp";;; Loading "/home/kdr2/quicklisp/setup.lisp";;; Loading #P"/usr/lib/x86_64-linux-gnu/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-OVERFLOWBINDING-STACK overflow at size 10240. Stack can probably be resized.Proceed with caution.Available restarts:
> 1. (CONTINUE) Extend stack size2. (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>.>
> ```

I have seen errors like this before when asdf was trying (and failing)
to replace itself with a newer version. You can check whether you have a
copy of a newer asdf in a place where asdf will search for its systems
and remove that copy. If you really need the new asdf, you need to
generate the asdf.lisp file containing all of asdf from the sources (see
the asdf documentation for how to do that), drop that in place of the
"contrib/asdf/asdf.lisp" file in the ECL sources and recompile ECL.

Best regards,
  Marius Gerbershagen