Debian GCL and FriCAS

[Waldek Hebisch]

I just heave build FriCAS using GCL from Debian 13. GCL identifies
as:

GCL (GNU Common Lisp) 2.6.14 Fri Jan 13 10:47:56 AM EST 2023 CLtL1 git: Version_2_6_15pre18

FriCAS builds OK, but running it shows serious problem. Namely
one may get error like:

>> System error:
Condition in FUNCALL [or a callee]: INTERNAL-SIMPLE-ERROR: File #pFRICAS/algebra/LODO1.o has been compiled for a restricted address space,
and can no longer be loaded in this heap.
You can recompile with :large-memory-model-p t,
or (setq compiler::*default-large-memory-model-p* t) before recompiling.

We had such problem earlier, but is showed up during build. Now
build goes on, but we get failures at runtime. One possible
workaround was to limit memory used by GCL, it probably still
works. I am not sure if we have better workaround. Maybe do what
the message says and define

(setq compiler::*default-large-memory-model-p* t)

--
Waldek Hebisch

[Camm Maguire]

Greetings, and thanks for your report!

The preferred solution to this is one of

1) (setq si::*code-block-reserve* (make-array 50000000 :element-type 'character :static t)
or whatever size in build image before build
2) export GCL_MEM_BOUND=29 to limit the build heap to 1G
3) (setq compiler::*default-large-memory-model-p* t)

The last is the least preferable as it incurs a 10% performance penalty.

The Debian fricas package does not seem to run into this, though it uses
gcl27, also in Debian testing. I would like both 2.6 and 2.7 to work at
the moment, but there does not seem any reason to prefer 2.6 at this
point.

Please note that I believe you also need the ANSI image for fricas,
which you can get with export GCL_ANSI=t for the gcl package. It is the
default for gcl27.

In case fricas supports parallel make, you might want to investigate the
other important GCL memory environment variable, export
GCL_MULTIPROCESS_MEMORY_POOL=$(pwd). This allows the sharing of one
designated heap size, either limited only by system memory or restricted
via GCL_MEM_BOUND, among many processes. Both axiom and acl2 make use
of this at present.

Finally, gcl27 has an enhanced signature discovery process that replaces
the older .fn file mechanism, though that is still supported. It may
also be worth investigating.

Take care,

Camm Maguire ca...@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

[Waldek Hebisch]

On Wed, Mar 04, 2026 at 02:54:11PM -0500, Camm Maguire wrote:
> Greetings, and thanks for your report!
>
> The preferred solution to this is one of
>
> 1) (setq si::*code-block-reserve* (make-array 50000000 :element-type 'character :static t)
> or whatever size in build image before build

We had

#+:gcl(progn (setq si::*code-block-reserve* "")(si::gbc t)(setq si::*code-block-reserve* (make-array 10000000 :element-type (quote character) :static t) si::*optimize-maximum-pages* t))

Replacing 10000000 by 50000000 fixes the problem (actually evan much
smaller increment seem to be enough). I am not sure how
big this should be. On my machine total size of .o files that
potentially may be loaded as reported by 'size -t' is 39384980. On
different architecture this may be bigger. Also, given file may
be loaded multiple times, so there is some possiblity of fragmentation.

> 2) export GCL_MEM_BOUND=29 to limit the build heap to 1G
> 3) (setq compiler::*default-large-memory-model-p* t)
>
> The last is the least preferable as it incurs a 10% performance penalty.
>
> The Debian fricas package does not seem to run into this, though it uses
> gcl27, also in Debian testing.

I saw no memory problem with version which describes itself as "2.7.1
git: Version_2_7_0".

> I would like both 2.6 and 2.7 to work at
> the moment, but there does not seem any reason to prefer 2.6 at this
> point.

I looked at this version as this is what Debian 13 user gets by
default (at least I got this version upgrading to current Debian).

