Segfault when using WeylGroup

[Clément Chenevière]

Hi,

My computer is on Ubuntu 24.04.4 LTS, and I built sage from sources (classical build, develop).

I encountered a segfault error when trying to create a Weyl Group via `WeylGroup(["A", 3])`. This used to work in the past, I used a lot WeylGroup without encountering that problem.

I rebuilt sage yesterday but the problem is still occurring. Surprisingly, when I start sage's python via `./sage --python` I do not encounter any problem.

How can I solve this problem and explore what's broken?

Attached is a minimal example in a text file.

Thanks in advance for the help!

Clément

[Mellvie]

Hi Clément,

On Wed Jul 15, 2026 at 5:06 PM CST, Clément Chenevière wrote:
> `WeylGroup(["A", 3])`. This used to work in the past, I used a lot
> WeylGroup without encountering that problem.
>
> I rebuilt sage yesterday but the problem is still occurring. Surprisingly,
> when I start sage's python via `./sage --python` I do not encounter any
> problem.

I think this might be caused by a mismatch between your freshly rebuilt
Sage and the old GAP workspace cache stored on your computer (like
~/.sage/gap )

The previous installation was not suited for the newly compiled version,so
when the new Sage loads it, it fails.

And sage --python works, because it likely creates a new temporary
workspace or loads lazily.

> How can I solve this problem and explore what's broken?

Remove the old GAP like this:
mv ~/.sage/gap ~/.sage/gap_bk
# if you do not need the old gap directory
# rm -rf ~/.sage/gap/


--
Mellvie

[Clément Chenevière]

Hi Mellvie,

Thank you for your very quick answer, and sorry for the delay in replying. I did move the old GAP as you suggested, but it did not seem to solve the problem. However, I explored a bit more : when I start sage from within my sage folder via the command `./sage`, the function for WeylGroup does not fail, whereas starting sage with `sage` and calling WeylGroup still leads to a segfault, while both are supposed to be the same version 10.10.beta5 of sage.

Moreover, when I move or delete the ~/sage/gap folder, it does not get created again as I start sage with `sage` and try `WeylGroup(["A", 3])`. The folder gets created when I start sage with `./sage` from within my sage folder and call the WeylGroup function. However, this does not solve the problem for WeylGroup when starting sage "normally" with `sage`. I also tried redoing `make build` to recompile sage but it did not solve my problem either.

If you need extra information, I'm happy to provide it!

Cheers,
Clément

[Mellvie]

Hi Clément,

On Tue Jul 21, 2026 at 7:56 AM CST, Clément Chenevière wrote:

> I did move the old GAP as you suggested, but it did not seem to solve the
> problem. However, I explored a bit more : when I start sage from within my
> sage folder via the command `./sage`, the function for WeylGroup does not
> fail, whereas starting sage with `sage` and calling WeylGroup still leads
> to a segfault, while both are supposed to be the same version 10.10.beta5
> of sage.
>
> Moreover, when I move or delete the ~/sage/gap folder, it does not get
> created again as I start sage with `sage` and try `WeylGroup(["A", 3])`.
> The folder gets created when I start sage with `./sage` from within my sage
> folder and call the WeylGroup function. However, this does not solve the

It seems they are using different GAP installations or workspaces.

> problem for WeylGroup when starting sage "normally" with `sage`. I also
> tried redoing `make build` to recompile sage but it did not solve my
> problem either.
>

When you rebuild the new sage, it is normally build for the new sage's
environment, but the old system-wide sage command may still use or point
to the old libraries like GAP.

These additional details are helpful.

For more exactly locating. We should firstly check out which sage you are
actually calling.
Run these commands to locate the sage:

```
which sage
# or
ls -l $(which sage)

```

These could figure out if the sage were really the same or which it
referred to.
And this command might help:

```
# it leads to GAP
sage --gap
# for your ./sage
./sage --gap

# and run this in the GAP prompt would show a list
GAPInfo.RootPaths;

```

> If you need extra information, I'm happy to provide it!

Could you paste the output of both sage and ./sage?

Just for reference, here is what I get on my machine when I run these
commands.
My output here:

```
> which sage
~/miniforge3/envs/sage/bin/sage
> ls -l $(which sage)
-rwxrwxr-x. 2 jiesi jiesi 42403 Nov 19 2025 /home/jiesi/miniforge3/envs/sage/bin/sage

> sage --gap
┌───────┐ GAP 4.14.0 of 2024-12-05
│ GAP │ https://www.gap-system.org
└───────┘ Architecture: 64
Configuration: gmp 6.3.0, GASMAN, readline
Loading the library and packages ...
Packages: GAPDoc 1.6.7, PrimGrp 3.4.4, SmallGrp 1.5.4, TransGrp 3.6.5
Try '??help' for help. See also '?copyright', '?cite' and '?authors'
gap> GAPInfo.RootPaths;
[ "/home/jiesi/.gap/", "/home/jiesi/miniforge3/envs/sage/lib/gap/", "/home/jiesi/miniforge3/envs/sage/share/gap/" ]
gap>

```

Based on what you find, we would get it fixed.

Cheers,

--
Mellvie

[Clément Chenevière]

Hi Mellvie,

Thanks again for your reply and your help!

Here is the output of the `which` commands:

>>> pc:~/sage$ which sage
/usr/local/bin/sage

>>> pc:~/sage$ ls -l $(which sage)
lrwxrwxrwx 1 root root 36 janv. 28  2024 /usr/local/bin/sage -> /home/ccheneviere/sage/venv/bin/sage

When I type `sage --gap` I get an error:

>>> pc:~$ sage --gap
usage: sage [-h] [-v] [-q] [--simple-prompt] [-V] [-n [{jupyter,jupyterlab}]]
            [-c [COMMAND]]
            [file ...]
sage: error: unrecognized arguments: --gap

When I do `./sage --gap` in my sage folder, I get the following:

>>> pc:~/sage$ ./sage --gap
 ┌───────┐   GAP 4.15.1 of 2025-10-18
 │  GAP  │   https://www.gap-system.org
 └───────┘   Architecture: x86_64-pc-linux-gnu-default64-kv10

 Configuration:  gmp 6.3.0, GASMAN, readline
 Loading the library and packages ...

 Packages:   GAPDoc 1.6.7, PrimGrp 4.0.1, SmallGrp 1.5.4, TransGrp 3.6.5

 Try '??help' for help. See also '?copyright', '?cite' and '?authors'
gap> GAPInfo.RootPaths;

[ "/home/ccheneviere/.gap/", "/home/ccheneviere/sage/local/lib/gap/",
  "/home/ccheneviere/sage/local/share/gap/" ]

If this helps, here are the relevant lines when I do ./configure:

>>> pc:~/sage$ ./configure
checking for [...]

## ----------------------------------------------------------------------- ##
## Build status for each package:                                          ##

## ----------------------------------------------------------------------- ##

[...]

gap:                            SPKG version 4.15.1 is already installed
gap3:                           experimental, use "./configure --enable-gap3" to install SPKG version 04jul17
gap_jupyter:                    no; optional, use "./configure --enable-gap_jupyter" to install SPKG version 0.9
gap_packages:                   optional, use "./configure --enable-gap_packages" to install SPKG version 4.15.1
[...]

Cheers,
Clément

[Mellvie]

Hi Clément,

Thanks for running those commands, the picture is now much clearer.

On Wed Jul 22, 2026 at 3:15 AM CST, Clément Chenevière wrote:
> Here is the output of the `which` commands:
>
>>>> pc:~/sage$ which sage
> /usr/local/bin/sage
>
>>>> pc:~/sage$ ls -l $(which sage)
> lrwxrwxrwx 1 root root 36 janv. 28 2024 /usr/local/bin/sage ->
> /home/ccheneviere/sage/venv/bin/sage

From this, it means the sage you run from anywhere (that is,the one in
your PATH) is not the new one you build.
It is a symbolic link pointing to `/home/ccheneviere/sage/venv/bin/sage`.
And the symlink was created back in January 2024.

>
> When I type `sage --gap` I get an error:
>
>>>> pc:~$ sage --gap
> usage: sage [-h] [-v] [-q] [--simple-prompt] [-V] [-n
> [{jupyter,jupyterlab}]]
> [-c [COMMAND]]
> [file ...]
> sage: error: unrecognized arguments: --gap
>

Well, this fails. The venv-entry-point script doesn't know what `--gap`
means.

> When I do `./sage --gap` in my sage folder, I get the following:
>
>>>> pc:~/sage$ ./sage --gap
> ┌───────┐ GAP 4.15.1 of 2025-10-18
> │ GAP │ https://www.gap-system.org
> └───────┘ Architecture: x86_64-pc-linux-gnu-default64-kv10
> Configuration: gmp 6.3.0, GASMAN, readline
> Loading the library and packages ...
> Packages: GAPDoc 1.6.7, PrimGrp 4.0.1, SmallGrp 1.5.4, TransGrp 3.6.5
> Try '??help' for help. See also '?copyright', '?cite' and '?authors'
> gap> GAPInfo.RootPaths;
> [ "/home/ccheneviere/.gap/", "/home/ccheneviere/sage/local/lib/gap/",
> "/home/ccheneviere/sage/local/share/gap/" ]
>

This works fine, and shows up the GAP 4.15.1. The `GAPInfo.RootPaths;`
command return the gap environment it relies on.


So here is how to fix it:

```
# just test this
/home/ccheneviere/sage/sage --gap
# if it is perfect, we can update the symlink to point to it.
sudo ln -sfn /home/ccheneviere/sage/sage /usr/local/bin/sage

```

If you prefer not to touch system directories, you can simply add an
alias to your shell configuration:

In your `~/.bashrc`, zsh is `~/.zshrc`
add this in the file

alias sage='~/sage/sage'

And run this or open a new terminal

source ~/.bashrc

This way ,whenever you type sage in a terminal, it will runs the same as
of `./sage`

>
> If this helps, here are the relevant lines when I do ./configure:
>
>>>> pc:~/sage$ ./configure
> checking for [...]
> ## -----------------------------------------------------------------------
> ##
> ## Build status for each package:
> ##
> ## -----------------------------------------------------------------------
> ##
> [...]
> gap: SPKG version 4.15.1 is already installed
> gap3: experimental, use "./configure
> --enable-gap3" to install SPKG version 04jul17
> gap_jupyter: no; optional, use "./configure
> --enable-gap_jupyter" to install SPKG version 0.9
> gap_packages: optional, use "./configure
> --enable-gap_packages" to install SPKG version 4.15.1
> [...]

The configure output you showed is just listing optional packages, they
aren't part of the problem, but everything looks fine there.

--
Mellvie

[Mellvie]

It was strange that I composed the last email and send it at 09:47 CST (
01:47 UTC), but it only arrived in my mailbox at 17:33 CST (09:33 UTC).
Over 7 hours later.

I almost supposed it had not reached the sage-support mailing list.


--
Mellvie

[Clément Chenevière]

Hi Mellvie,

Thank you for your help! I tried to read into the entry-point scripts to try to understand the problem. The "good" script `./sage` has a few comments at line 103 which mentions the previous longstanding recommended practice to symlink another file, which I think I simply followed, and the recommended procedure was apparently changed in the meantime.

As a reference, I put the link of the following message which seems related to my problem: https://groups.google.com/g/sage-release/c/GOGWk66zaCQ/m/M_jQiOjaAAAJ

I also include links to issues #33876 and #33787.

As you advised, I replaced the old symlink with a new one pointing at SAGE_ROOT/sage. However, as a last check, the comments in the script in ./sage mentions the following:

> # (The updated README.md and installation manual from Issue #33787 recommend to
> #  symlink the installed version of the src/bin/sage script instead.

Should we do `ln -sfn SAGE_ROOT/src/bin/sage  /somewhere_in_path`  instead of `ln -sfn SAGE_ROOT/sage /somewhere_in_path`?

Here are the details for the two files, as well as the end of the SAGE_ROOT/sage script:

