Bleadperl between v5.21.7-259-g819b139 and v5.21.7-435-gdf3c16d broke RIBASUSHI/DBIx-Class-TimeStamp-0.14.tar.gz

p5pRT commented 9 years ago

Migrated from rt.perl.org#123879 (status was 'resolved')

Searchable as RT123879$

p5pRT commented 9 years ago

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: 819b139db33e2022424694e381422766903d4f65 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

p5pRT commented 9 years ago

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

p5pRT commented 9 years ago

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

p5pRT commented 9 years ago

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

p5pRT commented 9 years ago

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

p5pRT commented 9 years ago

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 415b66b2 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

p5pRT commented 9 years ago

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] https://github.com/dbsrgits/dbix-class/commit/cff17b977

p5pRT commented 9 years ago

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] https://github.com/dbsrgits/dbix-class/commit/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

p5pRT commented 9 years ago

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 415b66b2 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

p5pRT commented 9 years ago

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 https://github.com/szabgab/Time-Warp/pull/2

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

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

Tony

p5pRT commented 9 years ago

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

p5pRT commented 9 years ago

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

Perl / perl5