Skip to content

Conversation

@antonio-rojas
Copy link
Contributor

In flint 3.3, gr_mat_struct replaced the rows array with row stride [1], update hmod_mat_struct accordingly.

Also, in that case we can use upstream's nmod_mat_entry macro, which doesn't do any type checking.

Fixes #86

[1] flintlib/flint@25251b8

    
In flint 3.3, gr_mat_struct replaced the `rows` array with row stride [1], update hmod_mat_struct accordingly.
    
Also, in that case we can use upstream's nmod_mat_entry macro, which doesn't do any type checking.
    
Fixes JohnCremona#86
    
[1] flintlib/flint@25251b8
@JohnCremona
Copy link
Owner

Thanks for finding and fixing this. I have been away and will check it out tomorrow

@JohnCremona
Copy link
Owner

JohnCremona commented Jun 16, 2025

When I build eclib using this patch and flint-3.3 I get a segfault in tests/smattest1, specifically in line 1393 of libsrc/mat.cc.
mod_mat_entry(A,i,j) = (uscalar)posmod(M(i+1,j+1),ipr);
in the function mod_mat_from_mat() which creates a FLINT matrix from an eclib matrix. I don't know why this happens on my laptop when the checks on github pass.

NB smattest1 has scalar=32-bit int.

@antonio-rojas
Copy link
Contributor Author

When I build eclib using this patch and flint-3.3 I get a segfault in tests/smattest1, specifically in line 1393 of libsrc/mat.cc. mod_mat_entry(A,i,j) = (uscalar)posmod(M(i+1,j+1),ipr); in the function mod_mat_from_mat() which creates a FLINT matrix from an eclib matrix. I don't know why this happens on my laptop when the checks on github pass.

NB smattest1 has scalar=32-bit int.

That's the crash I get without patching and that this PR is supposed to fix - so it looks like some other code path needs to be fixed too. I can't reproduce it locally though, all tests pass for me.

@JohnCremona
Copy link
Owner

Thankss for the quick response. Let me check what I am doing after 12 days of holiday...

@JohnCremona
Copy link
Owner

I cannot understand what is happening. The code in flinterface.h was written by Fredrik and relies on knowledge of FLINT internals which I do not have, and which have changed. But the mystery is why it works for you and for github but not for me (ubuntu 24.04.2 LTS, gcc 13.3.0).

--OK I now see that despite rebuilding from scratch, the executables in tests/ are being linked with an older flint lib (/usr/local/lib/libflint.so.18) not the newly installed one /usr/local/lib/libflint.so.21.0.0. I don't know why, I did make distclean and ./configure after installing the new flint system-wide.

@JohnCremona
Copy link
Owner

Now when I rebuild eclib after putting --with-flint=/usr/local on the ./configure line, it works fine though ldd shows that the executables are still linked to the old libflint.so.18. So this is better but I am still not actually testing the new eclib code with the new flint. I will try deleting the older libflint completely and building again.

@JohnCremona
Copy link
Owner

All OK, sorry about the noise.

@JohnCremona JohnCremona merged commit 234a6d5 into JohnCremona:master Jun 16, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

segfaults with flint 3.3

2 participants