Bug 453327 - Time::HiRes V1.86 does work correctly with current glibc
Summary: Time::HiRes V1.86 does work correctly with current glibc
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: perl
Version: 5.1
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Marcela Mašláňová
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks: 492112
TreeView+ depends on / blocked
 
Reported: 2008-06-29 18:11 UTC by Mark Seger
Modified: 2009-09-02 09:07 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-02 09:07:05 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:1244 0 normal SHIPPED_LIVE perl bug fix and enhancement update 2009-09-01 08:57:47 UTC

Description Mark Seger 2008-06-29 18:11:21 UTC
Description of problem: HiRes does not work correctly for times >1 second


Version-Release number of selected component (if applicable): 1.86


How reproducible: fails on boot, random at other times

Steps to Reproduce:
1. call HiRes with time > 1 second in an inet.d script at startup
2. a setitimer error will be written to dmseg

Actual results:


Expected results:


Additional info:

I'm not sure what this only happens at boot as it should happen all the time. 
There is a known bug in HiRes in that it calls setitimer passing only usecs,
even when > 1.  Version 1.91 has fixed this by calling setitimer with the
correct parameters.

The reason this has gone undetected before is that 2.3 of glib, which was on
RHEL4 systems, is more forgiving of bad parameters whereas the current glibc is
not.  At the very minimum, this breaks the collectl utility.

Here's what strace shows for a 2 second alarm with 1.86
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 2000000}},
{it_interval={0, 0}, it_value={0, 0}}) = 0

Here's the same program run under HiRes 1.91
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={2, 0}}, NULL) = 0

Note that the 2 seconds is in the correct parameter this time...

Comment 1 Warren Togami 2008-06-30 02:53:58 UTC
This looks like a real bug.  I can request this for 5.3 but it isn't my decision
if it makes it in.

(Adding kzak since he owns collectl in Fedora.)

Comment 2 Mark Seger 2008-07-01 20:31:07 UTC
I've been doing a lot more digging into this and it appears to be somewhat
benign as it only seems to show up at boot time.  However since it IS calling
setitimer() with invalid arguments who knows when someone is going to do more
careful checking and simply returns errors in the call.  For what it's worth, I
tried to describe this in a support page for users of collectl.  Feel free to
let me know if I got it wrong and/or am posting misleading information.

http://collectl.sourceforge.net/HiResTime.html

-mark


Comment 3 RHEL Program Management 2008-07-21 23:00:50 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 6 James M. Leddy 2009-01-22 23:25:30 UTC
Relevent parts of the Changelog 

1.9713	[2008-04-04]
	- for alarm() and ualarm() [Perl] prefer setitimer() [C]
	  instead of ualarm() [C] since ualarm() [C] cannot portably
	  (and standards-compliantly) be used for more than 999_999
	  microseconds (rt.cpan.org #34655)

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.)

Original conversation for context http://coding.derkeiler.com/Archive/Perl/comp.lang.perl.misc/2008-07/msg00032.html

relevent diff of ext/Time/HiRes/HiRes.xs

+static int
+hrt_ualarm_itimero(struct itimerval* itv, int usec, int uinterval)
+{
+   itv->it_value.tv_sec = usec / IV_1E6;
+   itv->it_value.tv_usec = usec % IV_1E6;
+   itv->it_interval.tv_sec = uinterval / IV_1E6;
+   itv->it_interval.tv_usec = uinterval % IV_1E6;
+   return setitimer(ITIMER_REAL, itv, 0);
+}
 
 int
-hrt_ualarm(int usec, int interval)
+hrt_ualarm_itimer(int usec, int uinterval)
 {
-   struct itimerval itv;
-   itv.it_value.tv_sec = usec / 1000000;
-   itv.it_value.tv_usec = usec % 1000000;
-   itv.it_interval.tv_sec = interval / 1000000;
-   itv.it_interval.tv_usec = interval % 1000000;
-   return setitimer(ITIMER_REAL, &itv, 0);
+  struct itimerval itv;
+  return hrt_ualarm_itimero(&itv, usec, uinterval);
 }
+
+
+#ifdef HAS_UALARM
+int
+hrt_ualarm(int usec, int interval) /* for binary compat before 1.91 */
+{
+   return hrt_ualarm_itimer(usec, interval);
+}


<snip>
In function ualarm(useconds,uinterval=0)


-       if (useconds < 0 || interval < 0)
-           croak("Time::HiRes::ualarm(%d, %d): negative time not invented yet",
 useconds, interval);
-       RETVAL = ualarm(useconds, interval);
+       if (useconds < 0 || uinterval < 0)
+           croak("Time::HiRes::ualarm(%d, %d): negative time not invented yet",
 useconds, uinterval);
+       if (useconds >= IV_1E6 || uinterval >= IV_1E6) 
+#if defined(HAS_SETITIMER) && defined(ITIMER_REAL)
+         {
+               struct itimerval itv;
+               if (hrt_ualarm_itimero(&itv, useconds, uinterval)) {
+                 RETVAL = itv.it_value.tv_sec + IV_1E6 * itv.it_value.tv_usec;
+               } else {
+                 RETVAL = 0;
+               }
+         }


Obviously the problem here is RETVAL = ualarm(useconds, interval);  Not sure what the function redifinition is about, but it doesn't seem to have used it in the past.

Comment 8 Warren Togami 2009-01-23 03:50:10 UTC
Spot said the risk of doing this as an update even before 5.3 was low.  I will build it if I have the necessary approvals to do so.

Comment 33 Mick Russom 2009-04-24 05:28:57 UTC
@Comment #3 "From  RHEL Product and Program Management (pm-rhel)  2008-07-21 19:00:50 EDT This request was evaluated by Red Hat Product Management for"

One of two things here:
1) Either the poster of this is hiding behind an email alias because they know this was the wrong position to take.

2) This person who is posting stuff like this is not qualified to be a product manager for an Enterprise Linux. Their names should be revealed so I can target the individuals responsible through the account manager.

Comment 34 Marcela Mašláňová 2009-04-24 05:52:23 UTC
This comment was probably automatic message from our bots. However this fix will be in RHEL-5.4 update.

Comment 35 James M. Leddy 2009-04-24 14:24:22 UTC
(In reply to comment #33)
> @Comment #3 "From  RHEL Product and Program Management (pm-rhel) 
> 2008-07-21 19:00:50 EDT This request was evaluated by Red Hat Product
> Management for"
> 
> One of two things here:
> 1) Either the poster of this is hiding behind an email alias because they know
> this was the wrong position to take.

As said before, anything from pm-rhel is a bot.

> 
> 2) This person who is posting stuff like this is not qualified to be a product
> manager for an Enterprise Linux. Their names should be revealed so I can target
> the individuals responsible through the account manager.  

All the message was saying was that it wasn't scheduled for 5.3, which makes sense because it was opened by someone who is not familiar with our development process.  Shortly after that someone did set the correct flags to schedule it for 5.3

I hope this clears up any concerns you have.

Comment 37 Stepan Kasal 2009-06-29 18:44:47 UTC
Actually, when we are rebasing to an updated version of Time::HiRes, I believe  1.9717 is a preferable one; it fixes several bugs found in 1.9715, cf the Changes file.

Comment 40 Chris Ward 2009-07-03 18:04:14 UTC
~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.

Comment 43 errata-xmlrpc 2009-09-02 09:07:05 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1244.html


Note You need to log in before you can comment on or make changes to this bug.