[Sbcl-help] (no subject)

[Andrey G. Grozin]

A Gentoo user reports the problem compiling OpenAxiom with sbcl-1.1.17 and
1.1.16, see https://bugs.gentoo.org/show_bug.cgi?id=508990

; compiling (DEFUN |bfOR| ...)CORRUPTION WARNING in SBCL pid 5624(tid
140737353508608):
Memory fault at 0 (pc=0x100178c053, sp=0x7ffff6c8ec90)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
CORRUPTION WARNING in SBCL pid 5624(tid 140737353508608):
Memory fault at 40200066 (pc=0x100159ef30, sp=0x7ffff6c8e5a0)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
CORRUPTION WARNING in SBCL pid 5624(tid 140737353508608):
Memory fault at 40200066 (pc=0x100159ef30, sp=0x7ffff6c8dd10)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

(no restarts: If you didn't do this on purpose, please report it as a
bug.)

debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread
#<THREAD "main thread" RUNNING {1002F363E3}>:
Unhandled memory fault at #x40200066.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

(no restarts: If you didn't do this on purpose, please report it as a
bug.)
...

I don't use OpenAxiom myself, and cannot confirm this. FriCAS is compiled
successfully.

Andrey

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Sbcl-help mailing list
Sbcl...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

[Christophe Rhodes]

Hi,

"Andrey G. Grozin" <A.G.G...@inp.nsk.su> writes:

> A Gentoo user reports the problem compiling OpenAxiom with sbcl-1.1.17 and
> 1.1.16, see https://bugs.gentoo.org/show_bug.cgi?id=508990

I guess the user should be asked whether this is a new problem, and if
so, which sbcl version is the first to trigger this behaviour, or
whether something has changed in OpenAxiom to make this happen?
Isolating the problem to a particular change would definitely be helpful
in debugging.

Cheers,

Christophe

[Andrey G. Grozin]

On Tue, 29 Apr 2014, Игорь Пашев wrote:
> Could it be related to portage sandbox [1, 2] ?
> [1] https://bugs.gentoo.org/show_bug.cgi?id=376213
> [2] https://sourceforge.net/p/open-axiom/mailman/open-axiom-help/thread/CAAiZkiD5nnDeby1T0g8UankY...@mail.gmail.com/
Probably, it's the same problem.

sbcl happily compiles FriCAS (and maxima) in the sandbox. Is OpenAxiom
much larger than FriCAS?

Andrey

[Orivej Desh]

1. I can reproduce the problem. It stems from SBCL being run effectively
as "sbcl --eval ... < /dev/null". When SBCL enters debugger due to an
error in the build process, it reads EOF, exits with code 0, and the
build continues with this happening many times until finally SBCL
encounters memory fault. To fix the build process apply this to
config/open-axiom.m4:

@@ -333,4 +333,4 @@
sbcl)
axiom_quiet_flags='--noinform --noprint'
- axiom_eval_flags='--no-sysinit --no-userinit --eval'
+ axiom_eval_flags='--no-sysinit --no-userinit --disable-debugger --eval'
;;

and rebuild ./configure with ./build-setup.sh.

2. The first actual error is this:

make[2]: Entering directory '/var/tmp/portage/sci-mathematics/open-axiom-1.4.2/work/open-axiom-1.4.2/src/boot'
../../src/driver/open-axiom --execpath=../lisp/lisp --make --main="|AxiomCore|::|topLevel|"\
--system=../../x86_64-unknown-linux-gnu \
--prologue='(pushnew :open-axiom-boot *features*)' \
--output=strap/bootsys --load-directory=strap strap/utility.fasl strap/tokens.fasl strap/includer.fasl strap/scanner.fasl strap/pile.fasl strap/ast.fasl strap/parser.fasl strap/translator.fasl
Unhandled SB-INT:SIMPLE-FILE-ERROR in thread #<THREAD "main thread" RUNNING
{1002D149B3}>:
Couldn't load "strap/utility.fasl": file does not exist.

3. I'm going to investigate the cause of memory fault, but it should not
concern OpenAxiom or Gentoo.

[Gabriel Dos Reis]

On Tue, Apr 29, 2014 at 1:55 AM, Andrey G. Grozin <A.G.G...@inp.nsk.su> wrote:

On Tue, 29 Apr 2014, Игорь Пашев wrote:

Could it be related to portage sandbox [1, 2] ?
[1] https://bugs.gentoo.org/show_bug.cgi?id=376213

[2] https://sourceforge.net/p/open-axiom/mailman/open-axiom-help/thread/CAAiZkiD5nnDeby1T0g8UankYrRUsg4o0k7q7uSZB7Q4aHx_6OQ@mail.gmail.com/

Probably, it's the same problem.

sbcl happily compiles FriCAS (and maxima) in the sandbox. Is OpenAxiom much larger than FriCAS?

The error you report happens in the very early stage of building the Boot translator with just a few functions loaded.  The main OpenAxiom binary isn't built yet at that time.

For what it is worth, I can't reproduce the problem on Mac OS X or openSUSE.  So, it must be the sandbox feature as reported in the gentoo bug database.

What are the typical limits when -sandbox is in effect?

PS: I don't have access to a gentoo machine so it is hard for me to reproduce the issue.

-- Gaby

 

[Gabriel Dos Reis]

Orivej,

On Tue, Apr 29, 2014 at 1:43 AM, Orivej Desh <ori...@gmx.fr> wrote:

1. I can reproduce the problem. It stems from SBCL being run effectively
as "sbcl --eval ... < /dev/null". When SBCL enters debugger due to an
error in the build process, it reads EOF, exits with code 0, and the
build continues with this happening many times until finally SBCL
encounters memory fault.  To fix the build process apply this to
config/open-axiom.m4:

     @@ -333,4 +333,4 @@
          sbcl)
             axiom_quiet_flags='--noinform --noprint'
     -       axiom_eval_flags='--no-sysinit --no-userinit --eval'
     +       axiom_eval_flags='--no-sysinit --no-userinit --disable-debugger --eval'
             ;;

Thanks for the detective work.  I missed your message earlier.

Applied your addition to the 1.4.3 branch of OpenAxiom:

   http://sourceforge.net/p/open-axiom/code/HEAD/tree/releases/1.4.3/

 

[...]

3. I'm going to investigate the cause of memory fault, but it should not
concern OpenAxiom or Gentoo.

Please, let me know if you need me to run any test, or if you find anything.

Thanks,

-- Gaby

[Orivej Desh]

> > 1. I can reproduce the problem. It stems from SBCL being run effectively
> > as "sbcl --eval ... < /dev/null". When SBCL enters debugger due to an
> > error in the build process, it reads EOF, exits with code 0, and the
> > build continues with this happening many times until finally SBCL
> > encounters memory fault.

> Thanks for the detective work. I missed your message earlier.

My message "has been automatically rejected" from open-axiom-devel.

Anyway, its second point (on the first actual error), and conclusion in
the third were mistaken.

> > 3. I'm going to investigate the cause of memory fault, but it should not
> > concern OpenAxiom or Gentoo.

So far I found that although corruption happens when

../../src/driver/open-axiom --execpath=../lisp/lisp --output=strap/ast.fasl --compile --load-directory=strap /var/tmp/portage/sci-mathematics/open-axiom-1.4.2/work/open-axiom-1.4.2/src/boot/strap/ast.clisp

executes

../lisp/lisp --noinform --end-runtime-options --noprint --no-sysinit --no-userinit --end-toplevel-options -- --output=strap/ast.fasl --compile --load-directory=strap /var/tmp/portage/sci-mathematics/open-axiom-1.4.2/work/open-axiom-1.4.2/src/boot/strap/ast.clisp

in BUILDDIR/src/boot in the sandbox, the latter command by itself completes compilation with no error.