Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

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

Report information
The Basics
Id:
34655
Status:
resolved
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
whorka [...] hmdc.harvard.edu
Cc:
AdminCc:

BugTracker
Severity:
(no value)
Broken in:
(no value)
Fixed in:
(no value)



Subject: glibc ualarm on Linux won't accept usec values outside 0-999999
Date: Thu, 03 Apr 2008 17:49:24 -0400
To: bug-Time-HiRes@rt.cpan.org
From: "William J. Horka" <whorka@hmdc.harvard.edu>
The perl Time::HiRes module alarm() function takes a time value in seconds and sets an alarm by calling the glibc ualarm() function and passing it the time value * 1000000 (microseconds). This results in warnings being generated by the syscall setitimer() which is called by glibc ualarm(). The call from Time::HiRes::alarm() to glibc ualarm() is contrary to the documented [non-]functionality of glibc ualarm() in two ways, as noted in the ualarm manpage: 1) ERRORS EINVAL usecs or interval is not smaller than 1000000. (On systems where that is considered an error.) 2) NOTES This function is obsolete. Use nanosleep(2) or setitimer(2) instead. The source of the problem is that the linux kernel did not used to consider usecs or interval >= 1000000 to be an error in a call to setitimer(). This behavior changed as noted in linux-2.6.18/Documentation/feature-removal-schedule.txt: What: Usage of invalid timevals in setitimer When: March 2007 Why: POSIX requires to validate timevals in the setitimer call. This was never done by Linux. The invalid (e.g. negative timevals) were silently converted to more or less random timeouts and intervals. Until the removal a per boot limited number of warnings is printed and the timevals are sanitized. Who: Thomas Gleixner <tglx@linutronix.de> This is also noted in the setitimer() manpage: BUGS POSIX.1-2001 says that setitimer() should fail if a tv_usec value is specified that is outside of the range 0 to 999999. However, Linux does not give an error, but instead silently adjusts the corresponding seconds value for the timer. In the future (scheduled for March 2007), this non-conformance will be repaired: existing applications should be fixed now to ensure that they supply a properly formed tv_usec value. In kernel 2.6.18 from September 2006 (the default kernel for RHEL5), kernel/itimer.c contains code to sanitize arguments to setitimer(), and will print out warnings (10 per boot) when it receives invalid arguments. In the latest kernel (2.6.24.4 from March 2008) this code has been replaced by code that will return an error when invalid arguments are passed to setitimer(). This problem was apparently addressed in Time::HiRes 1.91, but the change that was made appears to address the symptom rather than the source of the problem. The Changes file notes: 1.91 [2006-09-29] - ualarm() in SuSE 10.1 was overflowing after ~4.2 seconds, possibly due to a glibc bug/feature (suspected overflow at 2**32 microseconds?), workaround by using the setitimer() implementation of ualarm() if either useconds or interval > 999_999 (this case seems to vary between systems: are useconds more than 999_999 for ualarm() defined or not) Added more ualarm() tests to catch various overflow points, hopefully no problems in various platforms. (The problem report by Mark Seger and Jon Paul Sullivan of HP.) However, the alarm() function in Time::HiRes 1.9712 still contains the bug where it tries to pass a value of seconds * 1000000 to ualarm(), so any nonzero value for seconds will be result in the argument to ualarm() being out of bounds. Proposed fix: Per the ualarm() manpage, don't pass it values outside the range of 0 to 999999 since glibc ualarm() passes the value to setitimer() which requires a value in this range according to POSIX.1-2001 and the Linux kernel now considers a value outside this range to be an error. Use setitimer() instead. -- William Horka UNIX Systems Administrator Harvard-MIT Data Center
Subject: Re: [rt.cpan.org #34655] glibc ualarm on Linux won't accept usec values outside 0-999999
Date: Sat, 12 Apr 2008 13:17:55 -0400
To: bug-Time-HiRes@rt.cpan.org
From: Jarkko Hietaniemi <jhi@iki.fi>
Is 1.9715 any better for you?
I see test failures one of the PPM darwin build boxes that is caused by the the croak() when ualarm is called with values >= 1e6. See http://ppm4.activestate.com/darwin/5.8/818/J/JH/JHI/Time-HiRes-1.9719.d/log- 20090105T121250.txt $ uname -a Darwin ocelotl.activestate.com 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc The following patch fixes the problem on this machine. diff -u Time-HiRes/HiRes.xs.1.9719 Time-HiRes/HiRes.xs --- Time-HiRes/HiRes.xs.1.9719 2009-03-20 06:00:45.000000000 -0700 +++ Time-HiRes/HiRes.xs 2009-03-20 06:16:16.000000000 -0700 @@ -920,8 +920,6 @@ } } #else - if (useconds >= IV_1E6 || uinterval >= IV_1E6) - croak("Time::HiRes::ualarm(%d, %d): useconds or uinterval equal to or more than %"IVdf, useconds, uinterval, IV_1E6); RETVAL = ualarm(useconds, uinterval); #endif @@ -948,8 +946,6 @@ } } #else - if (useconds >= IV_1E6 || uinterval >= IV_1E6) - croak("Time::HiRes::alarm(%d, %d): seconds or interval equal to or more than 1.0 ", useconds, uinterval, IV_1E6); RETVAL = (NV)ualarm( useconds, uinterval ) / NV_1E6; #endif }
Alternative if you want to keep the croaks in there is to not expect to be able to test ualarm() with values above 1e6 µs, or to trap the croak and be happy with that outcome as well. If you want a patch along those lines instead I can try to hack that together.
Subject: Re: [rt.cpan.org #34655] glibc ualarm on Linux won't accept usec values outside 0-999999
Date: Tue, 31 Mar 2009 12:33:41 -0400
To: bug-Time-HiRes@rt.cpan.org
From: Jarkko Hietaniemi <jhi@iki.fi>
Gisle_Aas via RT wrote:
Show quoted text
> Queue: Time-HiRes > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=34655 > > > Alternative if you want to keep the croaks in there is to not expect to be able to test ualarm() > with values above 1e6 µs, or to trap the croak and be happy with that outcome as well. If you > want a patch along those lines instead I can try to hack that together. >
I'm a little lost as to what to do here. If you look at the original ticket, the issue was that in olden times Linux kernels didn't say "barf" to >999_999 useconds. Then they started saying that, so I changed the implementation to prefer setitimer(), if available. But what you are saying is that in PPC Linux I cannot do the setitimer() thing, and I should still use the ualarm() with >999_999 values...?
Subject: Re: [rt.cpan.org #34655] glibc ualarm on Linux won't accept usec values outside 0-999999
Date: Tue, 07 Apr 2009 19:24:42 -0400
To: bug-Time-HiRes@rt.cpan.org
From: "William J. Horka" <whorka@hmdc.harvard.edu>
I never had an opportunity to test this, but I originally observed this behavior on a Red Hat Enterprise Linux 5 system, and I saw that Red Hat recently released an update to their perl package which includes a fix for this issue. I believe this patch was incorporated from upstream, per your comment about using setitimer, and the issue has been resolved at the source. From the Red Hat errata: * the Time::HiRes Perl module is incompatible with the latest version of glibc, which caused setitimer errors to be written to /var/log/dmesg when the alarm() function of HiRes was called with a time greater than one second. With this update, the Time::HiRes module calls setitimer with the correct parameters and no error messages are written to /var/log/dmesg, thus resolving this issue. http://rhn.redhat.com/errata/RHBA-2009-0406.html Took them a year, but that's less time than it took me to get back to this. Also, unless I'm mistaken, I think what Gile is suggesting is that on systems that don't have the HAS_SETITIMER and ITIMER_REAL macros defined (like PPC Darwin apparently), Time::Hires should not assume that calling ualarm() with values above >999_999 useconds will fail, and should instead pass back the actual return code from the system call. Also, I should point out that my original bug report applied only to glibc ualarm on Linux, Gile is referring to a build test on PPC Darwin. This is consistent with the Linux man page for ualarm(3), which notes that ualarm() will return EINVAL when "usecs or interval is not smaller than 1000000. (On systems where that is considered an error.)" PPC Darwin may not be one of those systems. Oh, and Gile, if you're on cc:, many thanks for lwp. :) -Bill jhi@iki.fi via RT wrote:
Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=34655 > > > Is 1.9715 any better for you? >
-- William Horka UNIX Systems Administrator Harvard-MIT Data Center
Subject: Re: [rt.cpan.org #34655] glibc ualarm on Linux won't accept usec values outside 0-999999
Date: Tue, 07 Apr 2009 19:26:16 -0400
To: bug-Time-HiRes@rt.cpan.org
From: "William J. Horka" <whorka@hmdc.harvard.edu>
William J. Horka wrote:
Show quoted text
> > Oh, and Gile, if you're on cc:, many thanks for lwp. :)
When commending someone on a decade's worth of work, it behooves one to check that their name is spelled correctly. My apologies, Gisle. -Bill


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.