Segfault loading draw.lisp (GCL ba ckend) — draw2d/draw3d/gr2d unusable on Debian /Ubuntu-packaged Maxima 5.49.0

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