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

Jump to bottom

tests fail in 1-core VM #251

Closed
bmwiedemann opened this issue Oct 13, 2020 · 4 comments
Closed

tests fail in 1-core VM #251

bmwiedemann opened this issue Oct 13, 2020 · 4 comments
Labels
bug Label for issues or PR that indicate or resolve a bug. resolved-pending-release Label for issues that will be resolved in the next release.

Comments

@bmwiedemann
Copy link

While working on reproducible builds for openSUSE, I found that our libsemigroups-1.3.3 package fails its tests in a 1-core VM.

Steps to reproduce on openSUSE or Debian:

osc co openSUSE:Factory/libsemigroups && cd $_
osc build --noservice --vm-type=kvm -j1 --clean standard

test output:

 Congruence 041: 2-sided congruence constructed from type only . . . 250μs
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 test_all is a Catch v2.9.2 host application.
 Run with -? for options 

 Congruence 042: no winner
 -----------------------------------------------------------------------
 tests/test-cong.cpp:1414
 .......................................................................

 tests/test-cong.cpp:1418: FAILED:
   REQUIRE( cong.word_to_class_index({2, 2, 2, 2}) == 254 )
 due to unexpected exception with message:
   src/todd-coxeter.cpp:757:run_impl: there are infinitely many classes in the
   congruence and Todd-Coxeter will never terminate

 Congruence 042: no winner . . .
 =======================================================================
 test cases:    156 |    155 passed | 1 failed
 assertions: 263514 | 263513 passed | 1 failed
@james-d-mitchell
Copy link
Member

Thanks for the report @bmwiedemann, I have a pretty good idea what is causing this, and the fix should be straightforward, and I'll aim to make a release resolving this month.

@james-d-mitchell james-d-mitchell added the bug Label for issues or PR that indicate or resolve a bug. label Oct 16, 2020
@bmwiedemann
Copy link
Author

Please ping me when you have a patch. I can test it in our env as well (unless cherry-picking to 1.3.3 is too hard)

james-d-mitchell added a commit to james-d-mitchell/libsemigroups that referenced this issue Nov 6, 2020
@james-d-mitchell
cong: add max_threads mem fn
72e6e6c 
This allows setting the maximum number of threads to exceed the
hardware concurrency, in cases where this is required for tests to
pass. Resolves Issue libsemigroups#251.
james-d-mitchell added a commit to james-d-mitchell/libsemigroups that referenced this issue Nov 11, 2020
@james-d-mitchell
cong: add max_threads mem fn
d634c65 
This allows setting the maximum number of threads to exceed the
hardware concurrency, in cases where this is required for tests to
pass. Resolves Issue libsemigroups#251.
james-d-mitchell added a commit to james-d-mitchell/libsemigroups that referenced this issue Nov 11, 2020
@james-d-mitchell
cong: add max_threads mem fn
a773194 
This allows setting the maximum number of threads to exceed the
hardware concurrency, in cases where this is required for tests to
pass. Resolves Issue libsemigroups#251.
james-d-mitchell added a commit to james-d-mitchell/libsemigroups that referenced this issue Nov 11, 2020
@james-d-mitchell
cong: add max_threads mem fn
ad85662 
This allows setting the maximum number of threads to exceed the
hardware concurrency, in cases where this is required for tests to
pass. Resolves Issue libsemigroups#251.
james-d-mitchell added a commit that referenced this issue Nov 13, 2020
@james-d-mitchell
cong: add max_threads mem fn
0a11dd9 
This allows setting the maximum number of threads to exceed the
hardware concurrency, in cases where this is required for tests to
pass. Resolves Issue #251.
@james-d-mitchell james-d-mitchell added the resolved-pending-release Label for issues that will be resolved in the next release. label Nov 19, 2020
@james-d-mitchell
Copy link
Member

@bmwiedemann I believe I resolved this in v1.3.4, sorry I forgot to ping you earlier!

@bmwiedemann
Copy link
Author

I verified that it is fixed in 1.3.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Label for issues or PR that indicate or resolve a bug. resolved-pending-release Label for issues that will be resolved in the next release.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@bmwiedemann @james-d-mitchell