Bug 187647 - maxima-runtime-gcl: Unrecoverable error: fault count too high
Summary: maxima-runtime-gcl: Unrecoverable error: fault count too high
Alias: None
Product: Fedora
Classification: Fedora
Component: maxima
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
: 188202 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2006-04-02 09:22 UTC by Andre Robatino
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2006-04-29 23:20:03 UTC

Attachments (Terms of Use)

Description Andre Robatino 2006-04-02 09:22:51 UTC
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.
[andre@localhost ~]$

If maxima-runtime-clisp is installed, then maxima works properly.

Version-Release number of selected component (if applicable):

How reproducible:

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.

Comment 1 Rex Dieter 2006-04-02 12:04:31 UTC
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?)

Comment 2 Andre Robatino 2006-04-02 19:36:50 UTC
  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.

Comment 3 Rex Dieter 2006-04-02 19:57:07 UTC
Re-assigning to gcl.

Gerard, looks like a case of the gcl/selinux breakage that you mentioned on the
mailings list(s) awhile back.

Comment 4 Gérard Milmeister 2006-04-03 21:16:58 UTC

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?

Comment 5 Andre Robatino 2006-04-03 21:23:53 UTC
[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".

Comment 6 Gérard Milmeister 2006-04-03 21:34:24 UTC
(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
 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.

Comment 7 Rex Dieter 2006-04-04 15:22:10 UTC
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

Comment 8 Rex Dieter 2006-04-07 01:39:24 UTC
*** Bug 188202 has been marked as a duplicate of this bug. ***

Comment 9 Andre Robatino 2006-04-13 00:44:11 UTC
  Same problem with today's updates (5.9.3-1.fc5) for maxima, maxima-gui, and

Comment 10 Rex Dieter 2006-04-13 01:27:10 UTC
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

Comment 11 Gérard Milmeister 2006-04-22 09:46:47 UTC
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"

Comment 12 Rex Dieter 2006-04-26 18:54:34 UTC
I'll take the bug back now. (keeping gemi on cc:)

Comment 13 Rex Dieter 2006-04-29 23:20:03 UTC
setarch workaround implemented in maxima-5.9.3-3.

Note You need to log in before you can comment on or make changes to this bug.