Skip Menu |

This queue is for tickets about the Time-HiRes CPAN distribution.

Report information
The Basics
Id: 124450
Status: open
Priority: 0/
Queue: Time-HiRes

People
Owner: Nobody in particular
Requestors: SREZIC [...] cpan.org
Cc: jjnapiork [...] cpan.org
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.9754
Fixed in: (no value)



CC: jjnapiork [...] cpan.org
Subject: 1.9754 breaks Catalyst-Runtime's test suite
The test suite of Catalyst-Runtime-5.90117 seems to fail if the latest Time::HiRes is installed: # Failed test 'elapsed' # at t/unit_stats.t line 94. # got: '1518805116.2776' # expected: '14' # Looks like you failed 1 test of 13. t/unit_stats.t ........................................................ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/13 subtests
On Fri Feb 16 13:23:57 2018, SREZIC wrote: Show quoted text
> The test suite of Catalyst-Runtime-5.90117 seems to fail if the latest > Time::HiRes is installed: > > # Failed test 'elapsed' > # at t/unit_stats.t line 94. > # got: '1518805116.2776' > # expected: '14' > # Looks like you failed 1 test of 13. > t/unit_stats.t > ........................................................ > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/13 subtests
Uh, that result looks clearly like the the current epoch seconds. Is that Catalyst test using tv_interval()? That is about the only thing that changed for the 1.9754?
RT-Send-CC: jjnapiork [...] cpan.org, CAFEGRATZ [...] cpan.org
On 2018-02-17 01:34:26, JHI wrote: Show quoted text
> On Fri Feb 16 13:23:57 2018, SREZIC wrote:
> > The test suite of Catalyst-Runtime-5.90117 seems to fail if the > > latest > > Time::HiRes is installed: > > > > # Failed test 'elapsed' > > # at t/unit_stats.t line 94. > > # got: '1518805116.2776' > > # expected: '14' > > # Looks like you failed 1 test of 13. > > t/unit_stats.t > > ........................................................ > > Dubious, test returned 1 (wstat 256, 0x100) > > Failed 1/13 subtests
> > Uh, that result looks clearly like the the current epoch seconds. > > Is that Catalyst test using tv_interval()? That is about the only > thing that changed > for the 1.9754?
I'll check later. I found another "victim": CAFEGRATZ/Devel-TimeStats-0.04.tar.gz The test failure here looks similar: ... # Failed test 'elapsed' # at t/unit_stats.t line 100. # got: '1518820807.8718' # expected: '14' # Looks like you failed 1 test of 13. t/unit_stats.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/13 subtests ...
Subject: Re: [rt.cpan.org #124450] 1.9754 breaks Catalyst-Runtime's test suite
Date: Sat, 17 Feb 2018 12:32:26 +0000
To: Slaven_Rezic via RT <bug-Time-HiRes [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
Both victims are using tv_interval(), in very similar manner, and crucially they're testing it in the same manner too. The test involves monkey-patching Time::HiRes::gettimeofday() to fake the time, and the modules make use of the one-arg form of tv_interval(). The old Perl tv_interval() when called with one arg would call Time::HiRes::gettimeofday() to get the current time, but the new XS tv_interval() calls the C gettimeofday() directly and so isn't affected by the monkey-patching. -zefram
On Sat Feb 17 07:32:43 2018, zefram@fysh.org wrote: Show quoted text
> Both victims are using tv_interval(), in very similar manner, > and crucially they're testing it in the same manner too. The test > involves monkey-patching Time::HiRes::gettimeofday() to fake the > time, and the modules make use of the one-arg form of tv_interval(). > The old Perl tv_interval() when called with one arg would call > Time::HiRes::gettimeofday() to get the current time, but the new XS > tv_interval() calls the C gettimeofday() directly and so isn't affected > by the monkey-patching.
Thanks, Zefram! Then it doesn't sound like Time::HiRes can immediately do anything useful to cater for this expected behavior. Code expecting to monkey patch (or "virtualize") the time sources like this should probably use instead a code ref pointing to whatever. Show quoted text
> -zefram
I've reported this issue to both affected modules.