Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 405793 - sci-mathematics/maxima-5.26.0 stalls during testsuite
Summary: sci-mathematics/maxima-5.26.0 stalls during testsuite
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Science Mathematics related packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-25 17:42 UTC by Markus Walter
Modified: 2013-01-13 12:24 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
build log (build.log,704.02 KB, text/plain)
2012-02-25 17:42 UTC, Markus Walter
Details
emerge --info (info.txt,5.42 KB, text/plain)
2012-02-25 17:43 UTC, Markus Walter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Walter 2012-02-25 17:42:53 UTC
Created attachment 303191 [details]
build log

On my hardened ~amd64 machine with gcc-4.6.2 I'm unable to run the testsuite of maxima. It allways stalls for an infinite time. It does not create any load. All the processes are constantly sleeping.

The last line in the log is as follows:
Running tests in rtestnset: 

The process tree looks as follows:

/usr/bin/python2.7 /usr/bin/emerge -1 maxima
└─ [sci-mathematics/maxima-5.26.0] sandbox "/usr/lib64/portage/bin/ebuild.sh" test
   └─ /bin/bash /usr/lib64/portage/bin/ebuild.sh test
      └─ /bin/bash /usr/lib64/portage/bin/ebuild.sh test
         └─ make -j5 -j1 check
            └─ /bin/sh -c fail= failcom='exit 1'; \ for f in x $MAKEFLAGS; do \   case $f in \     *=* | --[!k]*);; \     *k*) failcom='fail=yes';; \   esac; \ done; \ dot_seen=no; \ target=`echo check-recursive | sed s/-recursive//`; \
               └─ /bin/sh -c fail= failcom='exit 1'; \ for f in x $MAKEFLAGS; do \   case $f in \     *=* | --[!k]*);; \     *k*) failcom='fail=yes';; \   esac; \ done; \ dot_seen=no; \ target=`echo check-recursive | sed s/-recursive//`; \
                  └─ make check
                     └─ /bin/sh -c echo "Running test suite with ecl..."; \ /bin/sh ../maxima-local --lisp=ecl --batch-string="run_testsuite();" < /dev/null
                        └─ /var/tmp/portage/sci-mathematics/maxima-5.26.0/work/maxima-5.26.0/src/binary-ecl/maxima -- --lisp=ecl --batch-string=run_testsuite();
                           └─ /var/tmp/portage/sci-mathematics/maxima-5.26.0/work/maxima-5.26.0/src/binary-ecl/maxima -- --lisp=ecl --batch-string=run_testsuite();
Comment 1 Markus Walter 2012-02-25 17:43:10 UTC
Created attachment 303193 [details]
emerge --info
Comment 2 Andrey Grozin gentoo-dev 2012-02-27 14:10:54 UTC
I see you use ecl. Have you tried some other lisps? ecl is very slow (only clisp is slower); sbcl or cmucl or gcl are much faster.
I cannot reproduce your problem. On my ~x86 box maxima runs its testsuite with all 6 lisps without problems.
One suspecious thing is hardened. In general, "hardened" and "lisp" always tend to contradict each other. Lisps tend to allocate some memory somewhere, to compile stuff on the fly into this memory, and to execute it immediately. This is a normal way of life for lisp. Usually, each small upgrade of the hardened stuff tends to break all lisps; later, lisps tend to recover somehow from this breakage; but by then, the hardened stuff change again, and all lisps are again completely broken.
If possible, it would be much more reasonable to run lisp applications on non-hardened computers (probably, guarded from the hostile internet by hardened ones). Why mix these very different lifestyles on a single computer?
Anyway, I cannot check this bug report, because I don't run hardened. I prefer to be able to have some work done on my laptop.
Comment 3 Markus Walter 2013-01-12 14:28:51 UTC
I retested this with 5.29.1 and it works just fine.
Comment 4 Andrey Grozin gentoo-dev 2013-01-13 12:24:08 UTC
OK thanks. Of course, I run tests for each version of maxima for all 6 lisps (I have gcl unmasked) on a ~x86 box; recently I got a new laptop, ~amd64, and also run tests on it for all 5 lisps (no cmucl on amd64). There are some failures on 32-bit ccl, all other combinations run tests fine. I have not seen your problem.