This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 187647 - maxima-runtime-gcl: Unrecoverable error: fault count too high
maxima-runtime-gcl: Unrecoverable error: fault count too high
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: maxima (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
:
: 188202 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-02 05:22 EDT by Andre Robatino
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version: 5.9.3-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-29 19:20:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Andre Robatino 2006-04-02 05:22:51 EDT
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.
Comment 1 Rex Dieter 2006-04-02 08:04:31 EDT
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 15:36:50 EDT
  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 15:57:07 EDT
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 17:16:58 EDT
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?
Comment 5 Andre Robatino 2006-04-03 17:23:53 EDT
[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".
Comment 6 Gérard Milmeister 2006-04-03 17:34:24 EDT
(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.
Comment 7 Rex Dieter 2006-04-04 11:22:10 EDT
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-06 21:39:24 EDT
*** Bug 188202 has been marked as a duplicate of this bug. ***
Comment 9 Andre Robatino 2006-04-12 20:44:11 EDT
  Same problem with today's updates (5.9.3-1.fc5) for maxima, maxima-gui, and
maxima-runtime-gcl.
Comment 10 Rex Dieter 2006-04-12 21:27:10 EDT
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
Comment 11 Gérard Milmeister 2006-04-22 05:46:47 EDT
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 14:54:34 EDT
I'll take the bug back now. (keeping gemi on cc:)
Comment 13 Rex Dieter 2006-04-29 19:20:03 EDT
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.