Discussion:
Bug#973443: src/init2.c:52: MPFR assertion failure
(too old to reply)
John Scott
2020-10-30 17:50:01 UTC
Permalink
Package: libmpfr6
Version: 4.1.0-3
Severity: normal
X-Debbugs-Cc:

I was fooling around with Arb and it seems that this program causes
an assertion failure in MPFR, although ASan and UBSan don't point to
any misusage by Arb. (Curiously if you change the numerical string
from "0" to "0.5" then Arb does segfault outright, but I think that's
unrelated.)

One can build the program below with -lflint-arb to link:
#include <arb.h>
#include <stdlib.h>
int main(void) {
arb_t x;
arb_init(x);
if(arb_set_str(x, "0", WORD_MAX)) {
exit(EXIT_FAILURE);
} else {
arb_printd(x, WORD_MAX);
arb_clear(x);
}
}

and this causes
../../src/init2.c:52: MPFR assertion failed: ((p) >= 1 && (p) <= ((mpfr_prec_t) ((((mpfr_uprec_t) -1) >> 1) - 256)))
Aborted

It seems this is related to the WORD_MAX limit in arb_printd(). Replacing
it with WORD_MAX/8 one gets (in GMP)
GNU MP: Cannot allocate memory (size=479903576292600072)
Aborted

-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmpfr6 depends on:
ii libc6 2.31-4
ii libgmp10 2:6.2.0+dfsg-6

libmpfr6 recommends no packages.

libmpfr6 suggests no packages.

-- no debconf information
Vincent Lefevre
2020-10-30 19:00:01 UTC
Permalink
Post by John Scott
I was fooling around with Arb and it seems that this program causes
an assertion failure in MPFR, although ASan and UBSan don't point to
any misusage by Arb. (Curiously if you change the numerical string
from "0" to "0.5" then Arb does segfault outright, but I think that's
unrelated.)
#include <arb.h>
#include <stdlib.h>
int main(void) {
arb_t x;
arb_init(x);
if(arb_set_str(x, "0", WORD_MAX)) {
exit(EXIT_FAILURE);
} else {
arb_printd(x, WORD_MAX);
arb_clear(x);
}
}
and this causes
../../src/init2.c:52: MPFR assertion failed: ((p) >= 1 && (p) <= ((mpfr_prec_t) ((((mpfr_uprec_t) -1) >> 1) - 256)))
Aborted
This is not a MPFR bug: a precision that is larger than MPFR_PREC_MAX
is provided. In the MPFR manual:

The “precision” is the number of bits used to represent the
significand of a floating-point number; the corresponding C data type is
‘mpfr_prec_t’. The precision can be any integer between ‘MPFR_PREC_MIN’
and ‘MPFR_PREC_MAX’. In the current implementation, ‘MPFR_PREC_MIN’ is
equal to 1.

Warning! MPFR needs to increase the precision internally, in order
to provide accurate results (and in particular, correct rounding). Do
not attempt to set the precision to any value near ‘MPFR_PREC_MAX’,
otherwise MPFR will abort due to an assertion failure. However, in
practice, the real limitation will probably be the available memory on
your platform, and in case of lack of memory, the program may abort,
crash or have undefined behavior (depending on your C implementation).
Post by John Scott
It seems this is related to the WORD_MAX limit in arb_printd(). Replacing
it with WORD_MAX/8 one gets (in GMP)
GNU MP: Cannot allocate memory (size=479903576292600072)
Aborted
This time, I assume that the MPFR precision is less than MPFR_PREC_MAX,
but this is still much too large for the available memory.

This looks like a user-side error. I suppose that in arb, WORD_MAX
is a technical limitation (like MPFR_PREC_MAX in MPFR), but other
limitations may be reached in practice (on 64-bit machines, the
available memory should be the real limitation, though various
technical limitations may be reached before you get an error on
the available memory).
--
Vincent Lefèvre <***@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Loading...