On Tue, Apr 14, 2009 at 6:58 PM, Roberto Bagnara <bagn...@cs.unipr.it> wrote:
> Richard Guenther wrote:
>>
>> On Tue, Apr 14, 2009 at 3:02 PM, Roberto Bagnara <bagn...@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-de...@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.
