From mhasch-p5p@cozap.com

This is a bug report for perl from mhasch-p5p@​cozap.com,
generated with the help of perlbug 1.40 running under perl 5.26.0.

Dear Perl 5 Porters,

The release candidate 2 for perl-5.26.0 comes with Math​::BigRat
v0.2611 which is severely broken. Neither this version of
Math​::BigRat nor its current CPAN version v0.2612 should be
distributed with perl core.

The impact would be that code using Math​::BigRat for symbolic
math is likely to break, as Math​::BigRat objects will randomly
change their values dependent on calculations with other objects.
Paul Haffenden has first reported this in CPAN RT #121139.
https://rt.cpan.org/Ticket/Display.html?id=121139

Here is a code snippet demonstrating the problem​:

  my $a = Math​::BigRat->new('3/2');
  my $x = Math​::BigRat->new('2/3');
  my $y = $a;
  $y = $x * $y;
  print "BONK\n" if "$a" ne '3/2';

Note that Math​::BigRat has always been supporting copying
behaviour for assignments rather than simple reference assignment
so far. This is normally achieved by correctly implementing
'=' with the overload pragma. Application code relying on this
behaviour is bound to break with the new bug.

It can be worked around by replacing many assignments like
''$foo = $bar'' by ''$foo = $bar->copy'', but this in turn
breaks the level of abstraction provided by overloaded math
operators in the first place.

As the Math​::BigXXX family of modules is currently under active
development I expect we will soon have a fix for this problem.
In case of an emergency I'd rather have a Math​::BigRat version
without the latest bells and whistles in the Perl 5 core
distribution than something massively breaking existing code.
A version of Math​::BigRat known to work would be v0.260804,
as in the development track from perl-5.25.4 to perl-5.25.7.

It is somewhat important not to use an even earlier version,
since v0.260804 was the first one to cope with incompatible
changes in Math​::BigInt released at the same time. As the
modules of this family are being developed in parallel but
come in separate CPAN distributions, there is always a risk
to end up with incompatible versions after updates. Perl
core providing fairly recent ones will help to avoid older
iterations of that trap. (See also the discussion in
http​://blogs.perl.org/users/martin/2016/08/the-math-bigrat-trap.html
.)

Thank you for your trouble,
-Martin

Flags​:
  category=library
  severity=critical
  module=Math​::BigRat

Site configuration information for perl 5.26.0​:

Configured by martin at Wed May 31 12​:56​:17 CEST 2017.

Summary of my perl5 (revision 5 version 26 subversion 0) configuration​:
 
  Platform​:
  osname=linux
  osvers=3.2.0-4-amd64
  archname=x86_64-linux-thread-multi-ld
  uname='linux dewey 3.2.0-4-amd64 #1 smp debian 3.2.86-1 x86_64 gnulinux '
  config_args='-Dusedevel -Uversiononly -Dprefix=/opt/perl526t -Dusethreads -Duse64bitint -Duse64bitall -Duselongdouble -Dperladmin=none -Dusevfork=false -de'
  hint=recommended
  useposix=true
  d_sigaction=define
  useithreads=define
  usemultiplicity=define
  use64bitint=define
  use64bitall=define
  uselongdouble=define
  usemymalloc=n
  default_inc_excludes_dot=define
  bincompat5005=undef
  Compiler​:
  cc='cc'
  ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
  optimize='-O2'
  cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion=''
  gccversion='4.7.2'
  gccosandvers=''
  intsize=4
  longsize=8
  ptrsize=8
  doublesize=8
  byteorder=12345678
  doublekind=3
  d_longlong=define
  longlongsize=8
  d_longdbl=define
  longdblsize=16
  longdblkind=3
  ivtype='long'
  ivsize=8
  nvtype='long double'
  nvsize=16
  Off_t='off_t'
  lseeksize=8
  alignbytes=16
  prototype=define
  Linker and Libraries​:
  ld='cc'
  ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /lib64 /usr/lib64
  libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  libc=libc-2.13.so
  so=so
  useshrplib=false
  libperl=libperl.a
  gnulibc_version='2.13'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs
  dlext=so
  d_dlsymun=undef
  ccdlflags='-Wl,-E'
  cccdlflags='-fPIC'
  lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'

