Skip to content

Prevent segfault on GF(2^e) dense matrix row/column swap #40291

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 25, 2025

Conversation

Biffo89
Copy link
Contributor

@Biffo89 Biffo89 commented Jun 23, 2025

There is currently a problem with n x 0 and 0 x n matrices over GF(2^e). When performing row or column swaps, a segmentation fault is produced. The underlying issue seems to be within the M4RI library. Although the existing library code already has checks for these, they seem to be failing. A simple example to reproduce the problem is:

sage: matrix.zero(GF(4),2,0).with_permuted_rows(Permutation([2,1]))

The issue may be avoided in Sage by only performing swaps on non-empty rows and columns. I have added a simple condition to the swap logic for matrix_gf2e_dense

Related issue raised in M4RI: malb/m4ri#32

📝 Checklist

  • The title is concise and informative.
  • The description explains in detail what this PR is about.
  • I have linked a relevant issue or discussion.
  • I have created tests covering the changes.
  • I have updated the documentation and checked the documentation preview.

⌛ Dependencies

None

Copy link

Documentation preview for this PR (built with commit 95979a0; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

@user202729
Copy link
Contributor

Although the existing library code already has checks for these, they seem to be failing.

where is this check currently performed? I think it would simplify the code to remove the check at that place.

also I think it's a good idea to add # see PR 40291 at these places

Copy link
Contributor

@vneiger vneiger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

@vneiger
Copy link
Contributor

vneiger commented Jun 23, 2025

Although the existing library code already has checks for these, they seem to be failing.

where is this check currently performed? I think it would simplify the code to remove the check at that place.

also I think it's a good idea to add # see PR 40291 at these places

I might be mistaken, but I read the initial comment as "these checks are within M4RI" (or M4RIE maybe?). In which case it may be worth raising the issue at the relevant repository.

@vneiger vneiger added s: positive review gsoc: 2025 Tag for GSoC2025 issues/PRs and removed s: needs review labels Jun 23, 2025
@Biffo89
Copy link
Contributor Author

Biffo89 commented Jun 24, 2025

Although the existing library code already has checks for these, they seem to be failing.

where is this check currently performed? I think it would simplify the code to remove the check at that place.
also I think it's a good idea to add # see PR 40291 at these places

I might be mistaken, but I read the initial comment as "these checks are within M4RI" (or M4RIE maybe?). In which case it may be worth raising the issue at the relevant repository.

This is correct, the check I've located is within M4RI, which M4RIE falls back to.

mzed_row_swap in mzed.h calls mzd_row_swap

mzd_row_swap in mzd.h adds a default argument startblock = 0 and calls _mzd_row_swap

The first line in _mzd_row_swap is

if ((rowa == rowb) || (startblock >= M->width)) { return; }

The construction for mzd_t *M seems like it should set width to 0, in which case startblock >= M->width should evaluate to 0 >= 0 and the function should exit early.

I will raise an issue in M4RI for this.

@vbraun vbraun merged commit e477b34 into sagemath:develop Jun 25, 2025
26 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gsoc: 2025 Tag for GSoC2025 issues/PRs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants