From @andk

bisect

It started to fail with v5.21.7-259-g819b139 but when that one was
reverted in v5.21.7-435-gdf3c16d it remained broken.

The brokenness only occurs for perls compiled with -Duselongdouble.

sample report

http​://www.cpantesters.org/cpan/report/49fefdde-a699-11e4-a2b8-12678971dd2f

perl -V

Summary of my perl5 (revision 5 version 21 subversion 8) configuration​:
  Commit id​: 819b139
  Platform​:
  osname=linux, osvers=3.16.0-4-amd64, archname=x86_64-linux-ld
  uname='linux k83 3.16.0-4-amd64 #1 smp debian 3.16.7-ckt2-1 (2014-12-08) x86_64 gnulinux '
  config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/perl/v5.21.7-259-g819b139/127e -Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  use64bitint=define, use64bitall=define, uselongdouble=define
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2',
  optimize='-O2 -g',
  cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
  ccversion='', gccversion='4.9.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-strong -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/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
  libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
  perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  libc=libc-2.19.so, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.19'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector-strong'

Characteristics of this binary (from libperl)​:
  Compile-time options​: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
  PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP
  PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV
  PERL_USE_DEVEL USE_64_BIT_ALL USE_64_BIT_INT
  USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE
  USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME
  USE_LONG_DOUBLE USE_PERLIO USE_PERL_ATOF
  Built under linux
  Compiled at Feb 19 2015 05​:33​:53
  @​INC​:
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.21.7-259-g819b139/127e/lib/site_perl/5.21.8/x86_64-linux-ld
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.21.7-259-g819b139/127e/lib/site_perl/5.21.8
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.21.7-259-g819b139/127e/lib/5.21.8/x86_64-linux-ld
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.21.7-259-g819b139/127e/lib/5.21.8
  .

--
andreas
v5.21.7-259-g819b139

From @tonycoz

On Wed Feb 18 23​:20​:57 2015, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

bisect
------
It started to fail with v5.21.7-259-g819b139 but when that one was
reverted in v5.21.7-435-gdf3c16d it remained broken.

The brokenness only occurs for perls compiled with -Duselongdouble.

It was reverted in v5.21.7-436-g13c59d4 not v5.21.7-435-gdf3c16d.

I can't reproduce the failure in v5.21.9-22-gf266b74 (blead) or in v5.21.7-436-g13c59d4.

I built both with​:

./Configure -Dprefix=/home/tony/perl/blead -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g

Tony

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

From @andk

On Sun, 22 Feb 2015 20​:00​:00 -0800, "Tony Cook via RT" <perlbug-followup@​perl.org> said​:

tc> On Wed Feb 18 23​:20​:57 2015, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

bisect
------
It started to fail with v5.21.7-259-g819b139 but when that one was
reverted in v5.21.7-435-gdf3c16d it remained broken.

The brokenness only occurs for perls compiled with -Duselongdouble.

tc> It was reverted in v5.21.7-436-g13c59d4 not v5.21.7-435-gdf3c16d.

Thanks for the corection.

tc> I can't reproduce the failure in v5.21.9-22-gf266b74 (blead) or in v5.21.7-436-g13c59d4.

Quite surprising for me.

tc> I built both with​:

tc> ./Configure -Dprefix=/home/tony/perl/blead -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g

Thanks for trying. I cannot explain. I still see the fail with
v5.21.9-24-gf4460c6.

Can you compare you system with

http​://www.cpantesters.org/cpan/report/cf50d412-a699-11e4-9e0e-9e908971dd2f

?

--
andreas

From @tonycoz

On Sun Feb 22 22​:17​:05 2015, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

On Sun, 22 Feb 2015 20​:00​:00 -0800, "Tony Cook via RT" <perlbug-
followup@​perl.org> said​:

tc> On Wed Feb 18 23​:20​:57 2015,
tc> andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

bisect
------
It started to fail with v5.21.7-259-g819b139 but when that one was
reverted in v5.21.7-435-gdf3c16d it remained broken.

The brokenness only occurs for perls compiled with -Duselongdouble.

tc> It was reverted in v5.21.7-436-g13c59d4 not v5.21.7-435-gdf3c16d.

Thanks for the corection.

tc> I can't reproduce the failure in v5.21.9-22-gf266b74 (blead) or in
tc> v5.21.7-436-g13c59d4.

Quite surprising for me.

tc> I built both with​:

tc> ./Configure -Dprefix=/home/tony/perl/blead -Uversiononly -Dusedevel
tc> -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g

Thanks for trying. I cannot explain. I still see the fail with
v5.21.9-24-gf4460c6.

Can you compare you system with

http​://www.cpantesters.org/cpan/report/cf50d412-a699-11e4-9e0e-
9e908971dd2f

A newer compiler did the trick.

Tony

From @tonycoz

On Mon Feb 23 16​:54​:54 2015, tonyc wrote​:

On Sun Feb 22 22​:17​:05 2015, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

On Sun, 22 Feb 2015 20​:00​:00 -0800, "Tony Cook via RT" <perlbug-
followup@​perl.org> said​:

tc> On Wed Feb 18 23​:20​:57 2015,
tc> andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

bisect
------
It started to fail with v5.21.7-259-g819b139 but when that one was
reverted in v5.21.7-435-gdf3c16d it remained broken.

The brokenness only occurs for perls compiled with -Duselongdouble.

tc> It was reverted in v5.21.7-436-g13c59d4 not v5.21.7-435-gdf3c16d.

Thanks for the corection.

tc> I can't reproduce the failure in v5.21.9-22-gf266b74 (blead) or in
tc> v5.21.7-436-g13c59d4.

Quite surprising for me.

tc> I built both with​:

tc> ./Configure -Dprefix=/home/tony/perl/blead -Uversiononly -Dusedevel
tc> -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g

Thanks for trying. I cannot explain. I still see the fail with
v5.21.9-24-gf4460c6.

Can you compare you system with

http​://www.cpantesters.org/cpan/report/cf50d412-a699-11e4-9e0e-
9e908971dd2f

A newer compiler did the trick.

The problem is occuring in S_outside_integer() which is reporting the bottom of the range in this code​:

  # an attempt to detect former effects of RT#79576, bug itself present between
  # 0.08191 and 0.08209 inclusive (fixed in 0.08210 and higher)
  my $stringifiable = 0;

  for my $i (0.. $#$bindattrs) {

  $stringifiable++ if ( length ref $bind->[$i][1] and is_plain_value($bind->[$i][1]) );

(the 0) as being out of range because Perl_isinfnan() is returning true.

If I revert 415b66b which introduced this check the test passes.

If I use the nv value as a memory reference (eg. to dump the raw content of the NV) the tests pass.

Just dumping the content of the nv as a number makes no difference.

Here's the generated code with some comments​:

0000000000000280 <S_outside_integer>​:
  280​: 48 83 ec 18 sub $0x18,%rsp
; %rdi is the sv parameter, get sv_flags in %edx
; checking SvOK()
  284​: 8b 57 0c mov 0xc(%rdi),%edx
  287​: f6 c6 ff test $0xff,%dh
  28a​: 75 24 jne 2b0 <S_outside_integer+0x30>
; check type == SVt_REGEXP
  28c​: 80 fa 08 cmp $0x8,%dl
  28f​: 74 1f je 2b0 <S_outside_integer+0x30>
; or that the flags match
  291​: 89 d1 mov %edx,%ecx
; zero %eax to return false if needed
  293​: 31 c0 xor %eax,%eax
  295​: 81 e1 ff c0 00 01 and $0x100c0ff,%ecx
  29b​: 81 f9 0a 00 00 01 cmp $0x100000a,%ecx
; jump to SvOK() true handling
  2a1​: 74 0d je 2b0 <S_outside_integer+0x30>
; jump to false return
  2a3​: eb 05 jmp 2aa <S_outside_integer+0x2a>
  2a5​: 0f 1f 00 nopl (%rax)
  2a8​: dd d8 fstp %st(0)
  2aa​: 48 83 c4 18 add $0x18,%rsp
  2ae​: c3 retq
  2af​: 90 nop
; const NV nv = SvNV_nomg(sv); test SVf_NOK
  2b0​: 80 e6 02 and $0x2,%dh
; if not SVf_NOK go call sv_2nv_flags()
  2b3​: 74 4b je 300 <S_outside_integer+0x80>
; it's NOK, load from SvNVX
  2b5​: 48 8b 07 mov (%rdi),%rax
  2b8​: db 68 30 fldt 0x30(%rax)
; call to sv_2nv_flags() end up here
  2bb​: 48 83 ec 10 sub $0x10,%rsp
  2bf​: d9 c0 fld %st(0)
  2c1​: db 3c 24 fstpt (%rsp)
  2c4​: db 7c 24 10 fstpt 0x10(%rsp)
  2c8​: e8 00 00 00 00 callq 2cd <S_outside_integer+0x4d>
  2c9​: R_X86_64_PC32 Perl_isinfnan+0xfffffffffffffffc
  2cd​: 84 c0 test %al,%al
  2cf​: 5a pop %rdx
  2d0​: 59 pop %rcx
; if ne return true
  2d1​: 75 d7 jne 2aa <S_outside_integer+0x2a>
; start of other tests
  2d3​: d9 05 00 00 00 00 flds 0x0(%rip) # 2d9 <S_outside_integer+0x59>
  2d5​: R_X86_64_PC32 .LC5+0xfffffffffffffffc
  2d9​: b8 01 00 00 00 mov $0x1,%eax
  2de​: db 2c 24 fldt (%rsp)
  2e1​: d9 c9 fxch %st(1)
  2e3​: df e9 fucomip %st(1),%st
  2e5​: 77 c1 ja 2a8 <S_outside_integer+0x28>
  2e7​: db 2d 00 00 00 00 fldt 0x0(%rip) # 2ed <S_outside_integer+0x6d>
  2e9​: R_X86_64_PC32 .LC6+0xfffffffffffffffc
  2ed​: d9 c9 fxch %st(1)
  2ef​: df e9 fucomip %st(1),%st
  2f1​: dd d8 fstp %st(0)
  2f3​: 0f 97 c0 seta %al
  2f6​: 48 83 c4 18 add $0x18,%rsp
  2fa​: c3 retq

  2fb​: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
  300​: 31 f6 xor %esi,%esi
  302​: e8 00 00 00 00 callq 307 <S_outside_integer+0x87>
  303​: R_X86_64_PC32 Perl_sv_2nv_flags+0xfffffffffffffffc
; nv is on the
  307​: eb b2 jmp 2bb <S_outside_integer+0x3b>
  309​: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)

