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. Greetings.
ZHUO Qingliang (KDr2, http://kdr2.com)
On Sunday, January 5, 2020, 10:16:11 PM GMT+8, ZHUO Qingliang (KDr2) zhuoql@yahoo.com 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.
Greetings.
ZHUO Qingliang (KDr2, http://kdr2.com)
On Sunday, January 5, 2020, 04:57:39 AM GMT+8, Marius Gerbershagen marius.gerbershagen@gmail.com wrote:
Hi,
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:http://depot.kdr2.com/scrappy/202001/ecl-gtk.lisp
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:http://depot.kdr2.com/scrappy/202001/ecl-gtk.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:
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