> Please note that I believe you also need the ANSI image for fricas,
> which you can get with export GCL_ANSI=t for the gcl package. It is the
> default for gcl27.

I get the same test result regardless of if it is ANSI or CLtL image.
For completeness let me add that both give the following error:

draw(1/x, x = 0.0..2.0, adaptive == false)

Compiling function %C with type DoubleFloat -> DoubleFloat

>> System error:
Condition in FUNCALL [or a callee]: INTERNAL-SIMPLE-ERROR: Zero divisor.

Continuing to read the file...

After increasing reserved memory size it is the only problem that
I see.

This happened also with 2.6.14. Other problems with 2.6.14 are no
longer present. In 2.7.1 the above does not signal error, but resulting
graph is wrong, namely it looks as if the function was 0

> In case fricas supports parallel make, you might want to investigate the
> other important GCL memory environment variable, export
> GCL_MULTIPROCESS_MEMORY_POOL=$(pwd). This allows the sharing of one
> designated heap size, either limited only by system memory or restricted
> via GCL_MEM_BOUND, among many processes. Both axiom and acl2 make use
> of this at present.

I routinely use parallel make, now it seems to work without extra
settings, at least on my machines.

--
Waldek Hebisch

[Camm Maguire]

Greetings!

Waldek Hebisch <de...@fricas.org> writes:

> On Wed, Mar 04, 2026 at 02:54:11PM -0500, Camm Maguire wrote:
>> Greetings, and thanks for your report!
>>
>> The preferred solution to this is one of
>>
>> 1) (setq si::*code-block-reserve* (make-array 50000000 :element-type 'character :static t)
>> or whatever size in build image before build
>
> We had
>
> #+:gcl(progn (setq si::*code-block-reserve* "")(si::gbc t)(setq si::*code-block-reserve* (make-array 10000000 :element-type (quote character) :static t) si::*optimize-maximum-pages* t))
>
> Replacing 10000000 by 50000000 fixes the problem (actually evan much
> smaller increment seem to be enough). I am not sure how
> big this should be. On my machine total size of .o files that
> potentially may be loaded as reported by 'size -t' is 39384980. On
> different architecture this may be bigger. Also, given file may
> be loaded multiple times, so there is some possiblity of fragmentation.
>

Yes on all accounts. Getting this number exactly right is of course
impossible. New blocks can be allocated at any time, i.e. perhaps one
block in the compiling image, another for the user after loading the .o
files and just before image save in a fresh image. Please note that
only a small fraction of each .o file takes up space, specifically the
.text and .data sections and a few others. The key to each allocation
of course is that it be done before the heap grows over 2Gb.

I can confirm the last sentence with the fricas package in Debian 13,
built with its gcl27.

I confess I do not know much about these drawing routines, but would
love to fix this before 2.7.2 is released. Where to go from here?

>> In case fricas supports parallel make, you might want to investigate the
>> other important GCL memory environment variable, export
>> GCL_MULTIPROCESS_MEMORY_POOL=$(pwd). This allows the sharing of one
>> designated heap size, either limited only by system memory or restricted
>> via GCL_MEM_BOUND, among many processes. Both axiom and acl2 make use
>> of this at present.
>
> I routinely use parallel make, now it seems to work without extra
> settings, at least on my machines.

Without GCL_MULTIPROCESS_MEMORY_POOL being set to a writable directory,
each process will think it can access the total memory, either that
available on the system or that limited by GCL_MEM_BOUND. Of course
these processes will only allocate when needed, and may not do so, but
they could easily OOM if they are unaware of each other and there are no
bounds.

Take care,

[Waldek Hebisch]

On Thu, Mar 05, 2026 at 05:11:07PM -0500, Camm Maguire wrote:
> Greetings!
>
> Waldek Hebisch <de...@fricas.org> writes:
>
> > I get the same test result regardless of if it is ANSI or CLtL image.
> > For completeness let me add that both give the following error:
> >
> > draw(1/x, x = 0.0..2.0, adaptive == false)
> >
> > Compiling function %C with type DoubleFloat -> DoubleFloat
> >
> > >> System error:
> > Condition in FUNCALL [or a callee]: INTERNAL-SIMPLE-ERROR: Zero divisor.
> >
> > Continuing to read the file...
> >
> > After increasing reserved memory size it is the only problem that
> > I see.
> >
> > This happened also with 2.6.14. Other problems with 2.6.14 are no
> > longer present. In 2.7.1 the above does not signal error, but resulting
> > graph is wrong, namely it looks as if the function was 0
> >
>
> I can confirm the last sentence with the fricas package in Debian 13,
> built with its gcl27.
>
> I confess I do not know much about these drawing routines, but would
> love to fix this before 2.7.2 is released. Where to go from here?

AFAICS the core reason is that FriCAS expects that numeric errors
are trapped, in particular result of division by 0 is replaced by 0.

On command line in GCL I get:

(3) -> 1/0$DoubleFloat

(3) #<inf>
Type: DoubleFloat

Using other Lisps I get:

(3) -> 1/0$DoubleFloat

>> System error:
arithmetic error DIVISION-BY-ZERO signalled
Operation was (/ 1.0 0.0).

This is not exactly to problem, but is closely related. Trace shows
that evaluating the function at 0 in GCL produces 1.7976931348623158E308,
while in other Lisp I get 0.

Simpler example is:

fP := MakeFloatCompiledFunction(Fraction(Polynomial(Integer)))
ff := makeFloatFunction(1/x, 'x)$fP
ff(0)

(8) #<inf>
Type: DoubleFloat
while FriCAS expects catchable exception.

At Lisp level this we have something like:

)lisp (DEFUN ffoo (x) (DECLARE (DOUBLE-FLOAT x)) (|c_to_rf| (/ 1 x)))

)lisp (FFOO 0.0d0)

Value = #<inf>

while other Lisp-s produce exception. |c_to_rf| is FriCAS helper
function which drops small imaginary part and converts the result
to DOUBLE-FLOAT. It is probably irrelevant to the problem, I get
the same results just using '(/ 1 x)'.

Let me add that normally FriCAS calls 'COMPILE' to compile the function,
but both compiled and interpreted case are used by FriCAS.

--
Waldek Hebisch

[Camm Maguire]

Greetings!

Yes, floating point exceptions are off by default in GCL, but can be
enabled to taste:


COMPILER>(si::break-on-floating-point-exceptions :floating-point-overflow t)

(:FLOATING-POINT-OVERFLOW)

COMPILER>(si::break-on-floating-point-exceptions :floating-point-overflow t)

(:FLOATING-POINT-OVERFLOW)

COMPILER>(si::break-on-floating-point-exceptions :floating-point-overflow nil)

NIL

COMPILER>(si::break-on-floating-point-exceptions :division-by-zero t)

(:DIVISION-BY-ZERO)

COMPILER>

Please let me know if that clears it up or if problems persist.

(GCL uses IEEE *hardware* floating point exceptions for this.
Unfortunately, the trend among some newer cpu architectures, like arm
and riscv64, deliberately do not support traps at this level....)

Take care,

Waldek Hebisch <de...@fricas.org> writes:

[Waldek Hebisch]

On Mon, Mar 09, 2026 at 03:03:54PM -0400, Camm Maguire wrote:
> Greetings!
>
> Yes, floating point exceptions are off by default in GCL, but can be
> enabled to taste:
>
>
> COMPILER>(si::break-on-floating-point-exceptions :floating-point-overflow t)
>
> (:FLOATING-POINT-OVERFLOW)
>
> COMPILER>(si::break-on-floating-point-exceptions :floating-point-overflow t)
>
> (:FLOATING-POINT-OVERFLOW)
>
> COMPILER>(si::break-on-floating-point-exceptions :floating-point-overflow nil)
>
> NIL
>
> COMPILER>(si::break-on-floating-point-exceptions :division-by-zero t)
>
> (:DIVISION-BY-ZERO)
>
> COMPILER>
>
> Please let me know if that clears it up or if problems persist.
>
> (GCL uses IEEE *hardware* floating point exceptions for this.
> Unfortunately, the trend among some newer cpu architectures, like arm
> and riscv64, deliberately do not support traps at this level....)

That solves problem for 2.7.1. With 2.6.14 and 2.15pre that I have
I still get errors, both in Lisp expample that I gave and in draw
command. Maybe my 2.15pre is too old.

BTW, there is also a different problem that I overlooked before.
Sequence of command:

x +-> if x < 0 then -x else x
abs1 := %
(x,y) +-> abs1(x) > abs1(y)
sort(%,[3,9,-4,10,-3,-1,-9,5])

produce no result and no error message. When I do

)lisp (si::use-fast-links nil)
)set break break

I get into GCL debugger:

Error:
Signalled by |*1;ANONYMOUSFUNCTION;1;FRAME0;INTERNAL|.

Condition in |*1;anonymousFunction;1;frame0;internal| [or a callee]: INTERNAL-SIMPLE-PROGRAM-ERROR: NIL [or a callee] requires more than zero arguments.

Broken at SYSTEM::BREAK-LEVEL. Type :H for Help.
1 Return to top level.

I get longish backtrace, shorthened it looks like:

#0 INVOKE-DEBUGGER {loc0=#<conditions::internal-simple-program-error.0>} [ihs=106]
#1 *1;anonymousFunction;1;frame0;internal {} [ihs=104]
#2 FN-GET {loc0=#<function 0000000001d04d70>,loc1=compiler::fun} [ihs=103]
#3 LOCAL-FUN-OBJ {loc0=#<function 0000000001d04d70>} [ihs=102]
#4 LOCAL-FUN-P {loc0=#<function 0000000001d04d70>} [ihs=101]
#5 COERCE-TO-FUNID {loc0=#<function 0000000001d04d70>} [ihs=100]
...
#60 T1EXPR {loc0=(defun |*2;anonymousFunction;0;frame0;internal| (#:g0 #:g1 |envArg|) ...)} [ihs=45]
#61 COMPILE-FILE1 {loc0=#P"/tmp/gazonk_3645744_0.lsp",loc1=#<@00000000035F5140>,loc2=#P"/tmp/gazon...} [ihs=44]
#62 COMPILE-FILE2 {loc0=#P"/tmp/gazonk_3645744_0.lsp",loc1=nil,loc2=nil,loc3=nil,loc4=nil} [ihs=43]
#63 COMPILE-FILE {loc0=#P"/tmp/gazonk_3645744_0.lsp",loc1=(t),loc2=(t t),loc3=(((style-warning . ...} [ihs=42]
#64 COMPILE {loc0=|*2;anonymousFunction;0;frame0;internal|,loc1=(nil),loc2=nil} [ihs=41]
#65 compile_defun {loc0=|*2;anonymousFunction;0;frame0;internal|,loc1=(defun |*2;anonymousFunction...} [ihs=40]

so the trouble is deep inside GCL COMPILE. AFAICS
"/tmp/gazonk_3645744_0.lsp" is empty. The function
'|*2;anonymousFunction;0;frame0;internal|' corresponds to FriCAS
code:

(x,y) +-> abs1(x) > abs1(y)

which gets translated to Lisp code:

(DEFUN
|*2;anonymousFunction;6;frame0;internal|
(#1=#:G2 #2=#:G3 |envArg|)
(>
(SPADCALL #1# '(#<function 0000000001d0f1e0>))
(SPADCALL #2# '(#<function 0000000001d0f6f0>))))

I see a little irreqularity, that is using sbcl I get new gensyms
on each run, using gcl I get the same name of gensyms (I do not
know if this matters). Otherwise the code look OK for me.

--
Waldek Hebisch