Red Hat Bugzilla – Bug 187647
maxima-runtime-gcl: Unrecoverable error: fault count too high
Last modified: 2007-11-30 17:11:29 EST
Description of problem:
It's possible to install maxima without maxima-runtime-clisp. However, the
former is totally nonfunctional without the latter: you can't even run maxima
from the command line without it:
[andre@localhost ~]$ maxima
Unrecoverable error: fault count too high.
If maxima-runtime-clisp is installed, then maxima works properly.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install maxima without maxima-runtime-clisp (which shouldn't be possible).
Should be required to install maxima-runtime-clisp as a dependency of maxima,
so it will work.
We're not forcing any particular runtime, and maxima only includes:
which is provided by any of maxima-runtime-gcl, maxima-runtime-clisp,
Now, we *have* seen problems with particular lisps and selinux. Which runtime
isn't working for you? (gcl?)
That's correct - I originally did a "yum install maxima maxima-gui" after FC5
came out, and it brought in maxima-runtime-gcl as a dependency, which doesn't
work for me.
Re-assigning to gcl.
Gerard, looks like a case of the gcl/selinux breakage that you mentioned on the
mailings list(s) awhile back.
Are you running SELinux?
If yes, do the following:
chcon -t :textrel_shlib_t /usr/lib/gcl-2.6.7/unixport/saved_ansi_gcl
Do gcl and maxima start now?
This does not seem a problem with the execstack bit, but with textrel
permission of selinux. I wonder what to do here.
Make the context change during the RPM build?
[root@localhost ~]# chcon -t :textrel_shlib_t
chcon: /usr/lib/gcl-2.6.7/unixport/saved_ansi_gcl: No such file or directory
There doesn't seem to be anything on my system remotely resembling this: I
searched for "unixport" and "saved_ansi_gcl".
(In reply to comment #5)
> [root@localhost ~]# chcon -t :textrel_shlib_t
> chcon: /usr/lib/gcl-2.6.7/unixport/saved_ansi_gcl: No such file or directory
Sorry, this should be /usr/lib/maxima/5.9.2/binary-gcl/maxima
However I checked this, changing the file context gives the error:
Error in CONDITIONS::CLCS-UNIVERSAL-ERROR-HANDLER [or a callee]: 4 is an illegal
Fast links are on: do (use-fast-links nil) for debugging
Broken at SYSTEM:SCH-FRS-BASE.
1 (Abort) Return to top level.
If I set SELinux to permissive, it works. The audit log
indicates that allow_execheap should be set to 1. I don't
know however how to do this on a file basis and not globally.
All I'm seeing in /var/log/audit/audit.log (with no selinux mods) is:
type=SYSCALL msg=audit(1144163146.004:1284): arch=40000003 syscall=125 per=40000
success=no exit=-13 a0=851f000 a1=130c000 a2=7 a3=982b000 items=0 pid=11984
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
# chcon -t textrel_shlib_t /usr/lib/maxima/5.9.2/binary-gcl/maxima
I can confirm that maxima then fails with with "CONDITIONS::CLCS-..." error as
GÃ©rard reported, with nothing new (no failures anyway) in audit.log
*** Bug 188202 has been marked as a duplicate of this bug. ***
Same problem with today's updates (5.9.3-1.fc5) for maxima, maxima-gui, and
If it wasn't already clear from the comments here, only 2 known workarounds exist:
1. (not advisable) Disable selinux
2. (preferred) Use a different maxima-runtime, like maxima-runtime-clisp or
It is probably best not to build maxima-runtime-gcl anymore.
There is however another workaround: start with
setarch i386 -X maxima -l gcl
To make this work on other archs one would possibly do:
setarch `arch` -X maxima -l gcl
I made the following change to the "maxima" script:
elif [ "$MAXIMA_LISP" = "gcl" ]; then
exec "setarch" `arch` "-X" "$maxima_image_base" -eval '(cl-user::run)' -f --
"$arg1" "$arg2" "$arg3" "$arg4" "$arg5" "$arg6" "$arg7" "$arg8" "$arg9"
I'll take the bug back now. (keeping gemi on cc:)
setarch workaround implemented in maxima-5.9.3-3.