Re: Segfault loading draw.lisp (GCL b ackend) — draw2d/draw3d/gr2d unusable on Debian/Ubunt u-packaged Maxima 5.49.0

Hi,

I have encountered similar problems with the debian maxima packages in
the last year. There are *several* possible causes. One which has not
been mentioned is that the maxima-share package requires build-essential
(Gcl uses the Gnu C compiler to compile things like `draw'). I just
checked on my debian testing installation and neither the maxima nor
maxima-share packages declare this as a dependency (try "apt-cache show
maxima" as a super-user or with sudo).

If you enter the following from the maxima command-line, it can give
more information about the specific cause in your case:

:lisp (load #p"/usr/share/maxima/5.49.0/share/draw/draw.lisp")

The colon (:) must be the first character on the command line.

Good luck,
Leo

On Tue, Aug 18 2026, Jean-Michel Sarlat <[email protected]> wrote:

> Hello,
>
>   I'm hitting a reproducible segfault when loading the draw package on the
> Debian/Ubuntu-packaged Maxima 5.49.0 (GCL backend). draw2d, draw3d, draw(),
> and gr2d/gr3d are all
>   unusable as a result, since they all trigger load(draw).
>
>   Environment:
>   - Ubuntu 26.04 LTS (Resolute Raccoon), x86_64
>   - Package: maxima 5.49.0+dsfg-2 (Debian/Ubuntu, maxima-share extra code)
>   - Lisp: GCL 2.7.1 (git tag Version_2_7_2pre7),
> /usr/lib/maxima/5.49.0/binary-gcl/maxima
>
>   Steps to reproduce:
>   $ maxima --batch-string='load(draw)$'
>
>   Observed:
>   loadfile: failed to load /usr/share/maxima/5.49.0/share/draw/draw.lisp
>    -- an error. To debug this try: debugmode(true);
>   Segmentation violation: c stack ok:signalling error
>
>   With debugmode(true), GCL's own signal handler catches the segfault and
> turns it into a catchable error rather than killing the process — but draw
> never actually finishes
>   loading, so draw2d/draw3d/draw()/gr2d remain undefined afterwards.
>
>   What I've checked:
>   - ulimit -s unlimited before starting maxima has no effect — this rules
> out the OS thread stack; it looks like GCL's own fixed-size internal
> control stack, baked into the
>   saved core image.
>   - Clearing ~/.maxima/binary and letting everything recompile from scratch
> doesn't help either.
>   - The Debian/Ubuntu maxima-share package ships only the .lisp sources for
> the draw module (draw.lisp and its dependents: gnuplot.lisp, picture.lisp,
> vtk.lisp,
>   draw-index.lisp, wbd.lisp) — no precompiled .fasl/.o. So GCL has to
> compile it from scratch on every load(draw), which seems to be exactly what
> triggers the crash — my
>   guess is the compiler overflows its C stack on this particular file,
> given its size/macro complexity.
>   - As a sanity check, I tried the maxima-sage package instead (Maxima
> 5.45.1, but built against ECL rather than GCL). Same source, no crash:
> load(draw), draw2d, draw3d, and
>   draw(scene1, scene2) with gr2d scenes all work fine there, once I
> installed libecl-dev, libgc-dev, libatomic-ops-dev and libffi-dev (needed
> for ECL's own on-the-fly C
>   compilation step). That strongly points to this being a GCL-specific
> limitation rather than a bug in draw.lisp itself.
>
>   Has this been reported before, and is there a known workaround short of
> switching Lisp backends — e.g. a way to raise GCL's control stack size for
> the saved Maxima image,
>   or a precompiled draw.fas that could be shipped with the package?
>
>   Thanks,
>   Jean-Michel Sarlat
>
> _______________________________________________
> Maxima-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

-- 
---
Best regards,
Dr Butler
_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss