Skip to content
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

[20241112] Compilation failure on armhf #81

Open
SnarkBoojum opened this issue Nov 25, 2024 · 3 comments
Open

[20241112] Compilation failure on armhf #81

SnarkBoojum opened this issue Nov 25, 2024 · 3 comments

Comments

@SnarkBoojum
Copy link
Contributor

I finally found some time to have a look at the eclib package in Debian - sorry I was away that long.

I updated it to 20241112, and checked it on armhf, since there were failures there last time. It fails, but the error message doesn't look very informative:

/bin/bash: line 1: 158066 Aborted                 ./${prog} < ./in_ntl/${prog}.in > ${prog}.testout 2> /dev/null
make[3]: *** [Makefile:1682: check_g0n] Error 134

Since the last started test seemed to be tmanin, I tried:

(sid_armhf-dchroot)jpuydt@amdahl:~/eclib-20241112/tests$ ./tmanin < ./in_ntl/tmanin.in > tmanin.testout 
Unable to open file ./newforms/x18 for newform output
Unable to open file ./smallnf/x18 for newform output
Unable to open file ./newforms/x15 for newform output
Unable to open file ./smallnf/x15 for newform output
Unable to open file ./newforms/x15 for newform output
Unable to open file ./smallnf/x15 for newform output
Unable to open file ./newforms/x30 for newform output
Unable to open file ./smallnf/x30 for newform output
Unable to open file ./newforms/x15 for newform output
Unable to open file ./smallnf/x15 for newform output
Unable to open file ./newforms/x45 for newform output
Unable to open file ./smallnf/x45 for newform output
terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 22) >= this->size() (which is 22)
Aborted

and indeed the directories newforms and smallnf don't exist... but that doesn't look like an arch-specific issue, so I'm a bit at a loss as to what the issue actually is.

@JohnCremona
Copy link
Owner

This is strange. True, some of the test programs require certain directories to exist. There are default names for these, which include "newforms" and "smallnf", which are used unless the environment variables NF_DIR and SNF_DIR are set to something else. In the test directory's Makefile (see tests/Makefile.am) these two are set to nftmp and snftmp respectively, and directories with these names are created before the tests run and deleted afterwards.

So there is something in the way you are testing things which are circumventing this: in your example, where you run tmanin by itself, it will indeed fail as you have not set those variables and the directories newforms and smallnf do not exist.

This does not, though, explain why the test failed while running "make check".

@tornaria
Copy link

I was hit by the same issue on i686 (32 bit).

The problem seems to be that you assume sizeof(long) >= 2*sizeof(int). This is true on x86_64 (where sizeof(int)==4 and sizeof(long)=8) but false on i686 (where sizeof(int)==sizeof(long)==4).

More specifically, in line https://github.com/JohnCremona/eclib/blob/master/libsrc/arith.cc#L384

  long P = a*a+b*b, Q = a*c+b*d, R = c*c+d*d, t=1;

you seem to be assuming that a and b are 32 bit and long P is 64 bit so the squaring does not overflow. In fact, a and b seem to have been casted to long from int somewhere else, ensuring they are 32 bit, but long will not be large enough to avoid overflow.

The actual crash in the report comes from modrat(0, 1073741789) returning 1073741789/0 instead of 0/1 (the vector is then normalized by the denominator, which begin unexpectedly 0 means looking for the first nonzero coordinate ends triggering out of range).

A possible workaround might be to use uint64_t instead of long, but I haven't tested it.

@JohnCremona
Copy link
Owner

Thanks for the detective work @tornaria . I will look at it after the holiday.

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

No branches or pull requests

3 participants