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

Hi,

On 18/08/2026 15:33, Jean-Michel Sarlat 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?

I reported a similar (serious) error for the Debian package maxima 5.49.0+dsfg-5 that I can observed on Debian/Sid environment on loong64 arch:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=maxima&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious
On other architectures, it seems okay.

I would try with the latest maxima and gcl packages from Debian (they must be built from the Debian source material).

Cheers,
Jerome

> 
>    Thanks,
>    Jean-Michel Sarlat
> 
> 
> 
> _______________________________________________
> Maxima-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss



_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss