Re: Parma Polyhedra Library 0.10.1

[Richard Guenther <richard dot guenther at gmail dot com>]

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.