Tony

From @ribasushi

On 02/25/2015 07​:07 AM, Tony Cook via RT wrote​:

On Mon Feb 23 16​:54​:54 2015, tonyc wrote​:

The problem is occuring in S_outside_integer() which is reporting the bottom of the range in this code​:

# an attempt to detect former effects of RT#79576, bug itself present between
# 0.08191 and 0.08209 inclusive (fixed in 0.08210 and higher)
my $stringifiable = 0;

for my $i (0.. $#$bindattrs) {

 $stringifiable\+\+ if \( length ref $bind\->\[$i\]\[1\] and is\_plain\_value\($bind\->\[$i\]\[1\]\) \);

(the 0) as being out of range because Perl_isinfnan() is returning true.

While this issue has not been resolved, it will likely disappear from
the BBC because the code in question is removed in [1] and will ship to
CPAN in the next several hours. Please take steps to not lose track of
this issue going towards 5.22.

Cheers

[1] Perl5/DBIx-Class@cff17b977

From @tonycoz

On Fri Mar 20 03​:31​:17 2015, rabbit-p5p@​rabbit.us wrote​:

On 02/25/2015 07​:07 AM, Tony Cook via RT wrote​:

On Mon Feb 23 16​:54​:54 2015, tonyc wrote​:

The problem is occuring in S_outside_integer() which is reporting the
bottom of the range in this code​:

# an attempt to detect former effects of RT#79576, bug itself present
between
# 0.08191 and 0.08209 inclusive (fixed in 0.08210 and higher)
my $stringifiable = 0;

for my $i (0.. $#$bindattrs) {

$stringifiable++ if ( length ref $bind->[$i][1] and
is_plain_value($bind->[$i][1]) );

(the 0) as being out of range because Perl_isinfnan() is returning
true.

While this issue has not been resolved, it will likely disappear from
the BBC because the code in question is removed in [1] and will ship
to
CPAN in the next several hours. Please take steps to not lose track of
this issue going towards 5.22.

Cheers

[1] Perl5/DBIx-Class@cff17b977

This didn't fix the problem.

t/08noclobber.t .... 1/9 Range iterator outside integer range at /home/tony/.cpan/build/DBIx-Class-0.082820-U_G_vt/blib/lib/DBIx/Class/Storage/DBI/SQLite.pm lin

$ ~/perl/blead-gcc/bin/perl -MDBIx​::Class -E 'say $DBIx​::Class​::VERSION'
0.082820

Tony

From @tonycoz

On Tue Feb 24 22​:07​:01 2015, tonyc wrote​:

The problem is occuring in S_outside_integer() which is reporting the
bottom of the range in this code​:

# an attempt to detect former effects of RT#79576, bug itself present
between
# 0.08191 and 0.08209 inclusive (fixed in 0.08210 and higher)
my $stringifiable = 0;

for my $i (0.. $#$bindattrs) {

$stringifiable++ if ( length ref $bind->[$i][1] and
is_plain_value($bind->[$i][1]) );

(the 0) as being out of range because Perl_isinfnan() is returning
true.

If I revert 415b66b which introduced this check the test passes.

If I use the nv value as a memory reference (eg. to dump the raw
content of the NV) the tests pass.

Just dumping the content of the nv as a number makes no difference.

Here's where the strangeness happens​:

(gdb)
0x00000000004f1622 in S_outside_integer ()
=> 0x00000000004f1622 <S_outside_integer+82>​: db 68 30 fldt 0x30(%rax)
(gdb)
0x00000000004f1625 in S_outside_integer ()
=> 0x00000000004f1625 <S_outside_integer+85>​: 48 83 ec 10 sub $0x10,%rsp
(gdb) info float
  R7​: Valid 0x401daa4bb09c9060e000 +1428543566.281989098
=>R6​: Zero 0x00000000000000000000 +0
  R5​: Valid 0x401daa4bb086db5ae800 +1428543555.428427935
  R4​: Valid 0x401daa4bb08800924800 +1428543556.001116037
  R3​: Valid 0x401daa4bb090c9a30800 +1428543560.393821955
  R2​: Valid 0x401daa4bb090c9a35000 +1428543560.3938241
  R1​: Valid 0x401daa4bb090c9c99000 +1428543560.394115925
  R0​: Valid 0x401daa4bb09c90607800 +1428543566.281985998

Status Word​: 0x7069 IE OE PE SF C3
  TOP​: 6
Control Word​: 0x037f IM DM ZM OM UM PM
  PC​: Extended Precision (64-bits)
  RC​: Round to nearest
Tag Word​: 0x1000
Instruction Pointer​: 0x00​:0x004f1622
Operand Pointer​: 0x00​:0x02c8d610
Opcode​: 0xdb68
(gdb) nexti
0x00000000004f1629 in S_outside_integer ()
=> 0x00000000004f1629 <S_outside_integer+89>​: d9 c0 fld %st(0)
(gdb)
0x00000000004f162b in S_outside_integer ()
=> 0x00000000004f162b <S_outside_integer+91>​: db 3c 24 fstpt (%rsp)
(gdb) info float
  R7​: Valid 0x401daa4bb09c9060e000 +1428543566.281989098
  R6​: Zero 0x00000000000000000000 +0
=>R5​: Special 0xffffc000000000000000 Real Indefinite (QNaN)
  R4​: Valid 0x401daa4bb08800924800 +1428543556.001116037
  R3​: Valid 0x401daa4bb090c9a30800 +1428543560.393821955
  R2​: Valid 0x401daa4bb090c9a35000 +1428543560.3938241
  R1​: Valid 0x401daa4bb090c9c99000 +1428543560.394115925
  R0​: Valid 0x401daa4bb09c90607800 +1428543566.281985998

Status Word​: 0x6a69 IE OE PE SF C1 C3
  TOP​: 5
Control Word​: 0x037f IM DM ZM OM UM PM
  PC​: Extended Precision (64-bits)
  RC​: Round to nearest
Tag Word​: 0x1800
Instruction Pointer​: 0x00​:0x004f1629
Operand Pointer​: 0x00​:0x00000000
Opcode​: 0xd9c0

The C1 flag being set indicates a stack overflow occurred, so some generated code isn't managing the stack properly.

Tony

Tony

Tony

From @tonycoz

On Wed Apr 08 19​:02​:25 2015, tonyc wrote​:

The C1 flag being set indicates a stack overflow occurred, so some
generated code isn't managing the stack properly.

This is caused by a mismatch between Time​::HiRes and Time​::Warp on the types of the function pointer stored in the "Time​::NVtime" entry of PL_modglobal.

Time​::HiRes documents that this pointer is​:

double (*)()

but the implementation actually stores a​:

NV (*)()

pointer in that entry.

Time​::Warp follows the documentation and expects that pointer to be a double(*)() and stores a replacement double(*)() pointer in that entry.

On x86_64 double is returned as a value on the FPU stack, but long double is returned the same way as a structure.

When the NV version of the function is called through the double pointer, an FPU stack underflow occurs, or accumulates unused values when the reverse happens.

In any case, this is undefined behaviour and breaks the tests.

I've posted a pull request at manwar/Time-Warp#2

I'll post an issue to Time​::HiRes too.

This isn't a bug in perl, I'll close this ticket soon.

Tony

From @tonycoz

On Wed Apr 15 22​:39​:20 2015, tonyc wrote​:

I'll post an issue to Time​::HiRes too.

https://rt.cpan.org/Ticket/Display.html?id=103765

Tony

@tonycoz - Status changed from 'open' to 'resolved'