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. Aborted [andre@localhost ~]$ If maxima-runtime-clisp is installed, then maxima works properly. Version-Release number of selected component (if applicable): maxima-5.9.2-13.fc5 How reproducible: always Steps to Reproduce: 1. Install maxima without maxima-runtime-clisp (which shouldn't be possible). Actual results: Nonfunctional maxima. Expected results: 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: Requires: maxima-runtime which is provided by any of maxima-runtime-gcl, maxima-runtime-clisp, maxima-cmucl, maxima-runtime-sbcl. 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.
Andre: 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? Rex: 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 /usr/lib/gcl-2.6.7/unixport/saved_ansi_gcl 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 > /usr/lib/gcl-2.6.7/unixport/saved_ansi_gcl > 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 ihs index. 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 comm="maxima" exe="/usr/lib/maxima/5.9.2/binary-gcl/maxima" And after # 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 maxima-runtime-gcl.
If it wasn't already clear from the comments here, only 2 known workarounds exist: 1. (not advisable) Disable selinux or 2. (preferred) Use a different maxima-runtime, like maxima-runtime-clisp or maxima-runtime-sbcl
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.