Re: [PPL-devel] Parma Polyhedra Library 0.10.1
Richard Guenther wrote:
On Tue, Apr 14, 2009 at 3:02 PM, Roberto Bagnara bagnara@cs.unipr.it wrote:
We are pleased to announce the availability of PPL 0.10.1, a new release of the Parma Polyhedra Library.
It seems to build and test ok on {i586,ia64,ppc,ppc64,s390,x86_64}-linux but I get
PASS: nnc_writepolyhedron1 /bin/sh: line 4: 29952 Segmentation fault ${dir}$tst FAIL: memory1 ====================================== 1 of 191 tests failed Please report to ppl-devel@cs.unipr.it ======================================
on s390x-linux. Does the testsuite stop after the first error?
Hi Richard.
The testsuite does not proceed after the first directory that gives an error. In your case, the `tests/Polyhedron' directory produced that error and the `tests/Grid' directory is the only subdirectory of `tests' that has not been tested because of that error.
If not, what is memory1 testing?
It tests the PPL features that allow to recover after an out-of-memory error, i.e., when std::bad_alloc is thrown. It does so by limiting the amount of memory available to the process, attempting some expensive computation, catching std:bad_alloc, and restart. The key function is this one:
bool guarded_compute_open_hypercube_generators(dimension_type dimension, unsigned long max_memory_in_bytes) { try { limit_memory(max_memory_in_bytes); compute_open_hypercube_generators(dimension); return true; } catch (const std::bad_alloc&) { nout << "out of virtual memory" << endl; return false; } catch (...) { exit(1); } // Should never get here. exit(1); }
From the fact that you observe this failure, I gather that the configure script found a version of GMP compiled with -fexceptions. Unfortunately, this is not always enough. For instance, on the Itanium the test fails because of the libunwind bug reported in
http://lists.gnu.org/archive/html/libunwind-devel/2008-09/msg00001.html
Hence the test is disabled if defined(__ia64). I don't know what the problem could be on s390x-linux. Do you know if there is an s390x-linux machine we can obtain access to for the purpose of debugging? Cheers,
Roberto
Hello,
* Roberto Bagnara wrote on Tue, Apr 14, 2009 at 06:58:01PM CEST:
Richard Guenther wrote:
It seems to build and test ok on {i586,ia64,ppc,ppc64,s390,x86_64}-linux but I get
PASS: nnc_writepolyhedron1 /bin/sh: line 4: 29952 Segmentation fault ${dir}$tst FAIL: memory1 ====================================== 1 of 191 tests failed Please report to ppl-devel@cs.unipr.it ======================================
on s390x-linux. Does the testsuite stop after the first error?
Are you saying that there were no 190 PASSes before that FAIL? If yes, that would be weird, and I'd be interested in the output of make check SHELL="/bin/sh -x"
and the make version used.
The testsuite does not proceed after the first directory that gives an error.
Why not recommend make -k check
then?
Cheers, Ralf
On Tue, Apr 14, 2009 at 6:58 PM, Roberto Bagnara bagnara@cs.unipr.it wrote:
Richard Guenther wrote:
On Tue, Apr 14, 2009 at 3:02 PM, Roberto Bagnara bagnara@cs.unipr.it wrote:
We are pleased to announce the availability of PPL 0.10.1, a new release of the Parma Polyhedra Library.
It seems to build and test ok on {i586,ia64,ppc,ppc64,s390,x86_64}-linux but I get
PASS: nnc_writepolyhedron1 /bin/sh: line 4: 29952 Segmentation fault ${dir}$tst FAIL: memory1 ====================================== 1 of 191 tests failed Please report to ppl-devel@cs.unipr.it ======================================
on s390x-linux. Does the testsuite stop after the first error?
Hi Richard.
The testsuite does not proceed after the first directory that gives an error. In your case, the `tests/Polyhedron' directory produced that error and the `tests/Grid' directory is the only subdirectory of `tests' that has not been tested because of that error.
Ok.
If not, what is memory1 testing?
It tests the PPL features that allow to recover after an out-of-memory error, i.e., when std::bad_alloc is thrown. It does so by limiting the amount of memory available to the process, attempting some expensive computation, catching std:bad_alloc, and restart. The key function is this one:
bool guarded_compute_open_hypercube_generators(dimension_type dimension, unsigned long max_memory_in_bytes) { try { limit_memory(max_memory_in_bytes); compute_open_hypercube_generators(dimension); return true; } catch (const std::bad_alloc&) { nout << "out of virtual memory" << endl; return false; } catch (...) { exit(1); } // Should never get here. exit(1); }
From the fact that you observe this failure, I gather that the configure script found a version of GMP compiled with -fexceptions. Unfortunately, this is not always enough.
Ah, I guess the script (incorrectly) assumes this because it uses the C++ bindings of GMP? Certainly our GMP (the C parts) are not built with -fexceptions. The configure detects
checking how to link with libgmp... /usr/lib64/libgmp.so checking how to link with libgmpxx... /usr/lib64/libgmpxx.so /usr/lib64/libgmp.so checking for the GMP library version 4.1.3 or above... yes checking size of mp_limb_t... 8 checking whether GMP has been compiled with support for exceptions... yes checking for __mpz_struct._mp_alloc... yes checking for __mpz_struct._mp_size... yes checking for __mpz_struct._mp_d... yes
the configure test for exceptions looks sane though. It might be that we indeed run into an unwinder bug.
For instance, on the Itanium the test fails because of the libunwind bug reported in
http://lists.gnu.org/archive/html/libunwind-devel/2008-09/msg00001.html
Hence the test is disabled if defined(__ia64). I don't know what the problem could be on s390x-linux.
After adding || defined(__s390x) all tests now pass (good enough for me - the test doesn't seem to be critical).
Do you know if there is an s390x-linux machine we can obtain access to for the purpose of debugging?
Unfortunately not.
Thanks, Richard.
participants (3)
-
Ralf Wildenhues -
Richard Guenther -
Roberto Bagnara