Bug #69541 for Time-HiRes: Fails to build on 5.15.0

Sun Jul 17 22:28:12 2011 njh [...] bandsman.co.uk - Ticket created

Subject:

Fails to build on 5.15.0

Confirmed on 32- and 64-bit Linux and Darwin. bandsman:/var/www/mirrors/CPAN/authors/id/Z/ZE/ZEFRAM/Time-HiRes-1.9724# perl5.15.0 Makefile.PL Configuring Time::HiRes... Using hints hints/linux.pl... Extra libraries: -lrt... Have syscall()... looking for syscall.h... found <syscall.h>. Looking for gettimeofday()... found. Looking for setitimer()... found. Looking for getitimer()... found. You have interval timers (both setitimer and getitimer). Looking for ualarm()... found. Looking for usleep()... found. Looking for nanosleep()... testing... found. You can mix subsecond sleeps with signals, if you want to. (It's still not portable, though.) Looking for clock_gettime()... found. Looking for clock_getres()... found. Looking for clock_nanosleep()... found. Looking for clock()... found. Looking for stat() subsecond timestamps... Trying struct stat st_atimespec.tv_nsec...NOT found. Trying struct stat st_atimensec...NOT found. Trying struct stat st_atime_n...NOT found. Trying struct stat st_atim.tv_nsec...found. Trying struct stat st_uatime...NOT found. You seem to have stat() subsecond timestamps. (Your struct stat has them, but the filesystems must help.) Checking if your kit is complete... Looks good Processing hints file hints/linux.pl Writing Makefile for Time::HiRes Writing MYMETA.yml and MYMETA.json Now you may issue 'make'. Do not forget also 'make test'. bandsman:/var/www/mirrors/CPAN/authors/id/Z/ZE/ZEFRAM/Time-HiRes-1.9724# make cp HiRes.pm blib/lib/Time/HiRes.pm /usr/local/bin/perl5.15.0 /usr/local/lib/perl5/5.15.0/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.15.0/ExtUtils/typemap -typemap typemap HiRes.xs > HiRes.xsc && mv HiRes.xsc HiRes.c cc -c -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -O2 -W -Wformat=2 -Wall -Wextra -pipe -mtune=native -march=native -fomit-frame-pointer -msse2 -msse -mmmx -mfpmath=sse -D_FORTIFY_SOURCE=2 -fstack-protector -Wstack-protector -Wfloat-equal -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.9724\" -DXS_VERSION=\"1.9724\" -fPIC "-I/usr/local/lib/perl5/5.15.0/x86_64-linux-thread-multi/CORE" -DTIME_HIRES_NANOSLEEP -DTIME_HIRES_CLOCK_GETTIME -DTIME_HIRES_CLOCK_GETRES -DTIME_HIRES_CLOCK_NANOSLEEP -DTIME_HIRES_CLOCK -DTIME_HIRES_STAT=4 -DATLEASTFIVEOHOHFIVE HiRes.c HiRes.c: In function ‘XS_Time__HiRes_constant’: ./const-xs.inc:38:11: warning: ‘iv’ may be used uninitialized in this function [-Wuninitialized] ./const-xs.inc:11:6: note: ‘iv’ was declared here Running Mkbootstrap for Time::HiRes () chmod 644 HiRes.bs rm -f blib/arch/auto/Time/HiRes/HiRes.so LD_RUN_PATH="/usr/lib/x86_64-linux-gnu" cc -shared -O2 -L/usr/local/lib -fstack-protector HiRes.o -o blib/arch/auto/Time/HiRes/HiRes.so \ -lrt \ chmod 755 blib/arch/auto/Time/HiRes/HiRes.so cp HiRes.bs blib/arch/auto/Time/HiRes/HiRes.bs chmod 644 blib/arch/auto/Time/HiRes/HiRes.bs Manifying blib/man3/Time::HiRes.3 bandsman:/var/www/mirrors/CPAN/authors/id/Z/ZE/ZEFRAM/Time-HiRes-1.9724# make test PERL_DL_NONLAZY=1 /usr/local/bin/perl5.15.0 "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t perl5.15.0: av.c:731: Perl_av_len: Assertion `((svtype)((av)->sv_flags & 0xff)) == SVt_PVAV' failed. Aborted (core dumped) make: *** [test_dynamic] Error 134 bandsman:/var/www/mirrors/CPAN/authors/id/Z/ZE/ZEFRAM/Time-HiRes-1.9724#

Wed Jul 20 05:41:11 2011 zefram [...] fysh.org - Correspondence added

