Build on Fedora 38 fails at iclasp final link stage #1567
Labels
Comments
|
Coredump details : That core::lisp_error() stack trace repeats more than 100,000 times - it looks like infinite stack recursion ! Any ideas on how to fix / progress to a working build would be much appreciated . |
|
I'd suggest some sort of re-entry detector in core::lisp_error() ? ie. core::lisp_error() calls fboundp() which calls core::lisp_error() - this recursion needs to be detected and limited. |
|
Actually, I am building with latest binutils-2.42 in /usr/local/bin /usr/local/lib64, I will try re-building |
|
Yes, exactly the same error and coredump occur using either binutils v2.39-16 or binutils v2.42 . What Clang / LLVM + binutils version do you use for compiling ? The CFLAGS / CXXFLAGS / LDFLAGS I use are : The actual command that enters infinite recursion and coredumps, |
|
With this patch, infinite recursion and coredump is avoided, but unfortunately the build still fails , printing the message: , unfortunately not much help , but at least no coredump. Clasp is evidently a long way from being buildable / usable - good luck, I'll see how it has progressed in a year or so. |
|
|
|
Thanks for taking a look, Alex . The recursion path is documented in the "Coredump Details" comment above : The original version or core::lisp_error: Unconditionally calls cl::sym_error->fboundp() , which eventually calls The recursion occurs because the TYPE_ERROR call on line 70 expands to (exceptions.h, line 103) : which expands to ERROR, on line 69 of that file : which then recurses infinitely . I can provide many examples of the actual coredump files if desired . Why the lisp_error(datum, arguments) parameters, which print as : in my modified recursion-safe version, are not detected as unboundp() or nilp() , and , most importantly, How a compilation on Fedora Core 38 under its latest clang + llvm 16.0.6 can end up being so different What OS version + Clang/LLVM version do you normally build under ? Why is the result so different in my case |
|
Sorry for the delay, I have lots of other things to work on. We usually build (and test) on Ubuntu 22.04 (github's The immediate problem in your trace is that it segfaults while trying to load the function cell of a "symbol". That "symbol" is 6, which is not exactly a valid pointer. Given how Have you yet posted an untruncated backtrace? I don't see it. Is it possible for you to get one? This segfault isn't the underlying problem but I don't think I have enough information to guess what the underlying problem is. As a sidenote, we don't want to prevent all recursive error calls, since it's legitimate to signal an error from within an error handler. But we could make our depth check use a simple |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
A clear and concise description of what the bug is.
Building on Fedora Core 38 Linux (FC-38), x86_64, with :
o sbcl-2.4.2
o clang + LLVM v16.0.6
o glibc-2.37-18
o binutils-2.42 or 2.39-16
with :
$ ./koga 2>&1 | tee koga.log && ninja -C build 2>&1 | tee build/ninja.build.log
`
fails at iclasp link stage :
[534/539] Linking boehmprecise/iclasp
[534/539] Compiling clasp
[535/539] Linking boehmprecise/clasp to iclasp
`
A core-dump is suffered by iclasp.
See attached long stack-trace & coredump logs.
Expected behavior
A clear and concise description of what you expected to happen.
Building a Release Tagged GIT commit according to instructions in Wiki
(https://github.com/clasp-developers/clasp/wiki/Building-and-Installing-from-Source)
should succeed.
Actual behavior
A clear and concise description of what happened instead. This should include error messages and backtraces if there are any. If that would be more than a few dozen lines, please attach it in a file instead.
Code at issue
If the code is more than a few dozen lines, please attach a source file instead.
PLEASE SEE :
iclasp coredump log listing ( can attach full coredump xz file if requested) :
clasp.ninja.build.failure.iclasp.coredump.log.txt
ninja.build.log Stack-Traces:
clasp.ninja.build.failure.stacktrace.log.txt
Other steps to reproduce
If the problem cannot be reproduced from just a code sample, include other steps here.
Context
(clasp-cltl2:declaration-information 'optimize))I will investigate core-dump & link failure further, using :
$ strace -s8192 -f -e trace=execve ninja -C build,since Ninja's worst fault (IMHO) is lack of 'Verbose Mode' / print-all-commands option
( ninja-build/ninja#2378 ) .
The text was updated successfully, but these errors were encountered: