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