Subject:	Re: [rt.cpan.org #69541] Fails to build on 5.15.0
Date:	Wed, 20 Jul 2011 10:40:52 +0100
To:	"njh [...] bandsman.co.uk via RT" <bug-Time-HiRes [...] rt.cpan.org>
From:	Zefram <zefram [...] fysh.org>

njh@bandsman.co.uk via RT wrote: Show quoted text

>perl5.15.0: av.c:731: Perl_av_len: Assertion `((svtype)((av)->sv_flags & >0xff)) == SVt_PVAV' failed.

I can't reproduce this on a debugging build of blead (on 32-bit Linux). I note that T:HR doesn't call av_len() directly. Can you reproduce this under gdb, and get me a C-level stack trace? If possible also a Perl-level stack trace (you can call C functions from within the debugger to do this). -zefram

Wed Jul 20 05:41:13 2011 The RT System itself - Status changed from 'new' to 'open'

Wed Jul 20 09:56:19 2011 njh [...] bandsman.co.uk - Correspondence added

From:

njh [...] bandsman.co.uk

Here's the stack-trace from GDB. I don't know how to create a Perl stack-trace. To generate the core dump, I did: perl Makefile.PL make make test #0 0x00007f0c7f41e405 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007f0c7f421680 in abort () at abort.c:92 #2 0x00007f0c7f4175b1 in __assert_fail ( assertion=0x617d88 "((svtype)((av)->sv_flags & 0xff)) == SVt_PVAV", file=<value optimized out>, line=731, function=0x61844e "Perl_av_len") at assert.c:81 #3 0x00000000004d32f2 in Perl_av_len () #4 0x000000000043a1a3 in Perl_call_list () #5 0x00007f0c80673c4c in boot_Time__HiRes () from /usr/local/lib/perl5/site_perl/5.15.0/x86_64-linux-thread-multi/auto/Time/HiRes/HiRes.so #6 0x00000000004e0974 in Perl_pp_entersub () #7 0x00000000004acc20 in Perl_runops_debug () #8 0x0000000000439b40 in Perl_call_sv () #9 0x000000000043a51f in Perl_call_list () #10 0x000000000041d1ff in S_process_special_blocks () #11 0x000000000042de8b in Perl_newATTRSUB () #12 0x000000000042eb93 in Perl_utilize () #13 0x000000000047376c in Perl_yyparse () #14 0x000000000053b766 in S_doeval () #15 0x000000000054eeb4 in Perl_pp_entereval () #16 0x00000000004acc20 in Perl_runops_debug () #17 0x0000000000439b40 in Perl_call_sv () #18 0x000000000043a51f in Perl_call_list () #19 0x000000000041d1ff in S_process_special_blocks () #20 0x000000000042de8b in Perl_newATTRSUB () #21 0x000000000042eb93 in Perl_utilize () #22 0x000000000047376c in Perl_yyparse () #23 0x000000000053b766 in S_doeval () #24 0x000000000054d7c5 in Perl_pp_require () #25 0x00000000004acc20 in Perl_runops_debug () #26 0x0000000000439b40 in Perl_call_sv () #27 0x000000000043a51f in Perl_call_list () #28 0x000000000041d1ff in S_process_special_blocks () #29 0x000000000042de8b in Perl_newATTRSUB () #30 0x000000000042eb93 in Perl_utilize () #31 0x000000000047376c in Perl_yyparse () #32 0x000000000053b766 in S_doeval () #33 0x000000000054d7c5 in Perl_pp_require () #34 0x00000000004acc20 in Perl_runops_debug () #35 0x0000000000439b40 in Perl_call_sv () #36 0x000000000043a51f in Perl_call_list () #37 0x000000000041d1ff in S_process_special_blocks () #38 0x000000000042de8b in Perl_newATTRSUB () #39 0x000000000042eb93 in Perl_utilize () #40 0x000000000047376c in Perl_yyparse () #41 0x000000000053b766 in S_doeval () #42 0x000000000054d7c5 in Perl_pp_require () #43 0x00000000004acc20 in Perl_runops_debug () #44 0x0000000000441278 in perl_run () #45 0x000000000041cd0e in main ()

Wed Jul 20 10:35:40 2011 njh [...] bandsman.co.uk - Correspondence added

From:

njh [...] bandsman.co.uk

I removed 5.15.0 and re-installed and the problem has gone away. Looks like a problem at my end, though I don't know what it is. Sorry for the noise. RT provides no means for me to close the bug report, sorry.

Wed Jul 20 14:58:53 2011 zefram [...] fysh.org - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #69541] Fails to build on 5.15.0
Date:	Wed, 20 Jul 2011 19:58:30 +0100
To:	"njh [...] bandsman.co.uk via RT" <bug-Time-HiRes [...] rt.cpan.org>
From:	Zefram <zefram [...] fysh.org>

njh@bandsman.co.uk via RT wrote: Show quoted text

>I removed 5.15.0 and re-installed and the problem has gone away. Looks >like a problem at my end, though I don't know what it is.

The gdb stack trace shows that the assertion failed when trying to run the UNITCHECK sections. (All zero of them.) My best guess is that you modified configuration somewhere and ended up with mismatched binaries. -zefram

Wed Jul 20 14:59:59 2011 ZEFRAM [...] cpan.org - Status changed from 'open' to 'resolved'