Re: Segfault loading draw.lisp (GCL b ackend) — draw2d/draw3d/gr2d unusable on Debia n/Ubuntu-packaged Maxima 5.49.0

It works for me on GCL 2.7.1 git tag Version_2_7_2pre35 and current Maxima
from Git.

Am Di., 18. Aug. 2026 um 17:39 Uhr schrieb Jerome BENOIT via Maxima-discuss
<[email protected]>:

> 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
>

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