```

>>> pc:~/sage$ ls -l src/bin/sage
-rwxrwxr-x 1 ccheneviere ccheneviere 42576 mars  20 10:58 src/bin/sage
>>> pc:~/sage$ ls -l sage
-rwxrwxr-x 1 ccheneviere ccheneviere 4894 févr. 25  2024 sage

>>> :~/sage$ cat sage
#!/bin/sh
[...]
# Run the actual Sage script
if [ -x "$SAGE_ROOT/src/bin/sage" ]; then
    exec "$SAGE_ROOT/src/bin/sage" "$@"
else
    echo >&2 "$0: no Sage installation found in \$SAGE_ROOT=$SAGE_ROOT"
    exit 1
fi
```

Thanks again for your help, everything is now working properly!

Cheers,
Clément

[Mellvie]

Hi Clément,

That's great, everything works properly now. Thank you for digging
deeper to the script comments and the upstream issues.

On Sat Jul 25, 2026 at 9:18 PM CST, Clément Chenevière wrote:
> Thank you for your help! I tried to read into the entry-point scripts to
> try to understand the problem. The "good" script `./sage` has a few
> comments at line 103

> <https://github.com/sagemath/sage/blob/develop/sage#L103> which mentions

> the previous longstanding recommended practice to symlink another file,
> which I think I simply followed, and the recommended procedure was
> apparently changed in the meantime.
>
> As a reference, I put the link of the following message which seems related
> to my problem:
> https://groups.google.com/g/sage-release/c/GOGWk66zaCQ/m/M_jQiOjaAAAJ
> I also include links to issues #33876

> <https://github.com/sagemath/sage/issues/33786> and #33787
> <https://github.com/sagemath/sage/issues/33787>.

You are right: the current recommended practice (as of Issue #33787, and
also mentioned in the sage script’s comments) is to symlink directly to
SAGE_ROOT/src/bin/sage for a system‑wide install, provided you also set
the SAGE_ROOT environment variable in your shell profile.

>
> As you advised, I replaced the old symlink with a new one pointing at
> SAGE_ROOT/sage. However, as a last check, the comments in the script in
> ./sage mentions the following:
>> # (The updated README.md and installation manual from Issue #33787
> recommend to
>> # symlink the installed version of the src/bin/sage script instead.
>
> Should we do `ln -sfn SAGE_ROOT/src/bin/sage /somewhere_in_path` instead
> of `ln -sfn SAGE_ROOT/sage /somewhere_in_path`?
>
> Here are the details for the two files, as well as the end of the
> SAGE_ROOT/sage script:
>
> ```
>>>> pc:~/sage$ ls -l src/bin/sage
> -rwxrwxr-x 1 ccheneviere ccheneviere 42576 mars 20 10:58 src/bin/sage
>>>> pc:~/sage$ ls -l sage
> -rwxrwxr-x 1 ccheneviere ccheneviere 4894 févr. 25 2024 sage


>>>> :~/sage$ cat sage
> #!/bin/sh
> [...]
> # Run the actual Sage script
> if [ -x "$SAGE_ROOT/src/bin/sage" ]; then
> exec "$SAGE_ROOT/src/bin/sage" "$@"
> else
> echo >&2 "$0: no Sage installation found in \$SAGE_ROOT=$SAGE_ROOT"
> exit 1
> fi
> ```

As you can see, the top‑level sage script (~/sage/sage) serves as a
convenient wrapper: it automatically sets SAGE_ROOT and then execs
src/bin/sage. So if you symlink to the wrapper, you don’t need to
manually export anything.

In your case, using a symlink to ~/sage/sage (as you did) works
perfectly and solves the segfault.

If you prefer to use src/bin/sage instead (it is also great), just:

Add this to the ~/.bashrc or ~/.zshrc :

export SAGE_ROOT=/home/ccheneviere/sage

Then update the symlink :

sudo ln -sfn /home/ccheneviere/sage/src/bin/sage /usr/local/bin/sage

>
> Thanks again for your help, everything is now working properly!

Thanks again for the precise report, I’m glad everything is working now!



--
Mellvie