Locally applied patches​:
  RC2

@​INC for perl 5.26.0​:
  /opt/perl526t/lib/site_perl/5.26.0/x86_64-linux-thread-multi-ld
  /opt/perl526t/lib/site_perl/5.26.0
  /opt/perl526t/lib/5.26.0/x86_64-linux-thread-multi-ld
  /opt/perl526t/lib/5.26.0

Environment for perl 5.26.0​:
  HOME=/home/martin
  LANG=C
  LANGUAGE (unset)
  LC_CTYPE=en_US
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/opt/perl526t/bin​:/opt/perl524/bin​:/home/martin/bin​:/usr/local/bin​:/usr/bin​:/bin​:/usr/local/games​:/usr/games
  PERL_BADLANG (unset)
  SHELL=/bin/bash

From @iabyn

On Wed, May 31, 2017 at 07​:32​:07AM -0700, Martin Hasch wrote​:

# New Ticket Created by Martin Hasch
# Please include the string​: [perl #131410]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131410 >

This is a bug report for perl from mhasch-p5p@​cozap.com,
generated with the help of perlbug 1.40 running under perl 5.26.0.

-----------------------------------------------------------------
Dear Perl 5 Porters,

The release candidate 2 for perl-5.26.0 comes with Math​::BigRat
v0.2611 which is severely broken. Neither this version of
Math​::BigRat nor its current CPAN version v0.2612 should be
distributed with perl core.

Note that perl 5.26.0 was released yesterday evening

--
You live and learn (although usually you just live).

The RT System itself - Status changed from 'new' to 'open'

From mhasch-p5p@cozap.com

On Thu, Jun 01, 2017 at 03​:40​:21AM -0700, Dave Mitchell via RT wrote​:

On Wed, May 31, 2017 at 07​:32​:07AM -0700, Martin Hasch wrote​:

The release candidate 2 for perl-5.26.0 comes with Math​::BigRat
v0.2611 which is severely broken. Neither this version of
Math​::BigRat nor its current CPAN version v0.2612 should be
distributed with perl core.

Note that perl 5.26.0 was released yesterday evening

Yes, I realized that, it's a pity I didn't find out earlier.

The good news is that there is already a patch. Peter shouldn't
have too much trouble now to fix the issue and thus make it
into perl-5.26.1.

-Martin

From @pjacklam

Ouch, this is bad. I'll give this top priority.

As a side remark, I would like to have Math​::BigRat in the same distribution as Math​::BigInt and Math​::BigFloat as these three modules are so closely related.

Also, the fact that Math​::BigRat isa Math​::BigFloat, and Math​::BigFloat isa Math​::BigInt is causing never ending problems. Introducing Math​::BigReal and letting Math​::Big(Int|Float|Rat) be a subclass of Math​::BigReal would make maintenance much easier.

From mhasch-p5p@cozap.com

Peter,

On Fri, Jun 09, 2017 at 02​:11​:38AM -0700, (Peter J. Acklam) via RT wrote​:

As a side remark, I would like to have Math​::BigRat in the same
distribution as Math​::BigInt and Math​::BigFloat as these three modules
are so closely related.

This is a very good idea and will greatly help to avoid problems
like the one reported in rt.cpan.org #122018, say.

Also, the fact that Math​::BigRat isa Math​::BigFloat, and Math​::BigFloat
isa Math​::BigInt is causing never ending problems. Introducing
Math​::BigReal and letting Math​::Big(Int|Float|Rat) be a subclass of
Math​::BigReal would make maintenance much easier.

I would be delighted if you could make this work. Such a new
architecture might also make it easier to take advantage of
backends that implement more multiprecision functionality than
just integers and floating point numbers.

Let us not get distracted from quickly fixing the problem at
hand though. I think I already nailed it with the patch in
rt.cpan.org #121139, but I am not sure that it is complete.

-Martin