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

Checking for overflow in matrix_mod2_dense not working on OS X 10.12.6 #24190

Closed
koffie opened this issue Nov 10, 2017 · 11 comments
Closed

Checking for overflow in matrix_mod2_dense not working on OS X 10.12.6 #24190

koffie opened this issue Nov 10, 2017 · 11 comments

Comments

@koffie
Copy link

koffie commented Nov 10, 2017

With OS X 10.12.6, Xcode 9.1 (and the same happens when building with clang, #12426):

sage -t --long --warn-long 64.0 src/sage/matrix/matrix_mod2_dense.pyx  # Killed due to kill signal
...
...
...
sage: sig_on_count() # check sig_on/off pairings (virtual doctest) ## line 90 ##
0
sage: type(random_matrix(GF(2),2,2)) ## line 165 ##
<type 'sage.matrix.matrix_mod2_dense.Matrix_mod2_dense'>
sage: Matrix(GF(2),3,3,1) # indirect doctest ## line 168 ##
[1 0 0]
[0 1 0]
[0 0 1]
sage: matrix(GF(2),0,[]) * vector(GF(2),0,[]) ## line 177 ##
()
sage: MatrixSpace(GF(2), 2^30)(1) ## line 182 ##

The failing doctest was introduced at #23742

Component: linear algebra

Author: Jeroen Demeyer

Branch: 145f9df

Reviewer: Volker Braun

Issue created by migration from https://trac.sagemath.org/ticket/24190

@koffie koffie added this to the sage-8.1 milestone Nov 10, 2017
@jdemeyer
Copy link

comment:1

I'm currently building this on vbraun's testing machine. In the worst case, we just have to remove the test.

@jdemeyer
Copy link

comment:2

It seems that OS X simply doesn't support ulimit -v.

@jdemeyer
Copy link

@jdemeyer
Copy link

Commit: 145f9df

@jdemeyer
Copy link

Author: Jeroen Demeyer

@jdemeyer
Copy link

New commits:

145f9dfSkip test on systems without RLIMIT_AS support

@vbraun
Copy link
Member

vbraun commented Nov 13, 2017

Reviewer: Volker Braun

@vbraun
Copy link
Member

vbraun commented Nov 15, 2017

@embray
Copy link
Contributor

embray commented Jul 23, 2018

comment:7

I think this fix was incomplete, because it does not provide a workaround for the next two tests in the example:

            sage: import resource
            sage: if resource.RLIMIT_AS == getattr(resource, 'RLIMIT_RSS', None):
            ....:     # Skip this test if RLIMIT_AS is not properly
            ....:     # supported like on OS X, see Trac #24190
            ....:     raise RuntimeError("matrix allocation failed")
            ....: else:  # Real test
            ....:     MatrixSpace(GF(2), 2^30)(1)
            Traceback (most recent call last):
            ...
            RuntimeError: matrix allocation failed
            sage: MatrixSpace(GF(2), 1, 2^40).zero()
            Traceback (most recent call last):
            ...
            OverflowError: ...
            sage: MatrixSpace(GF(2), 2^40, 1).zero()
            Traceback (most recent call last):
            ...
            OverflowError: ...

The MatrixSpace(GF(2), 1, 2^40).zero() and so on still happily gobble up as much memory as they can if RLIMIT_AS was not set. See #25884 and #23979. In the latter, I dealt with the fact that setting RLIMIT_AS doesn't work on Cygwin, but in that case it raises a ValueError. I'm guessing, from this ticket, that on OSX the setrlimit call doesn't raise an exception, but doesn't actually work either.

I think we need a better solution for dealing with tests on systems where setting memory limits by the test runner doesn't work properly...

@embray
Copy link
Contributor

embray commented Jul 23, 2018

Changed commit from 145f9df to none

@embray
Copy link
Contributor

embray commented Jul 23, 2018

comment:8

I take it back--the other tests do immediately raise OverflowError as they should. Question is then why the MatrixSpace(GF(2), 2^30)(1) is being run at all on Cygwin. It shouldn't, and yet it seems it does...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants