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
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
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
If number of so files is the problem then try to build a bundle (ot even a monolithic bundle), then each library/all libraries will be in a single fas instead of a fasl-per-file.
On January 4, 2020 9:57:36 PM GMT+01:00, 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:
"/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
- Stack can probably be resized.Proceed with caution.Available
restarts:
- (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
-- Wysłane za pomocą K-9 Mail.
Thanks. But I am still curious about why the cl-gtk2-gtk lib is compiled every time I run this simple program, I think usually it will be compiled only one time and then stored into the cache dir for the following loading. I checked ~/.cache/common-lisp/ecl-16.1.3-unknown-linux-x64/home/kdr2/quicklisp/dists/quicklisp/software/, the compiled files (*.o and *.fas) are there, but it seems they are not used. Greetings.
ZHUO Qingliang (KDr2, https://kdr2.com)
On Monday, January 6, 2020, 01:59:48 AM GMT+8, Daniel Kochmański daniel@turtleware.eu wrote:
If number of so files is the problem then try to build a bundle (ot even a monolithic bundle), then each library/all libraries will be in a single fas instead of a fasl-per-file.
On January 4, 2020 9:57:36 PM GMT+01:00, 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:
"/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
- Stack can probably be resized.Proceed with caution.Available
restarts:
- (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
-- Wysłane za pomocą K-9 Mail.
ZHUO Qingliang (KDr2) writes:
Thanks. But I am still curious about why the cl-gtk2-gtk lib is compiled every time I run this simple program, I think usually it will be compiled only one time and then stored into the cache dir for the following loading. I checked~/.cache/common-lisp/ecl-16.1.3-unknown-linux-x64/home/kdr2/quicklisp/dists/quicklisp/software/, the compiled files (*.o and *.fas) are there, but it seems they are not used. Greetings.
compilation plans are computed by asdf; abstraction is so dense I'm afraid I can't tell why it is recompiled, only that it shouldn't (unless files in cl-gtk2-gtk files or one of its dependencies access time has changed in a meantime).
ZHUO Qingliang (KDr2, https://kdr2.com)
-- Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu
"Be the change that you wish to see in the world." - Mahatma Gandhi
-
Daniel Kochmański -
Marius Gerbershagen -
ZHUO Qingliang (KDr2)